idnits 2.17.00 (12 Aug 2021) /tmp/idnits30026/draft-ietf-opsec-current-practices-04.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 1702. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1679. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1686. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1692. ** 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 (June 25, 2006) is 5808 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: 'BCP38' is mentioned on line 891, but not defined == Missing Reference: 'BCP84' is mentioned on line 891, but not defined == Missing Reference: 'BHTR' is mentioned on line 892, but not defined == Missing Reference: 'GTSM' is mentioned on line 1044, but not defined == Missing Reference: 'IRR' is mentioned on line 1108, but not defined ** Obsolete normative reference: RFC 2828 (Obsoleted by RFC 4949) 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 Expires: December 27, 2006 June 25, 2006 6 Operational Security Current Practices 7 draft-ietf-opsec-current-practices-04 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 December 27, 2006. 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 . . . . . . . . . . . . . . . . . . . . . . . . 25 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. Normative References . . . . . . . . . . . . . . . . . . . . . 35 69 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 36 70 Appendix B. Protocol Specific Attacks . . . . . . . . . . . . . . 37 71 B.1. Layer 2 Attacks . . . . . . . . . . . . . . . . . . . . . 37 72 B.2. IPv4 Attacks . . . . . . . . . . . . . . . . . . . . . . . 37 73 B.3. IPv6 Attacks . . . . . . . . . . . . . . . . . . . . . . . 38 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 39 75 Intellectual Property and Copyright Statements . . . . . . . . . . 40 77 1. Introduction 79 Security practices are well understood by the network operators who 80 have for many years gone through the growing pains of securing their 81 network infrastructures. However, there does not exist a written 82 document that enumerates these security practices. Network attacks 83 are continually increasing and although it is not necessarily the 84 role of an ISP to act as the Internet police, each ISP has to ensure 85 that certain security practices are followed to ensure that their 86 network is operationally available for their customers. This 87 document is the result of a survey conducted to find out what current 88 security practices are being deployed to secure network 89 infrastructures. 91 1.1. Scope 93 The scope for this survey is restricted to security practices that 94 mitigate exposure to risks with the potential to adversely impact 95 network availability and reliability. Securing the actual data 96 traffic is outside the scope of the conducted survey. This document 97 focuses solely on documenting currently deployed security mechanisms 98 for layer 2 and layer 3 network infrastructure devices. Although 99 primarily focused on IPv4, many of the same practices can (and 100 should) apply to IPv6 networks. Both IPv4 and IPv6 network 101 infrastructures are taken into account in this survey. 103 1.2. Threat Model 105 A threat is a potential for a security violation, which exists when 106 there is a circumstance, capability, action, or event that could 107 breach security and cause harm [RFC2828].Every operational network is 108 subject to a multitude of threat actions, or attacks, i.e. an assault 109 on system security that derives from an intelligent act that is a 110 deliberate attempt to evade security services and violate the 111 security policy of a system [RFC2828]. All of the threats in any 112 network infrastructure is an instantiation or combination of the 113 following: 115 Reconnaissance: An attack whereby information is gathered to 116 ascertain the network topology or specific device information which 117 can be further used to exploit known vulnerabilities 119 Man-In-The-Middle: An attack where a malicious user impersonates 120 either the sender or recipient of a communication stream while 121 inserting, modifying or dropping certain traffic. This type of 122 attack also covers phishing and session hijacks. 124 Protocol Vulnerability Exploitation: An attack which takes advantage 125 of known protocol deficiencies to cause inappropriate behavior. 127 Message Insertion: This can be a valid message (which could be a 128 reply attack, which is a scenario where a message is captured and 129 resent at later time). A message can also be inserted with any of 130 the fields in the message being OspoofedO, such as IP addresses, port 131 numbers, header fields or even packet content. Flooding is also part 132 of this threat instantiation. 134 Message Diversion/Deletion: An attack where legitimate messages are 135 removed before they can reach the desired recipient or are re- 136 directed to a network segment that is normally not part of the data 137 path. 139 Message Modification: This is a subset of a message insertion attack 140 where a previous message has been captured and modified before being 141 retransmitted. The message can be captured by using a man-in-the- 142 middle attack or message diversion. 144 Note that sometimes Denial of service attacks are listed as separate 145 categories. A denial of service is a consequence of an attack and 146 can be the result of too much traffic (i.e. flooding), or exploiting 147 protocol exploitation or inserting/deleting/diverting/modifying 148 messages. 150 1.3. Attack Sources 152 These attacks can be sourced in a variety of ways: 154 Active vs passive attacks 156 An active attack involves writing data to the network. It is 157 common practice in active attacks to disguise one's address and 158 conceal the identity of the traffic sender. A passive attack 159 involves only reading information off the network. This is 160 possible if the attacker has control of a host in the 161 communications path between two victim machines or has compromised 162 the routing infrastructure to specifically arrange that traffic 163 pass through a compromised machine. In general, the goal of a 164 passive attack is to obtain information that the sender and 165 receiver would prefer to remain private. [RFC3552] 167 On-path vs off-path attacks 168 In order for a datagram to be transmitted from one host to 169 another, it generally must traverse some set of intermediate links 170 and routers. Such routers are naturally able to read, modify, or 171 remove any datagram transmitted along that path. This makes it 172 much easier to mount a wide variety of attacks if you are on-path. 173 Off-path hosts can transmit arbitrary datagrams that appear to 174 come from any hosts but cannot necessarily receive datagrams 175 intended for other hosts. Thus, if an attack depends on being 176 able to receive data, off-path hosts must first subvert the 177 topology in order to place themselves on-path. This is by no 178 means impossible but is not necessarily trivial. [RFC3552] 180 Insider or outsider attacks 182 An "insider attack" is one which is initiated from inside a given 183 security perimeter, by an entity that is authorized to access 184 system resources but uses them in a way not approved by those who 185 granted the authorization. An "outside attack" is initiated from 186 outside the perimeter, by an unauthorized or illegitimate user of 187 the system. 189 Deliberate attacks vs unintentional events 191 A deliberate attack is one where a miscreant intentionally 192 performs an assault on system security. However, there are also 193 instances where unintentional events cause the same harm yet are 194 performed without malice in mind. Configuration errors and 195 software bugs can be as devastating to network availability as any 196 deliberate attack on the network infrastructure. 198 The attack source can be a combination of any of the above, all of 199 which need to be considered when trying to ascertain what impact any 200 attack can have on the availability and reliability of the network. 201 It is nearly impossible to stop insider attacks or unintentional 202 events. However, if appropriate monitoring mechanisms are in place, 203 these attacks can be as easily detected and mitigated as with any 204 other attack source. Any of the specific attacks discussed further 205 in this document will elaborate on attacks which are sourced by an 206 "outsider" and are deliberate attacks. Some further elaboration will 207 be given to the feasibility of passive vs active and on-path vs off- 208 path attacks to show the motivation behind deploying certain security 209 features. 211 1.4. Operational Security Impact from Threats 213 The main concern for any of the potential attack scenarios is the 214 impact and harm it can cause to the network infrastructure. The 215 threat consequences are the security violations which results from a 216 threat action, i.e. an attack. These are typically classified as 217 follows: 219 (Unauthorized) Disclosure 221 A circumstance or event whereby an entity gains access to data for 222 which the entity is not authorized. 224 Deception 226 A circumstance or event that may result in an authorized entity 227 receiving false data and believing it to be true. 229 Disruption 231 A circumstance or event that interrupts or prevents the correct 232 operation of system services and functions. A broad variety of 233 attacks, collectively called denial of service attacks, threaten 234 the availability of systems and bandwidth to legitimate users. 235 Many such attacks are designed to consume machine resources, 236 making it difficult or impossible to serve legitimate users. 237 Other attacks cause the target machine to crash, completely 238 denying service to users. 240 Usurpation 242 A circumstance or event that results in control of system services 243 or functions by an unauthorized entity. Most network 244 infrastructure systems are only intended to be completely 245 accessible to certain authorized individuals. Should an 246 unauthorized person gain access to critical layer 2 / layer 3 247 infrastructure devices or services, they could cause great harm to 248 the reliability and availability of the network. 250 A complete description of threat actions that can cause these threat 251 consequences can be found in [RFC2828]. Typically, a number of 252 different network attacks are used in combination to cause one or 253 more of the above mentioned threat consequences. An example would be 254 a malicious user who has the capability to eavesdrop on traffic. 255 First, he may listen in on traffic for a while to do some 256 reconnaissance work and ascertain which IP addresses belonged to 257 specific devices such as routers. Were this miscreant to obtain 258 information such as a router password sent in cleartext, he can then 259 proceed to compromise the actual router. From there, the miscreant 260 can launch various active attacks such as sending bogus routing 261 updates to redirect traffic or capture additional traffic to 262 compromise other network devices. 264 1.5. Document Layout 266 This document is a survey of current operational practices that 267 mitigate the risk of being susceptible to any threat actions. As 268 such, the main focus is on the currently deployed security practices 269 used to detect and/or mitigate attacks. The top-level categories in 270 this document are based on operational functions for ISPs and 271 generally relate to what is to be protected. This is followed by a 272 description of which attacks are possible and the security practices 273 currently deployed which will provide the necessary security services 274 to help mitigate these attacks. These security services are 275 classified as: 277 o User Authentication 279 o User Authorization 281 o Data Origin Authentication 283 o Access Control 285 o Data Integrity 287 o Data Confidentiality 289 o Auditing / Logging 291 o DoS Mitigation 293 In many instances, a specific protocol currently deployed will offer 294 a combination of these services. For example, AAA can offer user 295 authentication, user authorization and audit / logging services while 296 SSH can provide data origin authentication, data integrity and data 297 confidentiality. The services offered are more important than the 298 actual protocol used. Each section ends with an additional 299 considerations section which explains why specific protocols may or 300 may not be used and also gives some information regarding 301 capabilities which are not possible today due to bugs or lack of ease 302 of use. 304 1.6. Definitions 306 RFC 2119 Keywords 308 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 309 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 310 in this document are to be interpreted as described in [RFC2119]. 312 The use of the RFC 2119 keywords is an attempt, by the editor, to 313 assign the correct requirement levels ("MUST", "SHOULD", 314 "MAY"...). It must be noted that different organizations, 315 operational environments, policies and legal environments will 316 generate different requirement levels. 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 card key badges have access 364 to any of the physical locations that contain critical network 365 infrastructure devices. These card-key systems keep track of who 366 accessed which location and at what time. 368 All console access is always password protected and the login time is 369 set to time out after a specified amount of inactivity - typically 370 between 3-10 minutes. Individual users are authentication to get 371 basic access. For privileged (i.e. enable) access, a second 372 authentication step needs to be completed. Typically all console 373 access is provided via an out-of-band (OOB) management infrastructure 374 which is discussed in the section on OOB management. 376 2.1.3. Security Services 378 The following security services are offered through the use of the 379 practices described in the previous section: 381 o User Authentication - All individuals who have access to the 382 physical facility are authenticated. Console access is 383 authenticated. 385 o User Authorization - An authenticated individual has implicit 386 authorization to perform commands on the device. Console access 387 is usually granted via at least two privilege levels: 388 authorization for performing a basic set of commands vs 389 authorization for performing all commands. 391 o Data Origin Authentication - Not applicable 393 o Access Control - Not applicable 395 o Data Integrity - Not applicable 397 o Data Confidentiality - Not applicable 399 o Auditing / Logging - All access to the physical locations of the 400 infrastructure equipment is logged via electronic card-key 401 systems. All console access is logged (refer to the OOB 402 management section for more details) 404 o DoS Mitigation - Not applicable 406 2.1.4. Additional Considerations 408 Physical security is relevant to operational security practices as 409 described in this document mostly from a console access perspective. 410 Most ISPs provide console access via an OOB management infrastructure 411 which is discussed in the OOB management section of this document. 413 The physical and logical authentication and logging systems should be 414 run independently of each other and reside in different physical 415 locations. These systems need to be secured to ensure that they 416 themselves will not be compromised which could give the intruder 417 valuable authentication and logging information. 419 Social engineering plays a big role in many physical access 420 compromises. Most ISPs have set up training classes and awareness 421 programs to educate company personnel to deny physical access to 422 people who are not properly authenticated or authorized to have 423 physical access to critical infrastructure devices. 425 2.2. Device In-Band Management 427 In-band management is generally considered to be device access where 428 the control traffic takes the same data path as the data which 429 traverses the network. In many environments, device management for 430 layer 2 and layer 3 infrastructure devices is deployed as part of an 431 out-of-band management infrastructure although there are some 432 instances where it is deployed in-band as well. Presently, the 433 mechanisms used for in-band management are via virtual terminal 434 access (i.e. Telnet or SSH), SNMP, or HTTP. In all large ISPs that 435 were interviewed, HTTP management is never used and is explicitly 436 disabled. Note that file transfer protocols (TFTP, FTP, SCP) will be 437 covered in the 'Software Upgrades and Configuration Integrity/ 438 Validation' section. 440 2.2.1. Threats / Attacks 442 For in-band device management, passive attacks are possible if 443 someone has the capability to intercept data between the management 444 device and the managed device. The threat is possible if a single 445 infrastructure device is somehow compromised and can act as a network 446 sniffer or if it is possible to insert a new device which acts as a 447 network sniffer. 449 Active attacks are possible for both on-path and off-path scenarios. 450 For on-path active attacks, the situation is the same as for a 451 passive attack, where either a device has to already be compromised 452 or a device can be inserted into the path. For off-path active 453 attacks, the attack is generally limited to message insertion or 454 modification. 456 2.2.1.1. Confidentiality Violations 458 Confidentiality violations can occur when a miscreant intercepts 459 confidential data that has been sent in cleartext. This includes 460 interception of usernames and passwords with which an intruder can 461 obtain unauthorized access to network devices. It can also include 462 other information such as logging or configuration information if an 463 administrator is remotely viewing local logfiles or configuration 464 information. 466 2.2.1.2. Offline Cryptographic Attacks 468 If username/password information was encrypted but the cryptographic 469 mechanism used made it easy to capture data and break the encryption 470 key, the device management traffic could be compromised. The traffic 471 would need to be captured either by eavesdropping on the network or 472 by being able to divert traffic to a malicious user. 474 2.2.1.3. Replay Attacks 476 For a replay attack to be successful, in-band management traffic 477 would need to first be captured either on-path or diverted to an 478 attacker to later be replayed to the intended recipient. 480 2.2.1.4. Message Insertion/Deletion/Modification 482 Data can be manipulated by someone in control of intermediary hosts. 483 Forging data is also possible with IP spoofing, where a remote host 484 sends out packets which appear to come from another, trusted host. 486 2.2.1.5. Man-In-The-Middle 488 A man-in-the-middle attack attacks the identity of a communicating 489 peer rather than the data stream itself. The attacker intercepts 490 traffic that is sent from an in-band management system to the 491 networking infrastructure device and traffic that is sent from the 492 network infrastructure device to the in-band management system. 494 2.2.2. Security Practices 496 All in-band management access to layer 2 and layer 3 devices is 497 authenticated. The user authentication and authorization is 498 typically controlled by a AAA server (i.e. RADIUS and/or TACACS+). 499 Credentials used to determine the identity of the user vary from 500 static username/password to one-time username/password scheme such as 501 Secure-ID. Static username/passwords are expired after a specified 502 period of time, usually 30 days. Every authenticated entity via AAA 503 is an individual user for greater granularity of control. In some 504 deployments, the AAA servers used for in-band management 505 authentication/authorization/accounting are on separate out-of-band 506 networks to provide a demarcation for any other authentication 507 functions. 509 For backup purposes, there is often a single local database entry for 510 authentication which is known to a very limited set of key personnel. 511 It is usually the highest privilege level username/password 512 combination, which in most cases is the same across all devices. 513 This local device password is routinely regenerated once every 2-3 514 months and is also regenerated immediately after an employee who had 515 access to that password leaves the company or is no longer authorized 516 to have knowledge of that password. 518 Each individual user in the AAA database is configured with specific 519 authorization capability. Specific commands are either individually 520 denied or permitted depending on the capability of the device to be 521 accessed. Multiple privilege levels are deployed. Most individuals 522 are authorized with basic authorization to perform a minimal set of 523 commands while a subset of individuals are authorized to perform more 524 privileged commands. Securing the AAA server is imperative and 525 access to the AAA server itself is strictly controlled. When an 526 individual leaves the company, his/her AAA account is immediately 527 deleted and the TACACS/RADIUS shared secret is reset for all devices. 529 SSH is always used for virtual terminal access to provide for an 530 encrypted communication channel. There are exceptions due to 531 equipment limitations which are described in the additional 532 considerations section. 534 If SNMP is used for in-band management, it is for read queries only 535 and restricted to specific hosts. If possible, the view is also 536 restricted to only send the information that the management station 537 needs rather than expose the entire configuration file with the read- 538 only SNMP community. The community strings are carefully chosen to 539 be difficult to crack and there are procedures in place to change 540 these community strings between 30-90 days. If systems support two 541 SNMP community strings, the old string is replaced by first 542 configuring a second newer community string and then migrating over 543 from the currently used string to the newer one. Most large ISPs 544 have multiple SNMP systems accessing their routers so it takes more 545 then one maintenance period to get all the strings fixed in all the 546 right systems. SNMP RW is not used and disabled by configuration. 548 Access control is strictly enforced for infrastructure devices by 549 using stringent filtering rules. A limited set of IP addresses are 550 allowed to initiate connections to the infrastructure devices and are 551 specific to the services which they are to limited to (i.e. SSH and 552 SNMP). 554 All in-band device management access is audited and any violations 555 trigger alarms which initiate automated email, pager and/or telephone 556 notifications. AAA servers keeps track of the authenticated entity 557 as well as all the commands that were carried out on a specific 558 device. Additionally, the device itself logs any access control 559 violations (i.e. if an SSH request comes in from an IP address which 560 is not explicitly permitted, that event is logged so that the 561 offending IP address can be tracked down and investigations made as 562 to why it was trying to access a particular infrastructure device) 564 2.2.3. Security Services 566 The following security services are offered through the use of the 567 practices described in the previous section: 569 o User Authentication - All individuals are authenticated via AAA 570 services. 572 o User Authorization - All individuals are authorized via AAA 573 services to perform specific operations once successfully 574 authenticated. 576 o Data Origin Authentication - Management traffic is strictly 577 filtered to allow only specific IP addresses to have access to the 578 infrastructure devices. This does not alleviate risk from spoofed 579 traffic. Using SSH for device access ensures that noone can spoof 580 the traffic during the SSH session. 582 o Access Control - In-band management traffic is filtered to allow 583 only specific IP addresses to have access to the infrastructure 584 devices. 586 o Data Integrity - Using SSH provides data integrity and ensures 587 that no one has altered the management data in transit. 589 o Data Confidentiality - Using SSH provides data confidentiality. 591 o Auditing / Logging - Using AAA provides an audit trail for who 592 accessed which device and which operations were performed. 594 o DoS Mitigation - Using packet filters to allow only specific IP 595 addresses to have access to the infrastructure devices. This 596 limits but does not prevent spoofed DoS attacks directed at an 597 infrastructure device. Often OOB management is used to lower that 598 risk. 600 2.2.4. Additional Considerations 602 Password selection for any in-band device management protocol used is 603 critical to ensure that the passwords are hard to guess or break 604 using a brute-force attack. 606 IPsec is considered too difficult to deploy and the common protocol 607 to provide for confidential in-band management access is SSH. There 608 are exceptions for using SSH due to equipment limitations since SSH 609 may not be supported on legacy equipment. Also, in the case where 610 the SSH key is stored on a route processor card, a re-keying of SSH 611 would be required whenever the route processor card needs to be 612 swapped. Some providers feel that this operational impact exceeds 613 the security necessary and instead use Telnet from trusted inside 614 hosts (called 'jumphosts' or 'bastion hosts') to manage those 615 devices. An individual would first SSH to the jumphost and then 616 Telnet from the jumphost to the actual infrastructure device, fully 617 understanding that any passwords will be sent in the clear between 618 the jumphost and the device it is connecting to. All authentication 619 and authorization is still carried out using AAA servers. 621 In instances where Telnet access is used, the logs on the AAA servers 622 are more verbose and more attention is paid to them to detect any 623 abnormal behavior. The jumphosts themselves are carefully controlled 624 machines and usually have limited access. Note that Telent is NEVER 625 allowed to an infrastructure device except from specific jumphosts; 626 i.e. packet filters are used to ensure that Telnet is only allowed 627 from specific IP addresses. 629 With thousands of devices to manage, some ISPs have created automated 630 mechanisms to authenticate to devices. Kerberos is used to automate 631 the authentication process. An individual would first log in to a 632 Kerberized UNIX server using SSH and generate a Kerberos 'ticket'. 633 This 'ticket' is generally set to have a lifespan of 10 hours and is 634 used to automatically authenticate the individual to the 635 infrastructure devices. 637 In instances where SNMP is used, some legacy devices only support 638 SNMPv1 which then requires the provider to mandate its use across all 639 infrastructure devices for operational simplicity. SNMPv2 is 640 primarily deployed since it is easier to set up than v3. 642 2.3. Device Out-of-Band Management 644 Out-of-band management is generally considered to be device access 645 where the control traffic takes a separate path as the data which 646 traverses the network. Console access is always architected via an 647 OOB network. SNMP management is also usually carried out via that 648 same OOB network infrastructure. Note that many of the security 649 concerns and practices are the same for OOB management and in-band 650 management. Most ISPs prefer an OOB management system since access 651 to the devices which make up this management network are more 652 vigilantly protected and considered to be less susceptible to 653 malicious activity. 655 2.3.1. Threats / Attacks 657 For OOB device management, passive attacks are possible if someone 658 has the capability to intercept data between the management device 659 and the managed device. The threat is possible if a single 660 infrastructure device is somehow compromised and can act as a network 661 sniffer or if it is possible to insert a new device which acts as a 662 network sniffer. 664 Active attacks are possible for both on-path and off-path scenarios. 665 For on-path active attacks, the situation is the same as for a 666 passive attack, where either a device has to already be compromised 667 or a device can be inserted into the path. For off-path active 668 attacks, the attack is generally limited to message insertion or 669 modification. 671 2.3.1.1. Confidentiality Violations 673 Confidentiality violations can occur when a miscreant intercepts any 674 of the OOB management data that has been sent in cleartext. This 675 includes interception of usernames and passwords with which an 676 intruder can obtain unauthorized access to network devices. It can 677 also include other information such as logging or configuration 678 information if an administrator is remotely viewing local logfiles or 679 configuration information. 681 2.3.1.2. Offline Cryptographic Attacks 683 If username/password information was encrypted but the cryptographic 684 mechanism used made it easy to capture data and break the encryption 685 key, the OOB management traffic could be compromised. The traffic 686 would need to be captured either by eavesdropping on the network or 687 by being able to divert traffic to a malicious user. 689 2.3.1.3. Replay Attacks 691 For a replay attack to be successful, the OOB management traffic 692 would need to first be captured either on-path or diverted to an 693 attacker to later be replayed to the intended recipient. 695 2.3.1.4. Message Insertion/Deletion/Modification 697 Data can be manipulated by someone in control of intermediary hosts. 698 Forging data is also possible with IP spoofing, where a remote host 699 sends out packets which appear to come from another, trusted host. 701 2.3.1.5. Man-In-The-Middle 703 A man-in-the-middle attack attacks the identity of a communicating 704 peer rather than the data stream itself. The attacker intercepts 705 traffic that is sent from an OOB management system to the networking 706 infrastructure device and traffic that is sent from the network 707 infrastructure device to the OOB management system. 709 2.3.2. Security Practices 711 OOB is done via a terminal server at each location. SSH access is 712 used to get to the terminal server from where sessions to the devices 713 are initiated. Dial-in access is deployed as a backup if the network 714 is not available however, it is common to use dial-back, encrypting 715 modems and/or one-time-password (OTP) modems to avoid the security 716 weaknesses of plain dial-in access. 718 All OOB management access to layer 2 and layer 3 devices is 719 authenticated. The user authentication and authorization is 720 typically controlled by a AAA server (i.e. RADIUS and/or TACACS+). 721 Credentials used to determine the identity of the user vary from 722 static username/password to one-time username/password scheme such as 723 Secure-ID. Static username/passwords are expired after a specified 724 period of time, usually 30 days. Every authenticated entity via AAA 725 is an individual user for greater granularity of control. Note that 726 often the AAA server used for OOB management authentication is a 727 separate physical device from the AAA server used for in-band 728 management user authentication. 730 For backup purposes, there is often a single local database entry for 731 authentication which is known to a very limited set of key personnel. 732 It is usually the highest privilege level username/password 733 combination, which in most cases is the same across all devices. 734 This local device password is routinely regenerated once every 2-3 735 months and is also regenerated immediately after an employee who had 736 access to that password leaves the company or is no longer authorized 737 to have knowledge of that password. 739 Each individual user in the AAA database is configured with specific 740 authorization capability. Specific commands are either individually 741 denied or permitted depending on the capability of the device to be 742 accessed. Multiple privilege levels are deployed. Most individuals 743 are authorized with basic authorization to perform a minimal set of 744 commands while a subset of individuals are authorized to perform more 745 privileged commands. 747 Some OOB management functions are performed using command line 748 interface (CLI) scripting. In these scenarios, a dedicated user is 749 used for the identity in scripts that perform CLI scripting. Once 750 authenticated, these scripts control which commands are legitimate 751 depending on authorization rights of the authenticated individual. 753 SSH is always used for virtual terminal access to provide for an 754 encrypted communication channel. There are exceptions due to 755 equipment limitations which are described in the additional 756 considerations section. 758 If SNMP is used for OOB management, it is for read queries only and 759 restricted to specific hosts. The community strings are carefully 760 chosen to be difficult to crack and there are procedures in place to 761 change these community strings between 30-90 days. If systems 762 support two SNMP strings, a second new string is set and then migrate 763 over from the 1st to the 2nd. Most large ISPs have multiple SNMP 764 systems accessing their routers so it takes more then one maintenance 765 period to get all the strings fixed in all the right systems. SNMP 766 RW is not used and disabled by configuration. 768 Access control is strictly enforced for infrastructure devices by 769 using stringent filtering rules. A limited set of IP addresses are 770 allowed to initiate connections to the infrastructure devices and are 771 specific to the services which they are to limited to (i.e. SSH and 772 SNMP). 774 All OOB device management access is audited. The AAA server keeps 775 track of the authenticated entity as well as all the commands that 776 were carried out on a specific device. Additionally, the device 777 itself logs any access control violations (i.e. if an SSH request 778 comes in from an IP address which is not explicitly permitted, that 779 event is logged so that the offending IP address can be tracked down 780 and investigations made as to why it was trying to access a 781 particular infrastructure device) 783 2.3.3. Security Services 785 The security services offered for device OOB management are nearly 786 identical to those of device in-band management. Due to the critical 787 nature of controlling and limiting device access, many ISPs feel that 788 physically separating the management traffic from the normal customer 789 data traffic will provide an added level of risk mitigation and limit 790 the potential attack vectors. For OOB management, the security 791 services offered through the use of the practices described in the 792 previous section are: 794 o User Authentication - All individuals are authenticated via AAA 795 services. 797 o User Authorization - All individuals are authorized via AAA 798 services to perform specific operations once successfully 799 authenticated. 801 o Data Origin Authentication - Management traffic is strictly 802 filtered to allow only specific IP addresses to have access to the 803 infrastructure devices. This does not alleviate risk from spoofed 804 traffic. Using SSH for device access ensures that noone can spoof 805 the traffic during the SSH session. 807 o Access Control - In-band management traffic is filtered to allow 808 only specific IP addresses to have access to the infrastructure 809 devices. 811 o Data Integrity - Using SSH provides data integrity and ensures 812 that noone has altered the management data in transit. 814 o Data Confidentiality - Using SSH provides data confidentiality. 816 o Auditing / Logging - Using AAA provides an audit trail for who 817 accessed which device and which operations were performed. 819 o DoS Mitigation - Using packet filters to allow only specific IP 820 addresses to have access to the infrastructure devices. This 821 limits but does not prevent spoofed DoS attacks directed at an 822 infrastructure device. However, the risk is lowered by using a 823 separate physical network for management purposes. 825 2.3.4. Additional Considerations 827 Password selection for any OOB device management protocol used is 828 critical to ensure that the passwords are hard to guess or break 829 using a brute-force attack. 831 IPsec is considered too difficult to deploy and the common protocol 832 to provide for confidential OOB management access is SSH. There are 833 exceptions for using SSH due to equipment limitations since SSH may 834 not be supported on legacy equipment. In some cases changing the 835 hostname of a device requires an SSH rekey event since the key is 836 based on some combination of host name, MAC address and time. Also, 837 in the case where the SSH key is stored on a route processor card, a 838 re-keying of SSH would be required whenever the route processor card 839 needs to be swapped. Some providers feel that some of these 840 operational impacts exceed the security necessary and instead use 841 Telnet from trusted inside hosts (called 'jumphosts') to manage those 842 device. An individual would first SSH to the jumphost and then 843 Telnet from the jumphost to the terminal server before logging in to 844 the device console. All authentication and authorization is still 845 carried out using AAA servers. 847 In instances where Telnet access is used, the logs on the AAA servers 848 are more verbose and more attention is paid to them to detect any 849 abnormal behavior. The jumphosts themselves are carefully controlled 850 machines and usually have limited access. Note that Telent is NEVER 851 allowed to an infrastructure device except from specific jumphosts; 852 i.e. packet filters are used at the console server and/or 853 infrastructure device to ensure that Telnet is only allowed from 854 specific IP addresses. 856 In instances where SNMP is used, some legacy devices only support 857 SNMPv1 which then requires the provider to mandate its use across all 858 infrastructure devices for operational simplicity. SNMPv2 is 859 primarily deployed since it is easier to set up than v3. 861 2.4. Data Path 863 This section refers to how traffic is handled which traverses the 864 network infrastructure device. The primary goal of ISPs is to 865 forward customer traffic. However, due to the large amount of 866 malicious traffic that can cause DoS attacks and render the network 867 unavailable, specific measures are sometimes deployed to ensure the 868 availability to forward legitimate customer traffic. 870 2.4.1. Threats / Attacks 872 Any data traffic can potentially be attack traffic and the challenge 873 is to detect and potentially stop forwarding any of the malicious 874 traffic. The deliberately sourced attack traffic can consist of 875 packets with spoofed source and/or destination addresses or any other 876 malformed packet which mangle any portion of a header field to cause 877 protocol-related security issues (such as resetting connections, 878 causing unwelcome ICPM redirects, creating unwelcome IP options or 879 packet fragmentations). 881 2.4.2. Security Practices 883 Filtering and rate limiting are the primary mechanism to provide risk 884 mitigation of malicious traffic rendering the ISP services 885 unavailable. However, filtering and rate limiting of data path 886 traffic is deployed in a variety of ways depending on how automated 887 the process is and what the capabilities and performance limitations 888 of existing deployed hardware are. 890 The ISPs which do not have performance issues with their equipment 891 follow BCP38 [BCP38] and BCP84 [BCP84] guidelines. Null routes and 892 black-hole triggered routing [BHTR] are used to deter any detected 893 malicious traffic streams. Most ISPs consider layer 4 filtering 894 useful but it is only implemented if performance limitations allow 895 for it. Layer 4 filtering is typically only when no other option 896 exists since it does pose a large administrative overhead and ISPs 897 are very much opposed to acting as the Internet firewall. Netflow is 898 used for tracking traffic flows but there is some concern whether 899 sampling is good enough to detect malicious behavior. 901 Unicast RPF is not consistently implemented. Some ISPs are in 902 process of doing so while other ISPs think that the perceived benefit 903 of knowing that spoofed traffic comes from legitimate addresses are 904 not worth the operational complexity. Some providers have a policy 905 of implementing uRPF at link speeds of DS3 and below. 907 2.4.3. Security Services 909 o User Authentication - Not applicable 911 o User Authorization - Not applicable 913 o Data Origin Authentication - When IP address filtering per BCP38 914 and uRPF are deployed at network edges it can ensure that any 915 spoofed traffic comes from at least a legitimate IP address and 916 can be tracked. 918 o Access Control - IP address filtering and layer 4 filtering is 919 used to deny forbidden protocols and limit traffic destined for 920 infrastructure device itself. 922 o Data Integrity - Not applicable 924 o Data Confidentiality - Not applicable 926 o Auditing / Logging - Filtering exceptions are logged for potential 927 attack traffic. 929 o DoS Mitigation - Black-hole triggered filtering and rate-limiting 930 are used to limit the risk of DoS attacks. 932 2.4.4. Additional Considerations 934 For layer 2 devices, MAC address filtering and authentication is not 935 used. This is due to the problems it can cause when troubleshooting 936 networking issues. Port security becomes unmanageable at a large 937 scale where 1000s of switches are deployed. 939 Rate limiting is used by some ISPs although other ISPs believe it is 940 not really useful since attackers are not well behaved and it doesn't 941 provide any operational benefit over the complexity. Some ISPs feel 942 that rate limiting can also make an attacker's job easier by 943 requiring the attacker to send less traffic to starve legitimate 944 traffic that is part of a rate limiting scheme. Rate limiting may be 945 improved by developing flow-based rate-limiting capabilities with 946 filtering hooks. This would improve the performance as well as the 947 granularity over current capabilities. 949 Lack of consistency regarding the ability to filter, especially with 950 respect to performance issues cause some ISPs to not implement BCP38 951 guidelines for ingress filtering. One such example is at edge boxes 952 where you have up to 1000 T1's connecting into a router with an OC-12 953 uplink. Some deployed devices experience a large performance impact 954 with filtering which is unacceptable for passing customer traffic 955 through. Where performance is not an issue, the ISPs make a tradeoff 956 between management versus risk. 958 2.5. Routing Control Plane 960 The routing control plane deals with all the traffic which is part of 961 establishing and maintaining routing protocol information. 963 2.5.1. Threats / Attacks 965 Attacks on the routing control plane can be both from passive or 966 active sources. Passive attacks are possible if someone has the 967 capability to intercept data between the communicating routing peers. 968 This can be accomplished if a single routing peer is somehow 969 compromised and can act as a network sniffer or if it is possible to 970 insert a new device which acts as a network sniffer. 972 Active attacks are possible for both on-path and off-path scenarios. 973 For on-path active attacks, the situation is the same as for a 974 passive attack, where either a device has to already be compromised 975 or a device can be inserted into the path. This may lead to an 976 attacker impersonating a legitimate routing peer and exchanging 977 routing information. Unintentional active attacks are more common 978 due to configuration errors, which cause legitimate routing peers to 979 feed invalid routing information to other neighboring peers. 981 For off-path active attacks, the attacks are generally limited to 982 message insertion or modification which can divert traffic to 983 illegitimate destinations and cause traffic to never reach its 984 intended destination. 986 2.5.2. Confidentiality Violations 988 Confidentiality violations can occur when a miscreant intercepts any 989 of the routing update traffic. This is becoming more of a concern 990 because many ISPs are classifying addressing schemes and network 991 topologies as private and proprietary information. It is also a 992 concern because the routing protocol packets contain information that 993 may show ways in which routing sessions could be spoofed or hijacked. 994 This in turn could lead into a man-in-the-middle attack where the 995 miscreants can insert themselves into the traffic path or divert the 996 traffic path and violate the confidentiality of user data. 998 2.5.3. Offline Cryptographic Attacks 1000 If any cryptographic mechanism was used to provide for data integrity 1001 and confidentiality, an offline cryptographic attack could 1002 potentially compromise the data. The traffic would need to be 1003 captured either by eavesdropping on the network or by being able to 1004 divert traffic to a malicious user. Note that by using 1005 cryptographically protected routing information, the latter would 1006 require the cryptographic key to already be compromised anyway so 1007 this attack is only feasible if a device was able eavesdrop and 1008 capture the cryptographically protected routing information. 1010 2.5.4. Replay Attacks 1012 For a replay attack to be successful, the routing control plane 1013 traffic would need to first be captured either on-path or diverted to 1014 an attacker to later be replayed to the intended recipient. 1016 2.5.5. Message Insertion/Deletion/Modification 1018 Routing control plane traffic can be manipulated by someone in 1019 control of intermediate hosts. In addition, traffic can be injected 1020 by forging IP addresses, where a remote router sends out packets 1021 which appear to come from another, trusted router. If enough traffic 1022 is injected to be processed by limited memory routers it can cause a 1023 DoS attack. 1025 2.5.6. Man-In-The-Middle 1027 A man-in-the-middle attack attacks the identity of a communicating 1028 peer rather than the data stream itself. The attacker intercepts 1029 traffic that is sent from one routing peer to the other and 1030 communicates on behalf of one of the peers. This can lead to 1031 diversion of the user traffic to either an unauthorized receiving 1032 party or cause legitimate traffic to never reach its intended 1033 destination. 1035 2.5.7. Security Practices 1037 Securing the routing control plane takes many features which are 1038 generally deployed as a system. MD5 authentication is used by some 1039 ISPs to validate the sending peer and to ensure that the data in 1040 transit has not been altered. Some ISPs only deploy MD5 1041 authentication at customer's request. Additional sanity checks to 1042 ensure with reasonable certainty that the received routing update was 1043 originated by a valid routing peer include route filters and the 1044 Generalized TTL Security Mechanism (GTSM) feature [GTSM] (sometimes 1045 also referred to as the TTL-Hack). Note that validating whether a 1046 legitimate peer has the authority to send the contents of the routing 1047 update is a difficult problem that needs yet to be resolved. 1049 In the case of BGP routing, a variety of policies are deployed to 1050 limit the propagation of invalid routing information. These include: 1051 incoming and outgoing prefix filters for BGP customers, incoming and 1052 outgoing prefix filters for peers and upstream neighbors, incoming 1053 AS-PATH filter for BGP customers, outgoing AS-PATH filter towards 1054 peers and upstream neighbors, route dampening and rejecting selected 1055 attributes and communities. Consistency between these policies 1056 varies greatly although there is a trend to start depending on AS- 1057 PATH filters because they are much more manageable than the large 1058 numbers of prefix filters that would need to be maintained. Many 1059 ISPs also do not propagate interface IP addresses to further reduce 1060 attack vectors on routers and connected customers. 1062 2.5.8. Security Services 1064 o User Authentication - Not applicable 1066 o User Authorization - Not applicable 1068 o Data Origin Authentication - By using MD5 authentication and/or 1069 the TTL-hack a routing peer can be reasonably certain that traffic 1070 originated from a valid peer. 1072 o Access Control - Route filters, AS-PATH filters and prefix limits 1073 are used to control access to specific parts of the network. 1075 o Data Integrity - By using MD5 authentication a peer can be 1076 reasonably certain that the data has not been modified in transit 1077 but there is no mechanism to prove the validity of the routing 1078 information itself. 1080 o Data Confidentiality - Not implemented 1081 o Auditing / Logging - Filter exceptions are logged. 1083 o DoS Mitigation - Many DoS attacks are mitigated using a 1084 combination of techniques including: MD5 authentication, the GTSM 1085 feature, filtering routing advertisements to bogons and filtering 1086 routing advertisements to one's own network. 1088 2.5.9. Additional Considerations 1090 So far the primary concern to secure the routing control plane has 1091 been to validate the sending peer and to ensure that the data in 1092 transit has not been altered. Although MD5 routing protocol 1093 extensions have been implemented which can provide both services, 1094 they are not consistently deployed amongst ISPs. Two major 1095 deployment concerns have been implementation issues where both 1096 software bugs and the lack of graceful re-keying options have caused 1097 significant network down times. Also, some ISPs express concern that 1098 deploying MD5 authentication will itself be a worse DoS attack victim 1099 and prefer to use a combination of other risk mitigation mechanisms 1100 such as GTSM and route filters. 1102 Route filters are used to limit what routes are believed from a valid 1103 peer. Packet filters are used to limit which systems can appear as a 1104 valid peer. Due to the operational constraints of maintaining large 1105 prefix filter lists, many ISPs are starting to depend on BGP AS-PATH 1106 filters to/from their peers and upstream neighbors. Additionally, 1107 some large ISPs require that routes be registered in an Internet 1108 Routing Registry [IRR] which can then be part of the RADB - a public 1109 registry of routing information for networks in the Internet that can 1110 be used to generate filter lists. Some ISPs, especially in europe, 1111 require registered routes before agreeing to become an eBGP peer with 1112 someone. 1114 IPsec is not deployed since the operational management aspects of 1115 ensuring interoperability and reliable configurations is too complex 1116 and time consuming to be operationally viable. There is also limited 1117 concern to the confidentiality of the routing information. The 1118 integrity and validity of the updates are of much greater concern. 1120 There is concern for manual or automated actions which introduce new 1121 routes and can affect the entire routing domain. 1123 2.6. Software Upgrades and Configuration Integrity / Validation 1125 Software upgrades and configuration changes are usually performed as 1126 part of either in-band or OOB management functions. However, there 1127 are additional considerations to be taken into account which are 1128 enumerated in this section. 1130 2.6.1. Threats / Attacks 1132 Attacks performed on system software and configurations can be both 1133 from passive or active sources. Passive attacks are possible if 1134 someone has the capability to intercept data between the network 1135 infrastructure device and the system which is downloading or 1136 uploading the software or configuration information. This can be 1137 accomplished if a single infrastructure device is somehow compromised 1138 and can act as a network sniffer or if it is possible to insert a new 1139 device which acts as a network sniffer. 1141 Active attacks are possible for both on-path and off-path scenarios. 1142 For on-path active attacks, the situation is the same as for a 1143 passive attack, where either a device has to already be compromised 1144 or a device can be inserted into the path. For off-path active 1145 attacks, the attacks are generally limited to message insertion or 1146 modification where the attacker may wish to load illegal software or 1147 configuration files to an infrastructure device. 1149 2.6.2. Confidentiality Violations 1151 Confidentiality violations can occur when a miscreant intercepts any 1152 of the software image or configuration information. The software 1153 image may give an indication of exploits which the device is 1154 vulnerable to while the configuration information can inadvertently 1155 lead attackers to identify critical infrastructure IP addresses and 1156 passwords. 1158 2.6.3. Offline Cryptographic Attacks 1160 If any cryptographic mechanism was used to provide for data integrity 1161 and confidentiality, an offline cryptographic attack could 1162 potentially compromise the data. The traffic would need to be 1163 captured either by eavesdropping on the network or by being able to 1164 divert traffic to a malicious user. 1166 2.6.4. Replay Attacks 1168 For a replay attack to be successful, the software image or 1169 configuration file would need to first be captured either on-path or 1170 diverted to an attacker to later be replayed to the intended 1171 recipient. 1173 2.6.5. Message Insertion/Deletion/Modification 1175 Software images and configuration files can be manipulated by someone 1176 in control of intermediate hosts. By forging an IP address and 1177 impersonating a valid host which can download software images or 1178 configuration files, invalid files can be downloaded to an 1179 infrastructure device. An invalid software image or configuration 1180 file can cause a device to hang and become inoperable. Spoofed 1181 configuration files can be hard to detect, especially when the only 1182 added command is to allow a miscreant access to that device by 1183 entering a filter allowing a specific host access and configuring a 1184 local username/password database entry for authentication to that 1185 device. 1187 2.6.6. Man-In-The-Middle 1189 A man-in-the-middle attack attacks the identity of a communicating 1190 peer rather than the data stream itself. The attacker intercepts 1191 traffic that is sent between the infrastructure device and the host 1192 used to upload/download the system image or configuration file. He/ 1193 she can then act on behalf of one or both of these systems. 1195 If an attacker obtained a copy of the software image being deployed, 1196 he could potentially exploit a known vulnerability and gain access to 1197 the system. From a captured configuration file, he could obtain 1198 confidential network topology information or even more damaging 1199 information if any of the passwords in the configuration file were 1200 not encrypted. 1202 2.6.7. Security Practices 1204 Images and configurations are stored on specific hosts which have 1205 limited access. All access and activity relating to these hosts are 1206 authenticated and logged via AAA services. When uploaded/downloading 1207 any system software or configuration files, either TFTP, FTP or SCP 1208 can be used. Where possible, SCP is used to secure the data transfer 1209 and FTP is generally never used. All SCP access is username/password 1210 authenticated but since this requires an interactive shell, most ISPs 1211 will use shared key authentication to avoid the interactive shell. 1212 While TFTP access does not have any security measures, it is still 1213 widely used especially in OOB management scenarios. Some ISPs 1214 implement IP-based restriction on the TFTP server while some custom 1215 written TFTP servers will support MAC-based authentication. The MAC- 1216 based authentication is more common when using TFTP to bootstrap 1217 routers remotely using TFTP. 1219 In most environments scripts are used for maintaining the images and 1220 configurations of a large number of routers. To ensure the integrity 1221 of the configurations, every hour the configuration files are polled 1222 and compared to the previously polled version to find discrepancies. 1223 In at least one environment these tools are Kerberized to take 1224 advantage of automated authentication (not confidentiality). 1226 Filters are used to limit access to uploading/downloading 1227 configuration files and system images to specific IP addresses and 1228 protocols. 1230 The software images perform CRC-checks and the system binaries use 1231 the MD5 algorithm to validate integrity. Many ISPs expressed 1232 interest in having software image integrity validation based on the 1233 MD5 algorithm for enhanced security. 1235 In all configuration files, most passwords are stored in an 1236 obfuscated format. This includes passwords for user authentication, 1237 MD5 shared secrets, AAA server shared secrets, NTP shared secrets, 1238 etc. For older software which may not support this functionality, 1239 configuration files may contain some passwords in readable format. 1240 Most ISPs mitigate any risk of password compromise by either storing 1241 these configuration files without the password lines or by requiring 1242 authenticated and authorized access to the configuration files which 1243 are stored on protected OOB management devices. 1245 Automated security validation is performed on infrastructure devices 1246 using nmap and nessus to ensure valid configuration against many of 1247 the well-known attacks. 1249 2.6.8. Security Services 1251 o User Authentication - All users are authenticated before being 1252 able to download/upload any system images or configuration files. 1254 o User Authorization - All authenticated users are granted specific 1255 privileges to download or upload system images and/or 1256 configuration files. 1258 o Data Origin Authentication - Filters are used to limit access to 1259 uploading/downloading configuration files and system images to 1260 specific IP addresses. 1262 o Access Control - Filters are used to limit access to uploading/ 1263 downloading configuration files and system images to specific IP 1264 addresses and protocols. 1266 o Data Integrity - All systems use either a CRC-check or MD5 1267 authentication to ensure data integrity. 1269 o Data Confidentiality - If the SCP protocol is used then there is 1270 confidentiality of the downloaded/uploaded configuration files and 1271 system images. 1273 o Auditing / Logging - All access and activity relating to 1274 downloading/uploading system images and configuration files are 1275 logged via AAA services and filter exception rules. 1277 o DoS Mitigation - TBD 1279 2.6.9. Additional Considerations 1281 Where the MD5 algorithm is not used to perform data integrity 1282 checking of software images and configuration files, ISPs have 1283 expressed an interest in having this functionality. IPsec is 1284 considered too cumbersome and operationally difficult to use for data 1285 integrity and confidentiality. 1287 2.7. Logging Considerations 1289 Although logging is part of all the previous sections, it is 1290 important enough to be covered as a separate item. The main issues 1291 revolve around what gets logged, how long are logs kept and what 1292 mechanisms are used to secure the logged information while it is in 1293 transit and while it is stored. 1295 2.7.1. Threats / Attacks 1297 Attacks on the logged data can be both from passive or active 1298 sources. Passive attacks are possible if someone has the capability 1299 to intercept data between the recipient logging server and the device 1300 the logged data originated from. This can be accomplished if a 1301 single infrastructure device is somehow compromised and can act as a 1302 network sniffer or if it is possible to insert a new device which 1303 acts as a network sniffer. 1305 Active attacks are possible for both on-path and off-path scenarios. 1306 For on-path active attacks, the situation is the same as for a 1307 passive attack, where either a device has to already be compromised 1308 or a device can be inserted into the path. For off-path active 1309 attacks, the attacks are generally limited to message insertion or 1310 modification which can alter the logged data to keep any compromise 1311 from being detected or to destroy any evidence which could be used 1312 for criminal prosecution. 1314 2.7.1.1. Confidentiality Violations 1316 Confidentiality violations can occur when a miscreant intercepts any 1317 of the logging data which is in transit on the network. This could 1318 lead to privacy violations if some of the logged data has not been 1319 sanitized to disallow any data that could be a violation of privacy 1320 to be included in the logged data. 1322 2.7.1.2. Offline Cryptographic Attacks 1324 If any cryptographic mechanism was used to provide for data integrity 1325 and confidentiality, an offline cryptographic attack could 1326 potentially compromise the data. The traffic would need to be 1327 captured either by eavesdropping on the network or by being able to 1328 divert traffic to a malicious user. 1330 2.7.1.3. Replay Attacks 1332 For a replay attack to be successful, the logging data would need to 1333 first be captured either on-path or diverted to an attacker and later 1334 replayed to the recipient. [is reply handled by syslog protocol?] 1336 2.7.1.4. Message Insertion/Deletion/Modification 1338 Logging data could be injected, deleted or modified by someone in 1339 control of intermediate hosts. Logging data can also be injected by 1340 forging packets from either legitimate or illegitimate IP addresses. 1342 2.7.1.5. Man-In-The-Middle 1344 A man-in-the-middle attack attacks the identity of a communicating 1345 peer rather than the data stream itself. The attacker intercepts 1346 traffic that is sent between the infrastructure device and the 1347 logging server or traffic sent between the logging server and the 1348 database which is used to archive the logged data. Any unauthorized 1349 access to logging information could lead to knowledge of private and 1350 proprietary network topology information which could be used to 1351 compromise portions of the network. An additional concern is having 1352 access to logging information which could be deleted or modified so 1353 as to cover any traces of a security breach. 1355 2.7.2. Security Practices 1357 Logging is mostly performed on an exception auditing basis when it 1358 comes to filtering (i.e. traffic which is NOT allowed is logged). 1359 This is to assure that the logging servers are not overwhelmed with 1360 data which would render most logs unusable. Typically the data 1361 logged will contain the source and destination IP addresses and layer 1362 4 port numbers as well as a timestamp. The syslog protocol is used 1363 to transfer the logged data between the infrastructure device to the 1364 syslog server. Many ISPs use the OOB management network to transfer 1365 syslog data since there is virtually no security performed between 1366 the syslog server and the device. All ISPs have multiple syslog 1367 servers - some ISPs choose to use separate syslog servers for varying 1368 infrastructure devices (i.e. one syslog server for backbone routers, 1369 one syslog server for customer edge routers, etc.) 1370 The timestamp is derived from NTP which is generally configured as a 1371 flat hierarchy at stratum1 and stratum2 to have less configuration 1372 and less maintenance. Each router is configured with one stratum1 1373 peer both locally and remotely. 1375 In addition to logging filtering exceptions, the following is 1376 typically logged: Routing protocol state changes, all device access 1377 (regardless of authentication success or failure), all commands 1378 issued to a device, all configuration changes and all router events 1379 (boot-up/flaps). 1381 The main function of any of these log messages is to see what the 1382 device is doing as well as to try and ascertain what certain 1383 malicious attackers are trying to do. Some ISPs put in passive 1384 devices to see routing updates and withdrawals and not rely solely on 1385 the device for log files. This provides a backup mechanism to see 1386 what is going on in the network in the event that a device may 1387 'forget' to do syslog if the CPU is busy. 1389 The logs from the various syslog server devices are generally 1390 transferred into databases at a set interval which can be anywhere 1391 from every 10 minutes to every hour. One ISP uses Rsync to push the 1392 data into a database and then the information is sorted manually by 1393 someone SSH'ing to that database. 1395 2.7.3. Security Services 1397 o User Authentication - Not applicable 1399 o User Authorization - Not applicable 1401 o Data Origin Authentication - Not implemented 1403 o Access Control - Filtering on logging host and server IP address 1404 to ensure that syslog information only goes to specific syslog 1405 hosts. 1407 o Data Integrity - Not implemented 1409 o Data Confidentiality - Not implemented 1411 o Auditing / Logging - This entire section deals with logging. 1413 o DoS Mitigation - Logs are useful in providing traceback 1414 information to potentially trace the attack to as close to the 1415 source as possible. 1417 2.7.4. Additional Considerations 1419 There is no security with syslog and ISPs are fully cognizant of 1420 this. IPsec is considered too operationally expensive and cumbersome 1421 to deploy. Syslog-ng and stunnel are being looked at for providing 1422 better authenticated and integrity protected solutions. Mechanisms 1423 to prevent unauthorized personnel from tampering with logs is 1424 constrained to auditing who has access to the logging servers and 1425 files. 1427 ISPs expressed requirements for more than just UDP syslog. 1428 Additionally, they would like more granular and flexible facilities 1429 and priorities, i.e. specific logs to specific servers. Also, a 1430 common format for reporting standard events so that they don't have 1431 to modify parsers after each upgrade of vendor device or software. 1433 2.8. Filtering Considerations 1435 Although filtering has been covered under many of the previous 1436 sections, this section will provide some more insights to the 1437 filtering considerations that are currently being taken into account. 1438 Filtering is now being categorized into three specific areas: data 1439 plane, management plane and routing control plane. 1441 2.8.1. Data Plane Filtering 1443 Data plane filters control the traffic that traverses through a 1444 device and affect transit traffic. Most ISPs deploy these kinds of 1445 filters at the customer facing edge devices to mitigate spoofing 1446 attacks. 1448 2.8.2. Management Plane Filtering 1450 Management filters control the traffic to and from a device. All of 1451 the protocols which are used for device management fall under this 1452 category and includes SSH, Telnet, SNMP, NTP, http, DNS, TFTP, FTP, 1453 SCP and Syslog. This type of traffic is often filtered per interface 1454 and is based on any combination of protocol, source and destination 1455 IP address and source and destination port number. Some devices 1456 support functionality to apply management filters to the device 1457 rather than to the specific interfaces (e.g. receive ACL or loopback 1458 interface ACL) which is gaining wider acceptance. Note that logging 1459 the filtering rules can today place a burden on many systems and more 1460 granularity is often required to more specifically log the required 1461 exceptions. 1463 IPv6 networks require the use of specific ICMP messages for proper 1464 protocol operation. Therefore, ICMP cannot be completely filtered to 1465 and from a device. Instead, granular ICMPv6 filtering is always 1466 deployed to allow for specific ICMPv6 types to be sourced or destined 1467 to a network device. 1469 2.8.3. Routing Control Plane Filtering 1471 Routing filters are used to control the flow of routing information. 1472 In IPv6 networks, some providers are liberal in accepting /48s due to 1473 the still unresolved multihoming issues. Any announcement received 1474 that is longer than a /48 for IPv6 routing and a /24 for IPv4 routing 1475 is filtered out of eBGP. Note that this is for non-customer traffic. 1476 Most ISPs will accept any agreed upon prefix length from its 1477 customer(s). 1479 2.9. Denial of Service Tracking / Tracing 1481 Denial of Service attacks are an ever increasing problem and require 1482 vast amounts of resources to combat effectively. Some large ISPs do 1483 not concern themselves with attack streams that are less than 1G in 1484 bandwidth - this is on the larger pipes where 1G is essentially less 1485 than 5% of offered load. This is largely due to the large amounts of 1486 DDoS traffic which continually requires investigation and mitigation. 1487 At last count the number of hosts making up large distributed DoS 1488 botnets exceeded 1 million hosts. 1490 New techniques are continually evolving to automate the process of 1491 detecting DoS sources and mitigating any adverse effects as quickly 1492 as possible. At this time, ISPs are using a variety of mitigation 1493 techniques including: sink hole routing, black-hole triggered 1494 routing, uRPF and rate limiting. Each of these techniques will be 1495 detailed below. 1497 2.9.1. Sink Hole Routing 1499 Sink hole routing refers to injecting a more specific route for any 1500 known attack traffic which will ensure that the malicious traffic is 1501 redirected to a valid device or specific system where it can be 1502 analyzed. 1504 2.9.2. Black-Hole Triggered Routing 1506 Black-hole triggered routing is a technique where the BGP routing 1507 protocol is used to propagate routes which in turn redirects attack 1508 traffic to the null interface where it is effectively dropped. This 1509 technique is often used in large routing infrastructures since BGP 1510 can propagate the information in a fast effective manner as opposed 1511 to using any packet-based filtering techniques on hundreds or 1512 thousands of routers. 1514 2.9.3. Unicast Reverse Path Forwarding 1516 Unicast Reverse Path Forwarding (uRPF) is a mechanism for validating 1517 whether an incoming packet has a legitimate source address or not. 1518 It has two modes: strict mode and loose mode. In strict mode, uRPF 1519 checks whether the incoming packet has a source address that matches 1520 a prefix in the routing table, and whether the interface expects to 1521 receive a packet with this source address prefix. If the incoming 1522 packet fails the unicast RPF check, the packet is not accepted on the 1523 incoming interface. Loose mode uRPF is not as specific and the 1524 incoming packet is accepted if there is any route in the routing 1525 table for the source address. 1527 uRPF is not used on interfaces that are likely to have routing 1528 asymmetry, meaning multiple routes to the source of a packet. 1529 Usually for ISPs, uRPF is placed at the customer edge of a network. 1531 2.9.4. Rate Limiting 1533 Rate limiting refers to allocating a specific amount of bandwidth or 1534 packets per second to specific traffic types. This technique is 1535 widely used to mitigate well-known protocol attacks such as the TCP- 1536 SYN attack where a large number of resources get allocated for 1537 spoofed TCP traffic. Although this technique does not stop an 1538 attack, it can sometimes lessen the damage and impact on a specific 1539 service. However, it can also make the impact of a DDoS attack much 1540 worse if the rate limiting is impacting (i.e. discarding) more 1541 legitimate traffic. 1543 3. Security Considerations 1545 This entire document deals with current security practices in large 1546 ISP environments. As a synopsis, a table is shown below which 1547 summarizes the operational functions which are to be protected and 1548 the security services which currently deployed security practices 1549 offer: [ Table to be added ] 1551 4. Normative References 1553 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1554 Requirement Levels", BCP 14, RFC 2119, March 1997. 1556 [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, 1557 May 2000. 1559 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1560 Text on Security Considerations", BCP 72, RFC 3552, 1561 July 2003. 1563 Appendix A. Acknowledgments 1565 The editor gratefully acknowledges the contributions of: George 1566 Jones, who has been instrumental in providing guidance and direction 1567 for this document and the insighful comments from Ross Callon, Ron 1568 Bonica, Gaurab Upadhaya, Warren Kumari and the numerous ISP operators 1569 who supplied the information which is depicted in this document. 1571 Appendix B. Protocol Specific Attacks 1573 This section will enumerate many of the traditional protocol based 1574 attacks which have been observed over the years to cause malformed 1575 packets and/or exploit protocol deficiencies. 1577 B.1. Layer 2 Attacks 1579 o ARP Flooding 1581 B.2. IPv4 Attacks 1583 o IP Stream Option 1585 o IP Address Spoofing 1587 o IP Source Route Option 1589 o IP Short header 1591 o IP Malformed Packet 1593 o Ip Bad Option 1595 o Ip Address Session Limit 1597 o Fragmenmts - too many 1599 o Fragments - large offset 1601 o Fragments - same offset 1603 o Fragments - reassembly with different offsets (TearDrop Attac) 1605 o Fragments - reassembly off by one IP header (Nestea Attack) 1607 o Fragment - flooding only initial fragment (Rose Attack) 1609 o IGMP oversized packet 1611 o ICMP Source Quench 1613 o ICMP Mask Request 1615 o ICMP Large Packet (> 1472) 1616 o ICMP Oversized packet (>65536) 1618 o ICMP Flood 1620 o ICMP Broadcast w/ Spoofed Source (Smurf Attack) 1622 o ICMP Error Packet Flood 1624 o ICMP Spoofed Unreachable 1626 o TCP Packet without Flag 1628 o TCP Oversized Packet 1630 o TCP FIN bit with no ACK bit 1632 o TCP Packet with URG/OOB flag (Nuke Attack) 1634 o SYN Fragments 1636 o SYN Flood 1638 o SYN with IP Spoofing (Land Attack) 1640 o SYN and FIN bits set 1642 o TCP port scan attack 1644 o UDP spoofed broadcast echo (Fraggle Attack) 1646 o UDP attack on diag ports (Pepsi Attack) 1648 B.3. IPv6 Attacks 1650 Any of the above-mentioned IPv4 attacks could be used in IPv6 1651 networks with the exception of any fragmentation and broadcast 1652 traffic, which operate differently in IPv6. 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. 1659 Author's Address 1661 Merike Kaeo 1662 Double Shot Security, Inc. 1663 3518 Fremont Avenue North #363 1664 Seattle, WA 98103 1665 U.S.A. 1667 Phone: +1 310 866 0165 1668 Email: merike@doubleshotsecurity.com 1670 Intellectual Property Statement 1672 The IETF takes no position regarding the validity or scope of any 1673 Intellectual Property Rights or other rights that might be claimed to 1674 pertain to the implementation or use of the technology described in 1675 this document or the extent to which any license under such rights 1676 might or might not be available; nor does it represent that it has 1677 made any independent effort to identify any such rights. Information 1678 on the procedures with respect to rights in RFC documents can be 1679 found in BCP 78 and BCP 79. 1681 Copies of IPR disclosures made to the IETF Secretariat and any 1682 assurances of licenses to be made available, or the result of an 1683 attempt made to obtain a general license or permission for the use of 1684 such proprietary rights by implementers or users of this 1685 specification can be obtained from the IETF on-line IPR repository at 1686 http://www.ietf.org/ipr. 1688 The IETF invites any interested party to bring to its attention any 1689 copyrights, patents or patent applications, or other proprietary 1690 rights that may cover technology that may be required to implement 1691 this standard. Please address the information to the IETF at 1692 ietf-ipr@ietf.org. 1694 Disclaimer of Validity 1696 This document and the information contained herein are provided on an 1697 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1698 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1699 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1700 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1701 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1702 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1704 Copyright Statement 1706 Copyright (C) The Internet Society (2006). This document is subject 1707 to the rights, licenses and restrictions contained in BCP 78, and 1708 except as set forth therein, the authors retain all their rights. 1710 Acknowledgment 1712 Funding for the RFC Editor function is currently provided by the 1713 Internet Society.