idnits 2.17.1 draft-ietf-opsec-current-practices-03.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 1639. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1616. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1623. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1629. ** 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 (May 24, 2006) is 6546 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 862, but not defined == Missing Reference: 'BTSH' is mentioned on line 1009, but not defined ** Obsolete normative reference: RFC 2828 (Obsoleted by RFC 4949) Summary: 5 errors (**), 0 flaws (~~), 5 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: November 25, 2006 May 24, 2006 6 Operational Security Current Practices 7 draft-ietf-opsec-current-practices-03 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 November 25, 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 . . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . . . 19 61 2.5. Routing Control Plane . . . . . . . . . . . . . . . . . . 21 62 2.6. Software Upgrades and Configuration Integrity / 63 Validation . . . . . . . . . . . . . . . . . . . . . . . . 25 64 2.7. Logging Considerations . . . . . . . . . . . . . . . . . . 28 65 2.8. Filtering Considerations . . . . . . . . . . . . . . . . . 31 66 2.9. Denial of Service Tracking / Tracing . . . . . . . . . . . 32 67 3. Security Considerations . . . . . . . . . . . . . . . . . . . 34 68 4. Normative References . . . . . . . . . . . . . . . . . . . . . 34 69 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 35 70 Appendix B. Protocol Specific Attacks . . . . . . . . . . . . . . 36 71 B.1. Layer 2 Attacks . . . . . . . . . . . . . . . . . . . . . 36 72 B.2. IPv4 Attacks . . . . . . . . . . . . . . . . . . . . . . . 36 73 B.3. IPv6 Attacks . . . . . . . . . . . . . . . . . . . . . . . 37 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38 75 Intellectual Property and Copyright Statements . . . . . . . . . . 39 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 apply to 100 IPv6 networks. Both IPv4 and IPv6 network infrastructures are taken 101 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. 122 Protocol Vulnerability Exploitation: An attack which takes advantage 123 of known protocol deficiencies to cause inappropriate behavior. 125 Message Insertion: This can be a valid message (which could be a 126 reply attack,, which is a scenario where a message is captured and 127 resent at later time). A message can also be inserted with any of 128 the fields in the message being OspoofedO, such as IP addresses, port 129 numbers, header fields or even packet content. Flooding is also part 130 of this threat instantiation. 132 Message Diversion/Deletion: An attack where legitimate messages are 133 removed before they can reach the desired recipient or are re- 134 directed to a network segment that is normally not part of the data 135 path. 137 Message Modification: This is a subset of a message insertion attack 138 where a previous message has been captured and modified before being 139 retransmitted. The message can be captured by using a man-in-the- 140 middle attack or message diversion. 142 Note that sometimes Denial of service attacks are listed as separate 143 categories. A denial of service is a consequence of an attack and 144 can be the result of too much traffic (i.e. flooding), or exploting 145 protocol expoitation or inserting/deleting/diverting/midifying 146 messages. 148 1.3. Attack Sources 150 These attacks can be sourced in a variety of ways: 152 Active vs passive attacks 154 An active attack involves writing data to the network. It is 155 common practice in active attacks to disguise one's address and 156 conceal the identity of the traffic sender. A passive attack 157 involves only reading information off the network. This is 158 possible if the attacker has control of a host in the 159 communications path between two victim machines or has compromised 160 the routing infrastructure to specifically arrange that traffic 161 pass through a compromised machine. In general, the goal of a 162 passive attack is to obtain information that the sender and 163 receiver would prefer to remain private. [RFC3552] 165 On-path vs off-path attacks 167 In order for a datagram to be transmitted from one host to 168 another, it generally must traverse some set of intermediate links 169 and routers. Such routers are naturally able to read, modify, or 170 remove any datagram transmitted along that path. This makes it 171 much easier to mount a wide variety of attacks if you are on-path. 172 Off-path hosts can transmit arbitrary datagrams that appear to 173 come from any hosts but cannot necessarily receive datagrams 174 intended for other hosts. Thus, if an attack depends on being 175 able to receive data, off-path hosts must first subvert the 176 topology in order to place themselves on-path. This is by no 177 means impossible but is not necessarily trivial. [RFC3552] 179 Insider or outsider attacks 181 An "insider attack" is one which is initiated from inside a given 182 security perimeter, by an entity that is authorized to access 183 system resources but uses them in a way not approved by those who 184 granted the authorization. An "outside attack" is initiated from 185 outside the perimeter, by an unauthorized or illegitimate user of 186 the system. 188 Deliberate attacks vs unintentional events 190 A deliberate attack is one where a miscreant intentionally 191 performs an assault on system security. However, there are also 192 instances where unintentional events cause the same harm yet are 193 performed without malice in mind. Configuration errors and 194 software bugs can be as devastating to network availability as any 195 deliberate attack on the network infrastructure. 197 The attack source can be a combination of any of the above, all of 198 which need to be considered when trying to ascertain what impact any 199 attack can have on the availability and reliability of the network. 200 It is nearly impossible to stop insider attacks or unintentional 201 events. However, if appropriate monitoring mechanisms are in place, 202 these attacks can be as easily detected and mitigated as with any 203 other attack source. Any of the specific attacks discussed further 204 in this document will elaborate on attacks which are sourced by an 205 "outsider" and are deliberate attacks. Some further elaboration will 206 be given to the feasibility of passive vs active and on-path vs off- 207 path attacks to show the motivation behind deploying certain security 208 features. 210 1.4. Operational Security Impact from Threats 212 The main concern for any of the potential attack scenarios is the 213 impact and harm it can cause to the network infrastructure. The 214 threat consequences are the security violations which results from a 215 threat action, i.e. an attack. These are typically classified as 216 follows: 218 (Unauthorized) Disclosure 220 A circumstance or event whereby an entity gains access to data for 221 which the entity is not authorized. 223 Deception 225 A circumstance or event that may result in an authorized entity 226 receiving false data and believing it to be true. 228 Disruption 230 A circumstance or event that interrupts or prevents the correct 231 operation of system services and functions. A broad variety of 232 attacks, collectively called denial of service attacks, threaten 233 the availability of systems and bandwidth to legitimate users. 234 Many such attacks are designed to consume machine resources, 235 making it difficult or impossible to serve legitimate users. 236 Other attacks cause the target machine to crash, completely 237 denying service to users. 239 Usurpation 241 A circumstance or event that results in control of system services 242 or functions by an unauthorized entity. Most network 243 infrastructure systems are only intended to be completely 244 accessible to certain authorized individuals. Should an 245 unauthorized person gain access to critical layer 2 / layer 3 246 infrastructure devices or services, they could cause great harm to 247 the reliability and availability of the network. 249 A complete description of threat actions that can cause these threat 250 consequences can be found in [RFC2828]. Typically, a number of 251 different network attacks are used in combination to cause one or 252 more of the above mentioned threat consequences. An example would be 253 a malicious user who has the capability to eavesdrop on traffic. 254 First, he may listen in on traffic for a while to do some 255 reconnaissance work and ascertain which IP addresses belonged to 256 specific devices such as routers. Were this miscreant to obtain 257 information such as a router password sent in cleartext, he can then 258 proceed to compromise the actual router. From there, the miscreant 259 can launch various active attacks such as sending bogus routing 260 updates to redirect traffic or capture additional traffic to 261 compromise other network devices. 263 1.5. Document Layout 265 This document is a survey of current operational practices that 266 mitigate the risk of being susceptible to any threat actions. As 267 such, the main focus is on the currently deployed security practices 268 used to detect and/or mitigate attacks. The top-level categories in 269 this document are based on operational functions for ISPs and 270 generally relate to what is to be protected. This is followed by a 271 description of which attacks are possible and the security practices 272 currently deployed which will provide the necessary security services 273 to help mitigate these attacks. These security services are 274 classified as: 276 o User Authentication 278 o User Authorization 280 o Data Origin Authentication 282 o Access Control 284 o Data Integrity 286 o Data Confidentiality 288 o Auditing / Logging 290 o DoS Mitigation 292 In many instances, a specific protocol currently deployed will offer 293 a combination of these services. For example, AAA can offer user 294 authentication, user authorization and audit / logging services while 295 SSH can provide data origin authentication, data integrity and data 296 confidentiality. The services offered are more important than the 297 actual protocol used. Each section ends with an additional 298 considerations section which explains why specific protocols may or 299 may not be used and also gives some information regarding 300 capabilities which are not possible today due to bugs or lack of ease 301 of use. 303 1.6. Definitions 305 RFC 2119 Keywords 306 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 307 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 308 in this document are to be interpreted as described in [RFC2119]. 310 The use of the RFC 2119 keywords is an attempt, by the editor, to 311 assign the correct requirement levels ("MUST", "SHOULD", 312 "MAY"...). It must be noted that different organizations, 313 operational environments, policies and legal environments will 314 generate different requirement levels. 316 2. Protected Operational Functions 318 2.1. Device Physical Access 320 Device physical access pertains to protecting the physical location 321 of the layer 2 or layer 3 network infrastructure device. Although it 322 is important to have contingency plans for natural disasters such as 323 earthquakes and floods which can cause damage to networking devices, 324 this is out-of-scope for this document. Here we concern ourselves 325 with protecting access to the physical location and how a device can 326 be further protected from unauthorized access if the physical 327 location has been compromised, i.e protecting the console access. 329 2.1.1. Threats / Attacks 331 If any intruder gets physical access to a layer 2 or layer 3 device, 332 the entire network infrastructure can be under the control of the 333 intruder. At a minimum, the intruder can take the compromised device 334 out-of-service, causing network disruption, the extent of which 335 depends on the network topology. A worse scenario is where the 336 intruder can use this device to crack the console password and have 337 complete control of the device, perhaps without anyone detecting such 338 a compromise, or to attach another network device onto a port and 339 siphon off data with which the intruder can ascertain the network 340 topology and take control of the entire network. 342 The threat of gaining physical access can be realized in a variety of 343 ways even if critical devices are under high-security. There still 344 occur cases where attackers have impersonated maintenance workers to 345 gain physical access to critical devices that have caused major 346 outages and privacy compromises. Insider attacks from authorized 347 personnel also pose a real threat and must be adequately recognized 348 and dealt with. 350 2.1.2. Security Practices 352 For physical device security, equipment is kept in highly restrictive 353 environments. Only authorized users with card key badges have access 354 to any of the physical locations that contain critical network 355 infrastructure devices. These card-key systems keep track of who 356 accessed which location and at what time. 358 All console access is always password protected and the login time is 359 set to time out after a specified amount of inactivity - typically 360 between 3-10 minutes. Individual users are authentication to get 361 basic access. For privileged (i.e. enable) access, a second 362 authentication step needs to be completed. Typically all console 363 access is provided via an out-of-band (OOB) management infrastructure 364 which is discussed in the section on OOB management. 366 2.1.3. Security Services 368 The following security services are offered through the use of the 369 practices described in the previous section: 371 o User Authentication - All individuals who have access to the 372 physical facility are authenticated. Console access is 373 authenticated. 375 o User Authorization - An authenticated individual has implicit 376 authorization to perform commands on the device. Console access 377 is usually granted via at least two privilege levels: 378 authorization for performing a basic set of commands vs 379 authorization for performing all commands. 381 o Data Origin Authentication - Not applicable 383 o Access Control - Not applicable 385 o Data Integrity - Not applicable 387 o Data Confidentiality - Not applicable 389 o Auditing / Logging - All access to the physical locations of the 390 infrastructure equipment is logged via electronic card-key 391 systems. All console access is logged (refer to the OOB 392 management section for more details) 394 o DoS Mitigation - Not applicable 396 2.1.4. Additional Considerations 398 Physical security is relevant to operational security practices as 399 described in this document mostly from a console access perspective. 400 Most ISPs provide console access via an OOB management infrastructure 401 which is discussed in the OOB management section of this document. 403 The physical and logical authentication and logging systems should be 404 run independently of each other and reside in different physical 405 locations. 407 Social engineering plays a big role in many physical access 408 compromises. Most ISPs have set up training classes and awareness 409 programs to educate company personnel to deny physical access to 410 people who are not properly authenticated or authorized to have 411 physical access to critical infrastructure devices. 413 2.2. Device In-Band Management 415 In-band management is generally considered to be device access where 416 the control traffic takes the same data path as the data which 417 traverses the network. In many environments, device management for 418 layer 2 and layer 3 infrastructure devices is deployed as part of an 419 out-of-band management infrastructure although there are some 420 instances where it is deployed in-band as well. Presently, the 421 mechanisms used for in-band management are via virtual terminal 422 access (i.e. Telnet or SSH), SNMP, or HTTP. In all large ISPs that 423 were interviewed, HTTP management is never used and is explicitly 424 disabled. Note that file transfer protocols (TFTP, FTP, SCP) will be 425 covered in the 'Software Upgrades and Configuration Integrity/ 426 Validation' section. 428 2.2.1. Threats / Attacks 430 For in-band device management, passive attacks are possible if 431 someone has the capability to intercept data between the management 432 device and the managed device. The threat is possible if a single 433 infrastructure device is somehow compromised and can act as a network 434 sniffer or if it is possible to insert a new device which acts as a 435 network sniffer. 437 Active attacks are possible for both on-path and off-path scenarios. 438 For on-path active attacks, the situation is the same as for a 439 passive attack, where either a device has to already be compromised 440 or a device can be inserted into the path. For off-path active 441 attacks, the attack is generally limited to message insertion or 442 modification. 444 2.2.1.1. Confidentiality Violations 446 Confidentiality violations can occur when a miscreant intercepts 447 confidential data that has been sent in cleartext. This includes 448 interception of usernames and passwords with which an intruder can 449 obtain unauthorized access to network devices. It can also include 450 other information such as logging or configuration information if an 451 administrator is remotely viewing local logfiles or configuration 452 information. 454 2.2.1.2. Offline Cryptographic Attacks 456 If username/password information was encrypted but the cryptographic 457 mechanism used made it easy to capture data and break the encryption 458 key, the device management traffic could be compromised. The traffic 459 would need to be captured either by eavesdropping on the network or 460 by being able to divert traffic to a malicious user. 462 2.2.1.3. Replay Attacks 464 For a replay attack to be successful, in-band management traffic 465 would need to first be captured either on-path or diverted to an 466 attacker to later be replayed to the intended recipient. 468 2.2.1.4. Message Insertion/Deletion/Modification 470 Data can be manipulated by someone in control of intermediary hosts. 471 Forging data is also possible with IP spoofing, where a remote host 472 sends out packets which appear to come from another, trusted host. 474 2.2.1.5. Man-In-The-Middle 476 A man-in-the-middle attack attacks the identity of a communicating 477 peer rather than the data stream itself. The attacker intercepts 478 traffic that is sent from an in-band management system to the 479 networking infrastructure device and traffic that is sent from the 480 network infrastructure device to the in-band management system. 482 2.2.2. Security Practices 484 All in-band management access to layer 2 and layer 3 devices is 485 authenticated. The user authentication and authorization is 486 typically controlled by a AAA server (i.e. RADIUS and/or TACACS+). 487 Credentials used to determine the identity of the user vary from 488 static username/password to one-time username/password scheme such as 489 Secure-ID. Static username/passwords are expired after a specified 490 period of time, usually 30 days. Every authenticated entity via AAA 491 is an individual user for greater granularity of control. In some 492 deployments, The AAA servers used for in-band management 493 authentication/authorization/accounting are on separate out-of-band 494 networks to provide a demarcation for any other authentication 495 functions. 497 For backup purposes, there is often a single local database entry for 498 authentication which is known to a very limited set of key personnel. 499 It is usually the highest privilege level username/password 500 combination, which in most cases is the same across all devices. 501 This local device password is routinely regenerated once every 2-3 502 months and is also regenerated immediately after an employee who had 503 access to that password leaves the company or is no longer authorized 504 to have knowledge of that password. 506 Each individual user in the AAA database is configured with specific 507 authorization capability. Specific commands are either individually 508 denied or permitted depending on the capability of the device to be 509 accessed. Multiple privilege levels are deployed. Most individuals 510 are authorized with basic authorization to perform a minimal set of 511 commands while a subset of individuals are authorized to perform more 512 privileged commands. 514 SSH is always used for virtual terminal access to provide for an 515 encrypted communication channel. There are exceptions due to 516 equipment limitations which are described in the additional 517 considerations section. 519 If SNMP is used for in-band management, it is for read queries only 520 and restricted to specific hosts. The community strings are 521 carefully chosen to be difficult to crack and there are procedures in 522 place to change these community strings between 30-90 days. If 523 systems support two SNMP community strings, the old string is 524 replaced by first configuring a second newer community string and 525 then migrating over from the currently used string to the newer one. 526 Most large ISPs have multiple SNMP systems accessing their routers so 527 it takes more then one maintenance period to get all the strings 528 fixed in all the right systems. SNMP RW is not used and disabled by 529 configuration. 531 Access control is strictly enforced for infrastructure devices by 532 using stringent filtering rules. A limited set of IP addresses are 533 allowed to initiate connections to the infrastructure devices and are 534 specific to the services which they are to limited to (i.e. SSH and 535 SNMP). 537 All in-band device management access is audited and any violations 538 trigger alarms which initiate automated email, pager and/or telephone 539 notifications. AAA servers keeps track of the authenticated entity 540 as well as all the commands that were carried out on a specific 541 device. Additionally, the device itself logs any access control 542 violations (i.e. if an SSH request comes in from an IP address which 543 is not explicitly permitted, that event is logged so that the 544 offending IP address can be tracked down and investigations made as 545 to why it was trying to access a particular infrastructure device) 547 2.2.3. Security Services 549 The following security services are offered through the use of the 550 practices described in the previous section: 552 o User Authentication - All individuals are authenticated via AAA 553 services. 555 o User Authorization - All individuals are authorized via AAA 556 services to perform specific operations once successfully 557 authenticated. 559 o Data Origin Authentication - Management traffic is strictly 560 filtered to allow only specific IP addresses to have access to the 561 infrastructure devices. This does not alleviate risk from spoofed 562 traffic. Using SSH for device access ensures that noone can spoof 563 the traffic during the SSH session. 565 o Access Control - In-band management traffic is filtered to allow 566 only specific IP addresses to have access to the infrastructure 567 devices. 569 o Data Integrity - Using SSH provides data integrity and ensures 570 that noone has altered the management data in transit. 572 o Data Confidentiality - Using SSH provides data confidentiality. 574 o Auditing / Logging - Using AAA provides an audit trail for who 575 accessed which device and which operations were performed. 577 o DoS Mitigation - Using packet filters to allow only specific IP 578 addresses to have access to the infrastructure devices. This 579 limits but does not prevent spoofed DoS attacks directed at an 580 infrastructure device. Often OOB management is used to lower that 581 risk. 583 2.2.4. Additional Considerations 585 Password selection for any in-band device management protocol used is 586 critical to ensure that the passwords are hard to guess or break 587 using a brute-force attack. 589 IPsec is considered too difficult to deploy and the common protocol 590 to provide for confidential in-band management access is SSH. There 591 are exceptions for using SSH due to equipment limitations since SSH 592 may not be supported on legacy equipment. Also, in the case where 593 the SSH key is stored on a route processor card, a re-keying of SSH 594 would be required whenever the route processor card needs to be 595 swapped. Some providers feel that this operational impact exceeds 596 the security necessary and instead use Telnet from trusted inside 597 hosts (called 'jumphosts') to manage those devices. An individual 598 would first SSH to the jumphost and then Telnet from the jumphost to 599 the actual infrastructure device. All authentication and 600 authorization is still carried out using AAA servers. 602 In instances where Telnet access is used, the logs on the AAA servers 603 are more verbose and more attention is paid to them to detect any 604 abnormal behavior. The jumphosts themselves are carefully controlled 605 machines and usually have limited access. Note that Telent is NEVER 606 allowed to an infrastructure device except from specific jumphosts; 607 i.e. packet filters are used to ensure that Telnet is only allowed 608 from specific IP addresses. 610 With thousands of devices to manage, some ISPs have created automated 611 mechanisms to authenticate to devices. Kerberos is used to automate 612 the authentication process. An individual would first log in to a 613 Kerberized UNIX server using SSH and generate a Kerberos 'ticket'. 614 This 'ticket' is generally set to have a lifespan of 10 hours and is 615 used to automatically authenticate the individual to the 616 infrastructure devices. 618 In instances where SNMP is used, some legacy devices only support 619 SNMPv1 which then requires the provider to mandate its use across all 620 infrastructure devices for operational simplicity. SNMPv2 is 621 primarily deployed since it is easier to set up than v3. 623 2.3. Device Out-of-Band Management 625 Out-of-band management is generally considered to be device access 626 where the control traffic takes a separate path as the data which 627 traverses the network. Console access is always architected via an 628 OOB network. SNMP management is also usually carried out via that 629 same OOB network infrastructure. 631 2.3.1. Threats / Attacks 633 For OOB device management, passive attacks are possible if someone 634 has the capability to intercept data between the management device 635 and the managed device. The threat is possible if a single 636 infrastructure device is somehow compromised and can act as a network 637 sniffer or if it is possible to insert a new device which acts as a 638 network sniffer. 640 Active attacks are possible for both on-path and off-path scenarios. 641 For on-path active attacks, the situation is the same as for a 642 passive attack, where either a device has to already be compromised 643 or a device can be inserted into the path. For off-path active 644 attacks, the attack is generally limited to message insertion or 645 modification. 647 2.3.1.1. Confidentiality Violations 649 Confidentiality violations can occur when a miscreant intercepts any 650 of the OOB management data that has been sent in cleartext. This 651 includes interception of usernames and passwords with which an 652 intruder can obtain unauthorized access to network devices. It can 653 also include other information such as logging or configuration 654 information if an administrator is remotely viewing local logfiles or 655 configuration information. 657 2.3.1.2. Offline Cryptographic Attacks 659 If username/password information was encrypted but the cryptographic 660 mechanism used made it easy to capture data and break the encryption 661 key, the OOB management traffic could be compromised. The traffic 662 would need to be captured either by eavesdropping on the network or 663 by being able to divert traffic to a malicious user. 665 2.3.1.3. Replay Attacks 667 For a replay attack to be successful, the OOB management traffic 668 would need to first be captured either on-path or diverted to an 669 attacker to later be replayed to the intended recipient. 671 2.3.1.4. Message Insertion/Deletion/Modification 673 Data can be manipulated by someone in control of intermediary hosts. 674 Forging data is also possible with IP spoofing, where a remote host 675 sends out packets which appear to come from another, trusted host. 677 2.3.1.5. Man-In-The-Middle 679 A man-in-the-middle attack attacks the identity of a communicating 680 peer rather than the data stream itself. The attacker intercepts 681 traffic that is sent from an OOB management system to the networking 682 infrastructure device and traffic that is sent from the network 683 infrastructure device to the OOB management system. 685 2.3.2. Security Practices 687 OOB is done via a terminal server at each location. SSH access is 688 used to get to the terminal server from where sessions to the devices 689 are initiated. Dial-in access is deployed as a backup if the network 690 is not available. 692 All OOB management access to layer 2 and layer 3 devices is 693 authenticated. The user authentication and authorization is 694 typically controlled by a AAA server (i.e. RADIUS and/or TACACS+). 695 Credentials used to determine the identity of the user vary from 696 static username/password to one-time username/password scheme such as 697 Secure-ID. Static username/passwords are expired after a specified 698 period of time, usually 30 days. Every authenticated entity via AAA 699 is an individual user for greater granularity of control. Note that 700 often the AAA server used for OOB management authentication is a 701 separate physical device from the AAA server used for in-band 702 management user authentication. 704 For backup purposes, there is often a single local database entry for 705 authentication which is known to a very limited set of key personnel. 706 It is usually the highest privilege level username/password 707 combination, which in most cases is the same across all devices. 708 This local device password is routinely regenerated once every 2-3 709 months and is also regenerated immediately after an employee who had 710 access to that password leaves the company or is no longer authorized 711 to have knowledge of that password. 713 Each individual user in the AAA database is configured with specific 714 authorization capability. Specific commands are either individually 715 denied or permitted depending on the capability of the device to be 716 accessed. Multiple privilege levels are deployed. Most individuals 717 are authorized with basic authorization to perform a minimal set of 718 commands while a subset of individuals are authorized to perform more 719 privileged commands. 721 Some OOB management functions are performed using command line 722 interface (CLI) scripting. In these scenarios, a dedicated user is 723 used for the identity in scripts that perform CLI scripting. Once 724 authenticated, these scripts control which commands are legitimate 725 depending on authorization rights of the authenticated individual. 727 SSH is always used for virtual terminal access to provide for an 728 encrypted communication channel. There are exceptions due to 729 equipment limitations which are described in the additional 730 considerations section. 732 If SNMP is used for OOB management, it is for read queries only and 733 restricted to specific hosts. The community strings are carefully 734 chosen to be difficult to crack and there are procedures in place to 735 change these community strings between 30-90 days. If systems 736 support two SNMP strings, a second new string is set and then migrate 737 over from the 1st to the 2nd. Most large ISPs have multiple SNMP 738 systems accessing their routers so it takes more then one maintenance 739 period to get all the strings fixed in all the right systems. SNMP 740 RW is not used and disabled by configuration. 742 Access control is strictly enforced for infrastructure devices by 743 using stringent filtering rules. A limited set of IP addresses are 744 allowed to initiate connections to the infrastructure devices and are 745 specific to the services which they are to limited to (i.e. SSH and 746 SNMP). 748 All OOB device management access is audited. The AAA server keeps 749 track of the authenticated entity as well as all the commands that 750 were carried out on a specific device. Additionally, the device 751 itself logs any access control violations (i.e. if an SSH request 752 comes in from an IP address which is not explicitly permitted, that 753 event is logged so that the offending IP address can be tracked down 754 and investigations made as to why it was trying to access a 755 particular infrastructure device) 757 2.3.3. Security Services 759 The security services offered for device OOB management are nearly 760 identical to those of device in-band management. Due to the critical 761 nature of controlling and limiting device access, many ISPs feel that 762 physically separating the management traffic from the normal customer 763 data traffic will provide an added level of risk mitigation and limit 764 the potential attack vectors. For OOB management, the security 765 services offered through the use of the practices described in the 766 previous section are: 768 o User Authentication - All individuals are authenticated via AAA 769 services. 771 o User Authorization - All individuals are authorized via AAA 772 services to perform specific operations once successfully 773 authenticated. 775 o Data Origin Authentication - Management traffic is strictly 776 filtered to allow only specific IP addresses to have access to the 777 infrastructure devices. This does not alleviate risk from spoofed 778 traffic. Using SSH for device access ensures that noone can spoof 779 the traffic during the SSH session. 781 o Access Control - In-band management traffic is filtered to allow 782 only specific IP addresses to have access to the infrastructure 783 devices. 785 o Data Integrity - Using SSH provides data integrity and ensures 786 that noone has altered the management data in transit. 788 o Data Confidentiality - Using SSH provides data confidentiality. 790 o Auditing / Logging - Using AAA provides an audit trail for who 791 accessed which device and which operations were performed. 793 o DoS Mitigation - Using packet filters to allow only specific IP 794 addresses to have access to the infrastructure devices. This 795 limits but does not prevent spoofed DoS attacks directed at an 796 infrastructure device. However, the risk is lowered by using a 797 separate physical network for management purposes. 799 2.3.4. Additional Considerations 801 Password selection for any OOB device management protocol used is 802 critical to ensure that the passwords are hard to guess or break 803 using a brute-force attack. 805 IPsec is considered too difficult to deploy and the common protocol 806 to provide for confidential OOB management access is SSH. There are 807 exceptions for using SSH due to equipment limitations since SSH may 808 not be supported on legacy equipment. Also, in the case where the 809 SSH key is stored on a route processor card, a re-keying of SSH would 810 be required whenever the route processor card needs to be swapped. 811 Some providers feel that this operational impact exceeds the security 812 necessary and instead use Telnet from trusted inside hosts (called 813 'jumphosts') to manage those device. An individual would first SSH 814 to the jumphost and then Telnet from the jumphost to the terminal 815 server before logging in to the device console. All authentication 816 and authorization is still carried out using AAA servers. 818 In instances where Telnet access is used, the logs on the AAA servers 819 are more verbose and more attention is paid to them to detect any 820 abnormal behavior. The jumphosts themselves are carefully controlled 821 machines and usually have limited access. Note that Telent is NEVER 822 allowed to an infrastructure device except from specific jumphosts; 823 i.e. packet filters are used at the console server and/or 824 infrastructure device to ensure that Telnet is only allowed from 825 specific IP addresses. 827 In instances where SNMP is used, some legacy devices only support 828 SNMPv1 which then requires the provider to mandate its use across all 829 infrastructure devices for operational simplicity. SNMPv2 is 830 primarily deployed since it is easier to set up than v3. 832 2.4. Data Path 834 This section refers to how traffic is handled which traverses the 835 network infrastructure device. The primary goal of ISPs is to 836 forward customer traffic. However, due to the large amount of 837 malicious traffic that can cause DoS attacks and render the network 838 unavailable, specific measures are sometimes deployed to ensure the 839 availability to forward legitimate customer traffic. 841 2.4.1. Threats / Attacks 843 Any data traffic can potentially be attack traffic and the challenge 844 is to detect and potentially stop forwarding any of the malicious 845 traffic. The deliberately sourced attack traffic can consist of 846 packets with spoofed source and/or destination addresses or any other 847 malformed packet which mangle any portion of a header field to cause 848 protocol-related security issues (such as resetting connections, 849 causing unwelcome ICPM redirects, creating unwelcome IP options or 850 packet fragmentations). 852 2.4.2. Security Practices 854 Filtering and rate limiting are the primary mechanism to provide risk 855 mitigation of malicious traffic rendering the ISP services 856 unavailable. However, filtering and rate limiting of data path 857 traffic is deployed in a variety of ways depending on how automated 858 the process is and what the capabilities and performance limitations 859 of existing deployed hardware are. 861 The ISPs which do not have performance issues with their equipment 862 follow BCP38 [BCP38] guidelines. Null routes and black-hole 863 filtering are used to deter any detected malicious traffic streams. 864 Most ISPs consider layer 4 filtering useful but it is only 865 implemented if there is no performance limitations on the devices. 866 Netflow is used for tracking traffic flows but there is some concern 867 whether sampling is good enough to detect malicious behavior. 869 Unicast RPF is not consistently implemented. Some ISPs are in 870 process of doing so while other ISPs think that the perceived benefit 871 of knowing that spoofed traffic comes from legitimate addresses are 872 not worth the operational complexity. Some providers have a policy 873 of implementing uRPF at link speeds of DS3 and below. 875 2.4.3. Security Services 877 o User Authentication - Not applicable 879 o User Authorization - Not applicable 881 o Data Origin Authentication - When IP address filtering per BCP38 882 and uRPF are deployed at network edges it can ensure that any 883 spoofed traffic comes from at least a legitimate IP address and 884 can be tracked. 886 o Access Control - IP address filtering and layer 4 filtering is 887 used to deny forbidden protocols and limit traffic destined for 888 infrastructure device itself. 890 o Data Integrity - Not applicable 892 o Data Confidentiality - Not applicable 894 o Auditing / Logging - Filtering exceptions are logged for potential 895 attack traffic. 897 o DoS Mitigation - Black-hole triggered filtering and rate-limiting 898 are used to limit the risk of DoS attacks. 900 2.4.4. Additional Considerations 902 For layer 2 devices, MAC address filtering and authentication is not 903 used. This is due to the problems it can cause when troubleshooting 904 networking issues. Port security becomes unmanageable at a large 905 scale where 1000s of switches are deployed. 907 Rate limiting is used by some ISPs although other ISPs believe it is 908 not really useful since attackers are not well behaved and it doesn't 909 provide any operational benefit over the complexity. Rate limiting 910 may be improved by developing flow-based rate-limiting capabilities 911 with filtering hooks. This would improve the performance as well as 912 the granularity over current capabilities. 914 Lack of consistency regarding the ability to filter, especially with 915 respect to performance issues cause some ISPs to not implement BCP38 916 guidelines for ingress filtering. One such example is at edge boxes 917 where you have up to 1000 T1's connecting into a router with an OC-12 918 uplink. Some deployed devices experience a large performance impact 919 with filtering which is unacceptable for passing customer traffic 920 through. Where performance is not an issue, the ISPs make a tradeoff 921 between management versus risk. 923 2.5. Routing Control Plane 925 The routing control plane deals with all the traffic which is part of 926 establishing and maintaining routing protocol information. 928 2.5.1. Threats / Attacks 930 Attacks on the routing control plane can be both from passive or 931 active sources. Passive attacks are possible if someone has the 932 capability to intercept data between the communicating routing peers. 933 This can be accomplished if a single routing peer is somehow 934 compromised and can act as a network sniffer or if it is possible to 935 insert a new device which acts as a network sniffer. 937 Active attacks are possible for both on-path and off-path scenarios. 938 For on-path active attacks, the situation is the same as for a 939 passive attack, where either a device has to already be compromised 940 or a device can be inserted into the path. This may lead to an 941 attacker impersonating a legitimate routing peer and exchanging 942 routing information. Unintentional active attacks are more common 943 due to configuration errors, which cause legitimate routing peers to 944 feed invalid routing information to other neighboring peers. 946 For off-path active attacks, the attacks are generally limited to 947 message insertion or modification which can divert traffic to 948 illegitimate destinations and cause traffic to never reach its 949 intended destination. 951 2.5.2. Confidentiality Violations 953 Confidentiality violations can occur when a miscreant intercepts any 954 of the routing update traffic. This is becoming more of a concern 955 because many ISPs are classifying addressing schemes and network 956 topologies as private and proprietary information. It is also a 957 concern because the routing protocol packets contain information that 958 may show ways in which routing sessions could be spoofed or hijacked. 959 This in turn could lead into a man-in-the-middle attack where the 960 miscreants can insert themselves into the traffic path or divert the 961 traffic path and violate the confidentiality of user data. 963 2.5.3. Offline Cryptographic Attacks 965 If any cryptographic mechanism was used to provide for data integrity 966 and confidentiality, an offline cryptographic attack could 967 potentially compromise the data. The traffic would need to be 968 captured either by eavesdropping on the network or by being able to 969 divert traffic to a malicious user. Note that by using 970 cryptographically protected routing information, the latter would 971 require the cryptographic key to already be compromised anyway so 972 this attack is only feasible if a device was able eavesdrop and 973 capture the cryptographically protected routing information. 975 2.5.4. Replay Attacks 977 For a replay attack to be successful, the routing control plane 978 traffic would need to first be captured either on-path or diverted to 979 an attacker to later be replayed to the intended recipient. 981 2.5.5. Message Insertion/Deletion/Modification 983 Routing control plane traffic can be manipulated by someone in 984 control of intermediate hosts. In addition, traffic can be injected 985 by forging IP addresses, where a remote router sends out packets 986 which appear to come from another, trusted router. If enough traffic 987 is injected to be processed by limited memory routers it can cause a 988 DoS attack. 990 2.5.6. Man-In-The-Middle 992 A man-in-the-middle attack attacks the identity of a communicating 993 peer rather than the data stream itself. The attacker intercepts 994 traffic that is sent from one routing peer to the other and 995 communicates on behalf of one of the peers. This can lead to 996 diversion of the user traffic to either an unauthorized receiving 997 party or cause legitimate traffic to never reach its intended 998 destination. 1000 2.5.7. Security Practices 1002 Securing the routing control plane takes many features which are 1003 generally deployed as a system. MD5 authentication is used by some 1004 ISPs to validate the sending peer and to ensure that the data in 1005 transit has not been altered. Some ISPs only deploy MD-5 1006 authentication at customer's request. Additional sanity checks to 1007 ensure with reasonable certainty that the received routing update was 1008 originated by a valid routing peer include route filters and the BTSH 1009 feature [BTSH]. Note that validating whether a legitimate peer has 1010 the authority to send the contents of the routing update is a 1011 difficult problem that needs yet to be resolved. 1013 In the case of BGP routing, a variety of policies are deployed to 1014 limit the propagation of invalid routing information. These include: 1015 incoming and outgoing prefix filters for BGP customers, incoming and 1016 outgoing prefix filters for peers and upstream neighbors, incoming 1017 AS-PATH filter for BGP customers, outgoing AS-PATH filter towards 1018 peers and upstream neighbors, route dampening and rejecting selected 1019 attributes and communities. Consistency between these policies 1020 varies greatly although there is a trend to start depending on AS- 1021 PATH filters because they are much more manageable than the large 1022 numbers of prefix filters that would need to be maintained. Many 1023 ISPs also do not propagate interface IP addresses to further reduce 1024 attack vectors on routers and connected customers. 1026 2.5.8. Security Services 1028 o User Authentication - Not applicable 1030 o User Authorization - Not applicable 1031 o Data Origin Authentication - By using MD5 authentication and/or 1032 the TTL-hack a routing peer can be reasonably certain that traffic 1033 originated from a valid peer. 1035 o Access Control - Route filters, AS-PATH filters and prefix limits 1036 are used to control access to specific parts of the network. 1038 o Data Integrity - By using MD5 authentication a peer can be 1039 reasonably certain that the data has not been modified in transit 1040 but there is no mechanism to prove the validity of the routing 1041 information itself. 1043 o Data Confidentiality - Not implemented 1045 o Auditing / Logging - Filter exceptions are logged. 1047 o DoS Mitigation - Many DoS attacks are mitigated using a 1048 combination of techniques including: MD5 authentication, the BTSH 1049 feature, filtering routing advertisements to bogons and filtering 1050 routing advertisements to one's own network. 1052 2.5.9. Additional Considerations 1054 So far the primary concern to secure the routing control plane has 1055 been to validate the sending peer and to ensure that the data in 1056 transit has not been altered. Although MD-5 routing protocol 1057 extensions have been implemented which can provide both services, 1058 they are not consistently deployed amongst ISPs. Two major 1059 deployment concerns have been implementation issues where both 1060 software bugs and the lack of graceful re-keying options have caused 1061 significant network down times. Also, some ISPs express concern that 1062 deploying MD5 authentication will itself be a worse DoS attack victim 1063 and prefer to use a combination of other risk mitigation mechanisms 1064 such as BTSH and route filters. 1066 Route filters are used to limit what routes are believed from a valid 1067 peer. Packet filters are used to limit which systems can appear as a 1068 valid peer. Due to the operational constraints of maintaining large 1069 prefix filter lists, many ISPs are starting to depend on BGP AS-PATh 1070 filters to/from their peers and upstream neighbors. 1072 IPsec is not deployed since the operational management aspects of 1073 ensuring interoperability and reliable configurations is too complex 1074 and time consuming to be operationally viable. There is also limited 1075 concern to the confidentiality of the routing information. The 1076 integrity and validity of the updates are of much greater concern. 1078 There is concern for manual or automated actions which introduce new 1079 routes and can affect the entire routing domain. 1081 2.6. Software Upgrades and Configuration Integrity / Validation 1083 Software upgrades and configuration changes are usually performed as 1084 part of either in-band or OOB management functions. However, there 1085 are additional considerations to be taken into account which are 1086 enumerated in this section. 1088 2.6.1. Threats / Attacks 1090 Attacks performed on system software and configurations can be both 1091 from passive or active sources. Passive attacks are possible if 1092 someone has the capability to intercept data between the network 1093 infrastructure device and the system which is downloading or 1094 uploading the software or configuration information. This can be 1095 accomplished if a single infrastructure device is somehow compromised 1096 and can act as a network sniffer or if it is possible to insert a new 1097 device which acts as a network sniffer. 1099 Active attacks are possible for both on-path and off-path scenarios. 1100 For on-path active attacks, the situation is the same as for a 1101 passive attack, where either a device has to already be compromised 1102 or a device can be inserted into the path. For off-path active 1103 attacks, the attacks are generally limited to message insertion or 1104 modification where the attacker may wish to load illegal software or 1105 configuration files to an infrastructure device. 1107 2.6.2. Confidentiality Violations 1109 Confidentiality violations can occur when a miscreant intercepts any 1110 of the software image or configuration information. The software 1111 image may give an indication of exploits which the device is 1112 vulnerable to while the configuration information can inadvertently 1113 lead attackers to identify critical infrastructure IP addresses and 1114 passwords. 1116 2.6.3. Offline Cryptographic Attacks 1118 If any cryptographic mechanism was used to provide for data integrity 1119 and confidentiality, an offline cryptographic attack could 1120 potentially compromise the data. The traffic would need to be 1121 captured either by eavesdropping on the network or by being able to 1122 divert traffic to a malicious user. 1124 2.6.4. Replay Attacks 1126 For a replay attack to be successful, the software image or 1127 configuration file would need to first be captured either on-path or 1128 diverted to an attacker to later be replayed to the intended 1129 recipient. 1131 2.6.5. Message Insertion/Deletion/Modification 1133 Software images and configuration files can be manipulated by someone 1134 in control of intermediate hosts. By forging an IP address and 1135 impersonating a valid host which can download software images or 1136 configuration files, invalid files can be downloaded to an 1137 infrastructure device. An invalid software image or configuration 1138 file can cause a device to hang and become inoperable. Spoofed 1139 configuration files can be hard to detect, especially when the only 1140 added command is to allow a miscreant access to that device by 1141 entering a filter allowing a specific host access and configuring a 1142 local username/password database entry for authentication to that 1143 device. 1145 2.6.6. Man-In-The-Middle 1147 A man-in-the-middle attack attacks the identity of a communicating 1148 peer rather than the data stream itself. The attacker intercepts 1149 traffic that is sent between the infrastructure device and the host 1150 used to upload/download the system image or configuration file. He/ 1151 she can then act on behalf of one or both of these systems. 1153 If an attacker obtained a copy of the software image being deployed, 1154 he could potentially exploit a known vulnerability and gain access to 1155 the system. From a captured configuration file, he could obtain 1156 confidential network topology information or even more damaging 1157 information if any of the passwords in the configuration file were 1158 not encrypted. 1160 2.6.7. Security Practices 1162 Images and configurations are stored on specific hosts which have 1163 limited access. All access and activity relating to these hosts are 1164 authenticated and logged via AAA services. When uploaded/downloading 1165 any system software or configuration files, either TFTP, FTP or SCP 1166 can be used. Where possible, SCP is used to secure the data transfer 1167 and FTP is generally never used. All TFTP and SCP access is 1168 username/password authenticated and in most environments scripts are 1169 used for maintaining a large number of routers. To ensure the 1170 integrity of the configurations, every hour the configuration files 1171 are polled and compared to the previously polled version to find 1172 discrepancies. In at least one environment these tools are 1173 Kerberized to take advantage of automated authentication (not 1174 confidentiality). 1176 Filters are used to limit access to uploading/downloading 1177 configuration files and system images to specific IP addresses and 1178 protocols. 1180 The software images perform CRC-checks but many ISPs expressed 1181 interest in having software image integrity validation based on the 1182 MD5 algorithm for enhanced security. The system binaries use the MD5 1183 algorithm to validate integrity. 1185 In all configuration files, most passwords are stored in an 1186 obfuscated format. This includes passwords for user authentication, 1187 MD5 shared secrets, AAA server shared secrets, NTP shared secrets, 1188 etc. For older software which may not support this functionality, 1189 configuration files may contain some passwords in readable format. 1190 Most ISPs mitigate any risk of password compromise by either storing 1191 these configuration files without the password lines or by requiring 1192 authenticated and authorized access to the configuration files which 1193 are stored on protected OOB management devices. 1195 Automated security validation is performed on infrastructure devices 1196 using nmap and nessus to ensure valid configuration against many of 1197 the well-known attacks. 1199 2.6.8. Security Services 1201 o User Authentication - All users are authenticated before being 1202 able to download/upload any system images or configuration files. 1204 o User Authorization - All authenticated users are granted specific 1205 privileges to download or upload system images and/or 1206 configuration files. 1208 o Data Origin Authentication - Filters are used to limit access to 1209 uploading/downloading configuration files and system images to 1210 specific IP addresses. 1212 o Access Control - Filters are used to limit access to uploading/ 1213 downloading configuration files and system images to specific IP 1214 addresses and protocols. 1216 o Data Integrity - All systems use either a CRC-check or MD5 1217 authentication to ensure data integrity. 1219 o Data Confidentiality - If the SCP protocol is used then there is 1220 confidentiality of the downloaded/uploaded configuration files and 1221 system images. 1223 o Auditing / Logging - All access and activity relating to 1224 downloading/uploading system images and configuration files are 1225 logged via AAA services and filter exception rules. 1227 o DoS Mitigation - TBD 1229 2.6.9. Additional Considerations 1231 Where the MD5 algorithm is not used to perform data integrity 1232 checking of software images and configuration files, ISPs have 1233 expressed an interest in having this functionality. IPsec is 1234 considered too cumbersome and operationally difficult to use for data 1235 integrity and confidentiality. 1237 2.7. Logging Considerations 1239 Although logging is part of all the previous sections, it is 1240 important enough to be covered as a separate item. The main issues 1241 revolve around what gets logged, how long are logs kept and what 1242 mechanisms are used to secure the logged information while it is in 1243 transit and while it is stored. 1245 2.7.1. Threats / Attacks 1247 Attacks on the logged data can be both from passive or active 1248 sources. Passive attacks are possible if someone has the capability 1249 to intercept data between the recipient logging server and the device 1250 the logged data originated from. This can be accomplished if a 1251 single infrastructure device is somehow compromised and can act as a 1252 network sniffer or if it is possible to insert a new device which 1253 acts as a network sniffer. 1255 Active attacks are possible for both on-path and off-path scenarios. 1256 For on-path active attacks, the situation is the same as for a 1257 passive attack, where either a device has to already be compromised 1258 or a device can be inserted into the path. For off-path active 1259 attacks, the attacks are generally limited to message insertion or 1260 modification which can alter the logged data to keep any compromise 1261 from being detected or to destroy any evidence which could be used 1262 for criminal prosecution. 1264 2.7.1.1. Confidentiality Violations 1266 Confidentiality violations can occur when a miscreant intercepts any 1267 of the logging data which is in transit on the network. This could 1268 lead to privacy violations if some of the logged data has not been 1269 sanitized to disallow any data that could be a violation of privacy 1270 to be included in the logged data. 1272 2.7.1.2. Offline Cryptographic Attacks 1274 If any cryptographic mechanism was used to provide for data integrity 1275 and confidentiality, an offline cryptographic attack could 1276 potentially compromise the data. The traffic would need to be 1277 captured either by eavesdropping on the network or by being able to 1278 divert traffic to a malicious user. 1280 2.7.1.3. Replay Attacks 1282 For a replay attack to be successful, the logging data would need to 1283 first be captured either on-path or diverted to an attacker and later 1284 replayed to the recipient. [is reply handled by syslog protocol?] 1286 2.7.1.4. Message Insertion/Deletion/Modification 1288 Logging data could be injected, deleted or modified by someone in 1289 control of intermediate hosts. Logging data can also be injected by 1290 forging packets from either legitimate or illegitimate IP addresses. 1292 2.7.1.5. Man-In-The-Middle 1294 A man-in-the-middle attack attacks the identity of a communicating 1295 peer rather than the data stream itself. The attacker intercepts 1296 traffic that is sent between the infrastructure device and the 1297 logging server or traffic sent between the logging server and the 1298 database which is used to archive the logged data. Any unauthorized 1299 access to logging information could lead to knowledge of private and 1300 proprietary network topology information which could be used to 1301 compromise portions of the network. An additional concern is having 1302 access to logging information which could be deleted or modified so 1303 as to cover any traces of a security breach. 1305 2.7.2. Security Practices 1307 Logging is mostly performed on an exception auditing basis when it 1308 comes to filtering (i.e. traffic which is NOT allowed is logged). 1309 Typically the data logged will contain the source and destination IP 1310 addresses and layer 4 port numbers as well as a timestamp. The 1311 syslog protocol is used to transfer the logged data between the 1312 infrastructure device to the syslog server. Many ISPs use the OOB 1313 management network to transfer syslog data since there is virtually 1314 no security performed between the syslog server and the device. All 1315 ISPs have multiple syslog servers - some ISPs choose to use separate 1316 syslog servers for varying infrastructure devices (i.e. one syslog 1317 server for backbone routers, one syslog server for customer edge 1318 routers, etc.) 1319 The timestamp is derived from NTP which is generally configured as a 1320 flat hierarchy at stratum1 and stratum2 to have less configuration 1321 and less maintenance. Each router is configured with one stratum1 1322 peer both locally and remotely. 1324 In addition to logging filtering exceptions, the following is 1325 typically logged: Routing protocol state changes, all device access 1326 (regardless of authentication success or failure), all commands 1327 issued to a device, all configuration changes and all router events 1328 (boot-up/flaps). 1330 The main function of any of these log messages is to see what the 1331 device is doing as well as to try and ascertain what certain 1332 malicious attackers are trying to do. Some ISPs put in passive 1333 devices to see routing updates and withdrawals and not rely solely on 1334 the device for log files. This provides a backup mechanism to see 1335 what is going on in the network in the event that a device may 1336 'forget' to do syslog if the CPU is busy. 1338 The logs from the various syslog server devices are generally 1339 transferred into databases at a set interval which can be anywhere 1340 from every 10 minutes to every hour. One ISP uses Rsync to push the 1341 data into a database and then the information is sorted manually by 1342 someone SSH'ing to that database. 1344 2.7.3. Security Services 1346 o User Authentication - Not applicable 1348 o User Authorization - Not applicable 1350 o Data Origin Authentication - Not implemented 1352 o Access Control - Filtering on logging host and server IP address 1353 to ensure that syslog information only goes to specific syslog 1354 hosts. 1356 o Data Integrity - Not implemented 1358 o Data Confidentiality - Not implemented 1360 o Auditing / Logging - This entire section deals with logging. 1362 o DoS Mitigation - TBD 1364 2.7.4. Additional Considerations 1366 There is no security with syslog and ISPs are fully cognizant of 1367 this. IPsec is considered too operationally expensive and cumbersome 1368 to deploy. Syslog-ng and stunnel are being looked at for providing 1369 better authenticated and integrity protected solutions. Mechanisms 1370 to prevent unauthorized personnel from tampering with logs is 1371 constrained to auditing who has access to the logging servers and 1372 files. 1374 ISPs expressed requirements for more than just UDP syslog. They 1375 would also like more granular and flexible facilities and priorities, 1376 i.e. specific logs to specific servers. 1378 2.8. Filtering Considerations 1380 Although filtering has been covered under many of the previous 1381 sections, this section will provide some more insights to the 1382 filtering considerations that are currently being taken into account. 1383 Filtering is now being categorized into three specific areas: data 1384 plane, management plane and routing control plane. 1386 2.8.1. Data Plane Filtering 1388 Data plane filters control the traffic that traverses through a 1389 device and affect transit traffic. Most ISPs deploy these kinds of 1390 filters at the customer facing edge devices to mitigate spoofing 1391 attacks. 1393 2.8.2. Management Plane Filtering 1395 Management filters control the traffic to and from a device. All of 1396 the protocols which are used for device management fall under this 1397 category and includes SSH, Telnet, SNMP, NTP, http, DNS, TFTP, FTP, 1398 SCP and Syslog. This type of traffic is currently filtered per 1399 interface and is based on any combination of protocol, source and 1400 destination IP address and source and destination port number. Note 1401 that logging the filtering rules can today place a burden on many 1402 systems and more granularity is often required to more specifically 1403 log the required exceptions. 1405 IPv6 networks require the use of specific ICMP messages for proper 1406 protocol operation. Therefore, ICMP cannot be completely filtered to 1407 and from a device. Instead, granular ICMPv6 filtering is always 1408 deployed to allow for specific ICMPv6 types to be sourced or destined 1409 to a network device. 1411 2.8.3. Routing Control Plane Filtering 1413 Routing filters are used to control the flow of routing information. 1414 In IPv6 networks, some providers are liberal in accepting /48s due to 1415 the still unresolved multihoming issues. Any announcement received 1416 that is longer than a /48 for IPv6 routing and a /24 for IPv4 routing 1417 is discarded on EBGP. 1419 2.9. Denial of Service Tracking / Tracing 1421 Denial of Service attacks are an ever increasing problem and require 1422 vast amounts of resources to combat effectively. Some large ISPs do 1423 not concern themselves with attack streams that are less than 1G in 1424 bandwidth - this is on the larger pipes where 1G is essentially less 1425 than 5% of offered load. This is largely due to the large amounts of 1426 DDoS traffic which continually requires investigation and mitigation. 1427 At last count the number of hosts making up large distributed DoS 1428 BOTnets exceeded 1 million hosts. 1430 New techniques are continually evolving to automate the process of 1431 detecting DoS sources and mitigating any adverse effects as quickly 1432 as possible. At this time, ISPs are using a variety of mitigation 1433 techniques including: sink hole routing, black-hole triggered 1434 routing, uRPF and rate limiting. Each of these techniques will be 1435 detailed below. 1437 2.9.1. Sink Hole Routing 1439 Sink hole routing refers to injecting a more specific route for any 1440 known attack traffic which will ensure that the malicious traffic is 1441 redirected to a valid subnet or specific IP address where it can be 1442 analyzed. 1444 2.9.2. Black-Hole Triggered Routing 1446 Black-hole triggered routing is a technique where the BGP routing 1447 protocol is used to propagate static routes which in turn redirects 1448 attack traffic to the null interface where it is effectively dropped. 1449 This technique is often used in large routing infrastructures since 1450 BGP can propagate the information in a fast effective manner as 1451 opposed to using any packet-based filtering techniques on hundreds or 1452 thousands of routers. 1454 2.9.3. Unicast Reverse Path Forwarding 1456 Unicast Reverse Path Forwarding (uRPF) is a mechanism for validating 1457 whether an incoming packet has a legitimate source address or not. 1458 It has two modes: strict mode and loose mode. In strict mode, uRPF 1459 checks whether the incoming packet has a source address that matches 1460 a prefix in the routing table, and whether the interface expects to 1461 receive a packet with this source address prefix. If the incoming 1462 packet fails the unicast RPF check, the packet is not accepted on the 1463 incoming interface. Loose mode uRPF is not as specific and the 1464 incoming packet is accepted if there is any route in the routing 1465 table for the source address. 1467 uRPF is not used on interfaces that are likely to have routing 1468 asymmetry, meaning multiple routes to the source of a packet. 1469 Usually for ISPs, uRPF is placed at the customer edge of a network. 1471 2.9.4. Rate Limiting 1473 Rate limiting refers to allocating a specific amount of bandwidth or 1474 packets per second to specific traffic types. This technique is 1475 widely used to mitigate well-known protocol attacks such as the TCP- 1476 SYN attack where a large number of resources get allocated for 1477 spoofed TCP traffic. Although this technique does not stop an 1478 attack, it can lessen the damage and impact on a specific service. 1480 3. Security Considerations 1482 This entire document deals with current security practices in large 1483 ISP environments. As a synopsis, a table is shown below which 1484 summarizes the operational functions which are to be protected and 1485 the security services which currently deployed security practices 1486 offer: [ Table to be added ] 1488 4. Normative References 1490 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1491 Requirement Levels", BCP 14, RFC 2119, March 1997. 1493 [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, 1494 May 2000. 1496 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1497 Text on Security Considerations", BCP 72, RFC 3552, 1498 July 2003. 1500 Appendix A. Acknowledgments 1502 The editor gratefully acknowledges the contributions of: George 1503 Jones, who has been instrumental in providing guidance and direction 1504 for this document and the insighful comments from Ross Callon and the 1505 numerous ISP operators who supplied the information which is depicted 1506 in this document. 1508 Appendix B. Protocol Specific Attacks 1510 This section will enumerate many of the traditional protocol based 1511 attacks which have been observed over the years to cause malformed 1512 packets and/or exploit protocol deficiencies. 1514 B.1. Layer 2 Attacks 1516 o ARP Flooding 1518 B.2. IPv4 Attacks 1520 o IP Stream Option 1522 o IP Address Spoofing 1524 o IP Source Route Option 1526 o IP Short header 1528 o IP Malformed Packet 1530 o Ip Bad Option 1532 o Ip Address Session Limit 1534 o Fragmenmts - too many 1536 o Fragments - large offset 1538 o Fragments - same offset 1540 o Fragments - reassembly with different offsets (TearDrop Attac) 1542 o Fragments - reassembly off by one IP header (Nestea Attack) 1544 o Fragment - flooding only initial fragment (Rose Attack) 1546 o IGMP oversized packet 1548 o ICMP Source Quench 1550 o ICMP Mask Request 1552 o ICMP Large Packet (> 1472) 1553 o ICMP Oversized packet (>65536) 1555 o ICMP Flood 1557 o ICMP Broadcast w/ Spoofed Source (Smurf Attack) 1559 o ICMP Error Packet Flood 1561 o ICMP Spoofed Unreachable 1563 o TCP Packet without Flag 1565 o TCP Oversized Packet 1567 o TCP FIN bit with no ACK bit 1569 o TCP Packet with URG/OOB flag (Nuke Attack) 1571 o SYN Fragments 1573 o SYN Flood 1575 o SYN with IP Spoofing (Land Attack) 1577 o SYN and FIN bits set 1579 o TCP port scan attack 1581 o UDP spoofed broadcast echo (Fraggle Attack) 1583 o UDP attack on diag ports (Pepsi Attack) 1585 B.3. IPv6 Attacks 1587 Any of the above-mentioned IPv4 attacks could be used in IPv6 1588 networks with the exception of any fragmentation and broadcast 1589 traffic, which operate differently in IPv6. 1591 Today, IPv6 enabled hosts are starting to be used to create IPv6 1592 tunnels which can effectively hide botnet and other malicious traffic 1593 if firewalls and network flow collection tools are not capable of 1594 detecting this traffic. 1596 Author's Address 1598 Merike Kaeo 1599 Double Shot Security, Inc. 1600 3518 Fremont Avenue North #363 1601 Seattley, WA 98103 1602 U.S.A. 1604 Phone: +1 310 866 0165 1605 Email: merike@doubleshotsecurity.com 1607 Intellectual Property Statement 1609 The IETF takes no position regarding the validity or scope of any 1610 Intellectual Property Rights or other rights that might be claimed to 1611 pertain to the implementation or use of the technology described in 1612 this document or the extent to which any license under such rights 1613 might or might not be available; nor does it represent that it has 1614 made any independent effort to identify any such rights. Information 1615 on the procedures with respect to rights in RFC documents can be 1616 found in BCP 78 and BCP 79. 1618 Copies of IPR disclosures made to the IETF Secretariat and any 1619 assurances of licenses to be made available, or the result of an 1620 attempt made to obtain a general license or permission for the use of 1621 such proprietary rights by implementers or users of this 1622 specification can be obtained from the IETF on-line IPR repository at 1623 http://www.ietf.org/ipr. 1625 The IETF invites any interested party to bring to its attention any 1626 copyrights, patents or patent applications, or other proprietary 1627 rights that may cover technology that may be required to implement 1628 this standard. Please address the information to the IETF at 1629 ietf-ipr@ietf.org. 1631 Disclaimer of Validity 1633 This document and the information contained herein are provided on an 1634 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1635 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1636 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1637 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1638 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1639 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1641 Copyright Statement 1643 Copyright (C) The Internet Society (2006). This document is subject 1644 to the rights, licenses and restrictions contained in BCP 78, and 1645 except as set forth therein, the authors retain all their rights. 1647 Acknowledgment 1649 Funding for the RFC Editor function is currently provided by the 1650 Internet Society.