idnits 2.17.1 draft-ietf-opsec-current-practices-01.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 1517. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1494. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1501. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1507. ** 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 == Line 373 has weird spacing: '...ransfer proto...' == Line 561 has weird spacing: '...ss. An indiv...' == Line 990 has weird spacing: '...in that the d...' == Line 1124 has weird spacing: '...berized to ta...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 17, 2005) is 6856 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 812, but not defined == Missing Reference: 'BTSH' is mentioned on line 959, but not defined ** Obsolete normative reference: RFC 2828 (Obsoleted by RFC 4949) Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSEC M. Kaeo 3 Internet-Draft Double Shot Security, Inc. 4 Expires: January 18, 2006 July 17, 2005 6 Operational Security Current Practices 7 draft-ietf-opsec-current-practices-01 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 18, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 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 Threat Model . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.2 Operational Security Impact from Threats . . . . . . . . . 3 52 1.3 Document Layout . . . . . . . . . . . . . . . . . . . . . 6 53 1.4 Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 54 2. Protected Operational Functions . . . . . . . . . . . . . . . 8 55 2.1 Device Physical Access . . . . . . . . . . . . . . . . . . 8 56 2.2 Device In-Band Management . . . . . . . . . . . . . . . . 10 57 2.3 Device Out-of-Band Management . . . . . . . . . . . . . . 14 58 2.4 Data Path . . . . . . . . . . . . . . . . . . . . . . . . 18 59 2.5 Routing Control Plane . . . . . . . . . . . . . . . . . . 20 60 2.6 Software Upgrades and Configuration Integrity / 61 Validation . . . . . . . . . . . . . . . . . . . . . . . . 24 62 2.7 Logging Considerations . . . . . . . . . . . . . . . . . . 27 63 2.8 Denial of Service Tracking / Tracing . . . . . . . . . . . 30 64 3. Security Considerations . . . . . . . . . . . . . . . . . . . 32 65 4. Normative References . . . . . . . . . . . . . . . . . . . . . 32 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 32 67 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 68 B. Protocol Specific Attacks . . . . . . . . . . . . . . . . . . 34 69 Intellectual Property and Copyright Statements . . . . . . . . 36 71 1. Introduction 73 Security practices are well understood by the network operators who 74 have for many years gone through the growing pains of securing their 75 network infrastructures. However, there does not exist a written 76 document that enumerates these security practices. Network attacks 77 are continually increasing and although it is not necessarily the 78 role of an ISP to act as the Internet police, each ISP has to ensure 79 that certain security practices are followed to ensure that their 80 network is operationally available for their customers. This 81 document is the result of a survey conducted to find out what current 82 security practices are being deployed to secure network 83 infrastructures. 85 1.1 Threat Model 87 The scope for this survey is restricted to security practices that 88 mitigate exposure to risks with the potential to adversely impact 89 network availability and reliability. Securing the actual data 90 traffic is outside the scope of the conducted survey. This document 91 focuses solely on documenting currently deployed security mechanisms 92 for layer 2 and layer 3 network infrastructure devices. 94 1.2 Operational Security Impact from Threats 96 A threat is a potential for a security violation, which exists when 97 there is a circumstance, capability, action, or event that could 98 breach security and cause harm [RFC2828]. Every operational network 99 is subject to a multitude of threat actions, or attacks, i.e. an 100 assault on system security that derives from an intelligent act that 101 is a deliberate attempt to evade security services and violate the 102 security policy of a system [RFC2828]. These attacks can be sourced 103 in a variety of ways: 105 Active vs passive attacks 107 An active attack involves writing data to the network. It is 108 common practice in active attacks to disguise one's address and 109 conceal the identity of the traffic sender. A passive attack 110 involves only reading information off the network. This is 111 possible if the attacker has control of a host in the 112 communications path between two victim machines or has compromised 113 the routing infrastructure to specifically arrange that traffic 114 pass through a compromised machine. In general, the goal of a 115 passive attack is to obtain information that the sender and 116 receiver would prefer to remain private. [RFC3552] 118 On-path vs off-path attacks 120 In order for a datagram to be transmitted from one host to 121 another, it generally must traverse some set of intermediate links 122 and routers. Such routers are naturally able to read, modify, or 123 remove any datagram transmitted along that path. This makes it 124 much easier to mount a wide variety of attacks if you are on-path. 125 Off-path hosts can transmit arbitrary datagrams that appear to 126 come from any hosts but cannot necessarily receive datagrams 127 intended for other hosts. Thus, if an attack depends on being 128 able to receive data, off-path hosts must first subvert the 129 topology in order to place themselves on-path. This is by no 130 means impossible but is not necessarily trivial. [RFC3552] 132 Insider or outsider attacks 134 An "insider attack" is one which is initiated from inside a given 135 security perimeter, by an entity that is authorized to access 136 system resources but uses them in a way not approved by those who 137 granted the authorization. An "outside attack" is initiated from 138 outside the perimeter, by an unauthorized or illegitimate user of 139 the system. 141 Deliberate attacks vs unintentional events 143 A deliberate attack is one where a miscreant intentionally 144 performs an assault on system security. However, there are also 145 instances where unintentional events cause the same harm yet are 146 performed without malice in mind. Configuration errors and 147 software bugs can be as devastating to network availability as any 148 deliberate attack on the network infrastructure. 150 The attack source can be a combination of any of the above, all of 151 which need to be considered when trying to ascertain what impact any 152 attack can have on the availability and reliability of the network. 153 It is nearly impossible to stop insider attacks or unintentional 154 events. However, if appropriate monitoring mechanisms are in place, 155 these attacks can be as easily detected and mitigated as with any 156 other attack source. Any of the specific attacks discussed further 157 in this document will elaborate on attacks which are sourced by an 158 "outsider" and are deliberate attacks. Some further elaboration will 159 be given to the feasibility of passive vs active and on-path vs off- 160 path attacks to show the motivation behind deploying certain security 161 features. 163 The threat consequences are the security violations which results 164 from a threat action, i.e. an attack. These are typically classified 165 as follows: 167 (Unauthorized) Disclosure 169 A circumstance or event whereby an entity gains access to data for 170 which the entity is not authorized. 172 Deception 174 A circumstance or event that may result in an authorized entity 175 receiving false data and believing it to be true. 177 Disruption 179 A circumstance or event that interrupts or prevents the correct 180 operation of system services and functions. A broad variety of 181 attacks, collectively called denial of service attacks, threaten 182 the availability of systems and bandwidth to legitimate users. 183 Many such attacks are designed to consume machine resources, 184 making it difficult or impossible to serve legitimate users. 185 Other attacks cause the target machine to crash, completely 186 denying service to users. 188 Usurpation 190 A circumstance or event that results in control of system services 191 or functions by an unauthorized entity. Most network 192 infrastructure systems are only intended to be completely 193 accessible to certain authorized individuals. Should an 194 unauthorized person gain access to critical layer 2 / layer 3 195 infrastructure devices or services, they could cause great harm to 196 the reliability and availability of the network. 198 A complete description of threat actions that can cause these threat 199 consequences can be found in [RFC2828]. Typically, a number of 200 different network attacks are used in combination to cause one or 201 more of the above mentioned threat consequences. An example would be 202 a malicious user who has the capability to eavesdrop on traffic. 203 First, he may listen in on traffic for a while to do some 204 reconnaissance work and ascertain which IP addresses belonged to 205 specific devices such as routers. Were this miscreant to obtain 206 information such as a router password sent in cleartext, he can then 207 proceed to compromise the actual router. From there, the miscreant 208 can launch various active attacks such as sending bogus routing 209 updates to redirect traffic or capture additional traffic to 210 compromise other network devices. 212 1.3 Document Layout 214 This document is a survey of current operational practices that 215 mitigate the risk of being susceptible to any threat actions. As 216 such, the main focus is on the currently deployed security practices 217 used to detect and/or mitigate attacks. The top-level categories in 218 this document are based on operational functions for ISPs and 219 generally relate to what is to be protected. This is followed by a 220 description of which attacks are possible and the security practices 221 currently deployed which will provide the necessary security services 222 to help mitigate these attacks. These security services are 223 classified as: 225 o User Authentication 227 o User Authorization 229 o Data Origin Authentication 231 o Access Control 233 o Data Integrity 235 o Data Confidentiality 237 o Auditing / Logging 239 o DoS Mitigation 241 In many instances, a specific protocol currently deployed will offer 242 a combination of these services. For example, AAA can offer user 243 authentication, user authorization and audit / logging services while 244 SSH can provide data origin authentication, data integrity and data 245 confidentiality. The services offered are more important than the 246 actual protocol used. Each section ends with an additional 247 considerations section which explains why specific protocols may or 248 may not be used and also gives some information regarding 249 capabilities which are not possible today due to bugs or lack of ease 250 of use. 252 1.4 Definitions 253 RFC 2119 Keywords 255 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 256 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 257 in this document are to be interpreted as described in [RFC2119]. 259 The use of the RFC 2119 keywords is an attempt, by the editor, to 260 assign the correct requirement levels ("MUST", "SHOULD", 261 "MAY"...). It must be noted that different organizations, 262 operational environments, policies and legal environments will 263 generate different requirement levels. 265 2. Protected Operational Functions 267 2.1 Device Physical Access 269 Device physical access pertains to protecting the physical location 270 of the layer 2 or layer 3 network infrastructure device. Although it 271 is important to have contingency plans for natural disasters such as 272 earthquakes and floods which can cause damage to networking devices, 273 this is out-of-scope for this document. Here we concern ourselves 274 with protecting access to the physical location and how a device can 275 be further protected from unauthorized access if the physical 276 location has been compromised, i.e protecting the console access. 278 2.1.1 Threats / Attacks 280 If any intruder gets physical access to a layer 2 or layer 3 device, 281 the entire network infrastructure can be under the control of the 282 intruder. At a minimum, the intruder can take the compromised device 283 out-of-service, causing network disruption, the extent of which 284 depends on the network topology. A worse scenario is where the 285 intruder can use this device to crack the console password and have 286 complete control of the device, perhaps without anyone detecting such 287 a compromise, or to attach another network device onto a port and 288 siphon off data with which the intruder can ascertain the network 289 topology and take control of the entire network. 291 The threat of gaining physical access can be realized in a variety of 292 ways even if critical devices are under high-security. There still 293 occur cases where attackers have impersonated maintenance workers to 294 gain physical access to critical devices that have caused major 295 outages and privacy compromises. Insider attacks from authorized 296 personnel also pose a real threat and must be adequately recognized 297 and dealt with. 299 2.1.2 Security Practices 301 For physical device security, equipment is kept in highly restrictive 302 environments. Only authorized users with card key badges have access 303 to any of the physical locations that contain critical network 304 infrastructure devices. These card-key systems keep track of who 305 accessed which location and at what time. 307 All console access is always password protected and the login time is 308 set to time out after a specified amount of inactivity - typically 309 between 3-10 minutes. Individual users are authentication to get 310 basic access. For privileged (i.e. enable) access, a second 311 authentication step needs to be completed. Typically all console 312 access is provided via an out-of-band (OOB) management infrastructure 313 which is discussed in the section on OOB management. 315 2.1.3 Security Services 317 The following security services are offered through the use of the 318 practices described in the previous section: 320 o User Authentication - All individuals who have access to the 321 physical facility are authenticated. Console access is 322 authenticated. 324 o User Authorization - An authenticated individual has implicit 325 authorization to perform commands on the device. Console access 326 is usually granted via at least two privilege levels: 327 authorization for performing a basic set of commands vs 328 authorization for performing all commands. 330 o Data Origin Authentication - Not applicable 332 o Access Control - Not applicable 334 o Data Integrity - Not applicable 336 o Data Confidentiality - Not applicable 338 o Auditing / Logging - All access to the physical locations of the 339 infrastructure equipment is logged via electronic card-key 340 systems. All console access is logged (refer to the OOB 341 management section for more details) 343 o DoS Mitigation - Not applicable 345 2.1.4 Additional Considerations 347 Physical security is relevant to operational security practices as 348 described in this document mostly from a console access perspective. 349 Most ISPs provide console access via an OOB management infrastructure 350 which is discussed in the OOB management section of this document. 352 The physical and logical authentication and logging systems should be 353 run independently of each other and reside in different physical 354 locations. 356 Social engineering plays a big role in many physical access 357 compromises. Most ISPs have set up training classes and awareness 358 programs to educate company personnel to deny physical access to 359 people who are not properly authenticated or authorized to have 360 physical access to critical infrastructure devices. 362 2.2 Device In-Band Management 364 In-band management is generally considered to be device access where 365 the control traffic takes the same data path as the data which 366 traverses the network. In many environments, device management for 367 layer 2 and layer 3 infrastructure devices is deployed as part of an 368 out-of-band management infrastructure although there are some 369 instances where it is deployed in-band as well. Presently, the 370 mechanisms used for in-band management are via virtual terminal 371 access (i.e. Telnet or SSH), SNMP, or HTTP. In all large ISPs that 372 were interviewed, HTTP management is never used and is explicitly 373 disabled. Note that file transfer protocols (TFTP, FTP, SCP) will 374 be covered in the 'Software Upgrades and Configuration Integrity/ 375 Validation' section. 377 2.2.1 Threats / Attacks 379 For in-band device management, passive attacks are possible if 380 someone has the capability to intercept data between the management 381 device and the managed device. The threat is possible if a single 382 infrastructure device is somehow compromised and can act as a network 383 sniffer or if it is possible to insert a new device which acts as a 384 network sniffer. 386 Active attacks are possible for both on-path and off-path scenarios. 387 For on-path active attacks, the situation is the same as for a 388 passive attack, where either a device has to already be compromised 389 or a device can be inserted into the path. For off-path active 390 attacks, the attack is generally limited to message insertion or 391 modification. 393 2.2.1.1 Confidentiality Violations 395 Confidentiality violations can occur when a miscreant intercepts 396 confidential data that has been sent in cleartext. This includes 397 interception of usernames and passwords with which an intruder can 398 obtain unauthorized access to network devices. It can also include 399 other information such as logging or configuration information if an 400 administrator is remotely viewing local logfiles or configuration 401 information. 403 2.2.1.2 Offline Cryptographic Attacks 405 If username/password information was encrypted but the cryptographic 406 mechanism used made it easy to capture data and break the encryption 407 key, the device management traffic could be compromised. The traffic 408 would need to be captured either by eavesdropping on the network or 409 by being able to divert traffic to a malicious user. 411 2.2.1.3 Replay Attacks 413 For a replay attack to be successful, in-band management traffic 414 would need to first be captured either on-path or diverted to an 415 attacker to later be replayed to the intended recipient. 417 2.2.1.4 Message Insertion/Deletion/Modification 419 Data can be manipulated by someone in control of intermediary hosts. 420 Forging data is also possible with IP spoofing, where a remote host 421 sends out packets which appear to come from another, trusted host. 423 2.2.1.5 Man-In-The-Middle 425 A man-in-the-middle attack attacks the identity of a communicating 426 peer rather than the data stream itself. The attacker intercepts 427 traffic that is sent from an in-band management system to the 428 networking infrastructure device and traffic that is sent from the 429 network infrastructure device to the in-band management system. 431 2.2.2 Security Practices 433 All in-band management access to layer 2 and layer 3 devices is 434 authenticated. The user authentication and authorization is 435 typically controlled by a AAA server (i.e. RADIUS and/or TACACS+). 436 Credentials used to determine the identity of the user vary from 437 static username/password to one-time username/password scheme such as 438 Secure-ID. Static username/passwords are expired after a specified 439 period of time, usually 30 days. Every authenticated entity via AAA 440 is an individual user for greater granularity of control. In some 441 deployments, The AAA servers used for in-band management 442 authentication/authorization/accounting are on separate out-of-band 443 networks to provide a demarcation for any other authentication 444 functions. 446 For backup purposes, there is often a single local database entry for 447 authentication which is known to a very limited set of key personnel. 448 It is usually the highest privilege level username/password 449 combination, which in most cases is the same across all devices. 450 This local device password is routinely regenerated once every 2-3 451 months and is also regenerated immediately after an employee who had 452 access to that password leaves the company or is no longer authorized 453 to have knowledge of that password. 455 Each individual user in the AAA database is configured with specific 456 authorization capability. Specific commands are either individually 457 denied or permitted depending on the capability of the device to be 458 accessed. Multiple privilege levels are deployed. Most individuals 459 are authorized with basic authorization to perform a minimal set of 460 commands while a subset of individuals are authorized to perform more 461 privileged commands. 463 SSH is always used for virtual terminal access to provide for an 464 encrypted communication channel. There are exceptions due to 465 equipment limitations which are described in the additional 466 considerations section. 468 If SNMP is used for in-band management, it is for read queries only 469 and restricted to specific hosts. The community strings are 470 carefully chosen to be difficult to crack and there are procedures in 471 place to change these community strings between 30-90 days. If 472 systems support two SNMP community strings, the old string is 473 replaced by first configuring a second newer community string and 474 then migrating over from the currently used string to the newer one. 475 Most large ISPs have multiple SNMP systems accessing their routers so 476 it takes more then one maintenance period to get all the strings 477 fixed in all the right systems. SNMP RW is not used and disabled by 478 configuration. 480 Access control is strictly enforced for infrastructure devices by 481 using stringent filtering rules. A limited set of IP addresses are 482 allowed to initiate connections to the infrastructure devices and are 483 specific to the services which they are to limited to (i.e. SSH and 484 SNMP). 486 All in-band device management access is audited and any violations 487 trigger alarms which initiate automated email, pager and/or telephone 488 notifications. AAA servers keeps track of the authenticated entity 489 as well as all the commands that were carried out on a specific 490 device. Additionally, the device itself logs any access control 491 violations (i.e. if an SSH request comes in from an IP address which 492 is not explicitly permitted, that event is logged so that the 493 offending IP address can be tracked down and investigations made as 494 to why it was trying to access a particular infrastructure device) 496 2.2.3 Security Services 498 The following security services are offered through the use of the 499 practices described in the previous section: 501 o User Authentication - All individuals are authenticated via AAA 502 services. 504 o User Authorization - All individuals are authorized via AAA 505 services to perform specific operations once successfully 506 authenticated. 508 o Data Origin Authentication - Management traffic is strictly 509 filtered to allow only specific IP addresses to have access to the 510 infrastructure devices. This does not alleviate risk from spoofed 511 traffic. Using SSH for device access ensures that noone can spoof 512 the traffic during the SSH session. 514 o Access Control - In-band management traffic is filtered to allow 515 only specific IP addresses to have access to the infrastructure 516 devices. 518 o Data Integrity - Using SSH provides data integrity and ensures 519 that noone has altered the management data in transit. 521 o Data Confidentiality - Using SSH provides data confidentiality. 523 o Auditing / Logging - Using AAA provides an audit trail for who 524 accessed which device and which operations were performed. 526 o DoS Mitigation - Using packet filters to allow only specific IP 527 addresses to have access to the infrastructure devices. This 528 limits but does not prevent spoofed DoS attacks directed at an 529 infrastructure device. Often OOB management is used to lower that 530 risk. 532 2.2.4 Additional Considerations 534 Password selection for any in-band device management protocol used is 535 critical to ensure that the passwords are hard to guess or break 536 using a brute-force attack. 538 IPsec is considered too difficult to deploy and the common protocol 539 to provide for confidential in-band management access is SSH. There 540 are exceptions for using SSH due to equipment limitations since SSH 541 may not be supported on legacy equipment. Also, in the case where 542 the SSH key is stored on a route processor card, a re-keying of SSH 543 would be required whenever the route processor card needs to be 544 swapped. Some providers feel that this operational impact exceeds 545 the security necessary and instead use Telnet from trusted inside 546 hosts (called 'jumphosts') to manage those devices. An individual 547 would first SSH to the jumphost and then Telnet from the jumphost to 548 the actual infrastructure device. All authentication and 549 authorization is still carried out using AAA servers. 551 In instances where Telnet access is used, the logs on the AAA servers 552 are more verbose and more attention is paid to them to detect any 553 abnormal behavior. The jumphosts themselves are carefully controlled 554 machines and usually have limited access. Note that Telent is NEVER 555 allowed to an infrastructure device except from specific jumphosts; 556 i.e. packet filters are used to ensure that Telnet is only allowed 557 from specific IP addresses. 559 With thousands of devices to manage, some ISPs have created automated 560 mechanisms to authenticate to devices. Kerberos is used to automate 561 the authentication process. An individual would first log in to a 562 Kerberized UNIX server using SSH and generate a Kerberos 'ticket'. 563 This 'ticket' is generally set to have a lifespan of 10 hours and is 564 used to automatically authenticate the individual to the 565 infrastructure devices. 567 In instances where SNMP is used, some legacy devices only support 568 SNMPv1 which then requires the provider to mandate its use across all 569 infrastructure devices for operational simplicity. SNMPv2 is 570 primarily deployed since it is easier to set up than v3. 572 2.3 Device Out-of-Band Management 574 Out-of-band management is generally considered to be device access 575 where the control traffic takes a separate path as the data which 576 traverses the network. Console access is always architected via an 577 OOB network. SNMP management is also usually carried out via that 578 same OOB network infrastructure. 580 2.3.1 Threats / Attacks 582 For OOB device management, passive attacks are possible if someone 583 has the capability to intercept data between the management device 584 and the managed device. The threat is possible if a single 585 infrastructure device is somehow compromised and can act as a network 586 sniffer or if it is possible to insert a new device which acts as a 587 network sniffer. 589 Active attacks are possible for both on-path and off-path scenarios. 590 For on-path active attacks, the situation is the same as for a 591 passive attack, where either a device has to already be compromised 592 or a device can be inserted into the path. For off-path active 593 attacks, the attack is generally limited to message insertion or 594 modification. 596 2.3.1.1 Confidentiality Violations 598 Confidentiality violations can occur when a miscreant intercepts any 599 of the OOB management data that has been sent in cleartext. This 600 includes interception of usernames and passwords with which an 601 intruder can obtain unauthorized access to network devices. It can 602 also include other information such as logging or configuration 603 information if an administrator is remotely viewing local logfiles or 604 configuration information. 606 2.3.1.2 Offline Cryptographic Attacks 608 If username/password information was encrypted but the cryptographic 609 mechanism used made it easy to capture data and break the encryption 610 key, the OOB management traffic could be compromised. The traffic 611 would need to be captured either by eavesdropping on the network or 612 by being able to divert traffic to a malicious user. 614 2.3.1.3 Replay Attacks 616 For a replay attack to be successful, the OOB management traffic 617 would need to first be captured either on-path or diverted to an 618 attacker to later be replayed to the intended recipient. 620 2.3.1.4 Message Insertion/Deletion/Modification 622 Data can be manipulated by someone in control of intermediary hosts. 623 Forging data is also possible with IP spoofing, where a remote host 624 sends out packets which appear to come from another, trusted host. 626 2.3.1.5 Man-In-The-Middle 628 A man-in-the-middle attack attacks the identity of a communicating 629 peer rather than the data stream itself. The attacker intercepts 630 traffic that is sent from an OOB management system to the networking 631 infrastructure device and traffic that is sent from the network 632 infrastructure device to the OOB management system. 634 2.3.2 Security Practices 636 OOB is done via a terminal server at each location. SSH access is 637 used to get to the terminal server from where sessions to the devices 638 are initiated. Dial-in access is deployed as a backup if the network 639 is not available. 641 All OOB management access to layer 2 and layer 3 devices is 642 authenticated. The user authentication and authorization is 643 typically controlled by a AAA server (i.e. RADIUS and/or TACACS+). 645 Credentials used to determine the identity of the user vary from 646 static username/password to one-time username/password scheme such as 647 Secure-ID. Static username/passwords are expired after a specified 648 period of time, usually 30 days. Every authenticated entity via AAA 649 is an individual user for greater granularity of control. Note that 650 often the AAA server used for OOB management authentication is a 651 separate physical device from the AAA server used for in-band 652 management user authentication. 654 For backup purposes, there is often a single local database entry for 655 authentication which is known to a very limited set of key personnel. 656 It is usually the highest privilege level username/password 657 combination, which in most cases is the same across all devices. 658 This local device password is routinely regenerated once every 2-3 659 months and is also regenerated immediately after an employee who had 660 access to that password leaves the company or is no longer authorized 661 to have knowledge of that password. 663 Each individual user in the AAA database is configured with specific 664 authorization capability. Specific commands are either individually 665 denied or permitted depending on the capability of the device to be 666 accessed. Multiple privilege levels are deployed. Most individuals 667 are authorized with basic authorization to perform a minimal set of 668 commands while a subset of individuals are authorized to perform more 669 privileged commands. 671 Some OOB management functions are performed using command line 672 interface (CLI) scripting. In these scenarios, a dedicated user is 673 used for the identity in scripts that perform CLI scripting. Once 674 authenticated, these scripts control which commands are legitimate 675 depending on authorization rights of the authenticated individual. 677 SSH is always used for virtual terminal access to provide for an 678 encrypted communication channel. There are exceptions due to 679 equipment limitations which are described in the additional 680 considerations section. 682 If SNMP is used for OOB management, it is for read queries only and 683 restricted to specific hosts. The community strings are carefully 684 chosen to be difficult to crack and there are procedures in place to 685 change these community strings between 30-90 days. If systems 686 support two SNMP strings, a second new string is set and then migrate 687 over from the 1st to the 2nd. Most large ISPs have multiple SNMP 688 systems accessing their routers so it takes more then one maintenance 689 period to get all the strings fixed in all the right systems. SNMP 690 RW is not used and disabled by configuration. 692 Access control is strictly enforced for infrastructure devices by 693 using stringent filtering rules. A limited set of IP addresses are 694 allowed to initiate connections to the infrastructure devices and are 695 specific to the services which they are to limited to (i.e. SSH and 696 SNMP). 698 All OOB device management access is audited. The AAA server keeps 699 track of the authenticated entity as well as all the commands that 700 were carried out on a specific device. Additionally, the device 701 itself logs any access control violations (i.e. if an SSH request 702 comes in from an IP address which is not explicitly permitted, that 703 event is logged so that the offending IP address can be tracked down 704 and investigations made as to why it was trying to access a 705 particular infrastructure device) 707 2.3.3 Security Services 709 The security services offered for device OOB management are nearly 710 identical to those of device in-band management. Due to the critical 711 nature of controlling and limiting device access, many ISPs feel that 712 physically separating the management traffic from the normal customer 713 data traffic will provide an added level of risk mitigation and limit 714 the potential attack vectors. For OOB management, the security 715 services offered through the use of the practices described in the 716 previous section are: 718 o User Authentication - All individuals are authenticated via AAA 719 services. 721 o User Authorization - All individuals are authorized via AAA 722 services to perform specific operations once successfully 723 authenticated. 725 o Data Origin Authentication - Management traffic is strictly 726 filtered to allow only specific IP addresses to have access to the 727 infrastructure devices. This does not alleviate risk from spoofed 728 traffic. Using SSH for device access ensures that noone can spoof 729 the traffic during the SSH session. 731 o Access Control - In-band management traffic is filtered to allow 732 only specific IP addresses to have access to the infrastructure 733 devices. 735 o Data Integrity - Using SSH provides data integrity and ensures 736 that noone has altered the management data in transit. 738 o Data Confidentiality - Using SSH provides data confidentiality. 740 o Auditing / Logging - Using AAA provides an audit trail for who 741 accessed which device and which operations were performed. 743 o DoS Mitigation - Using packet filters to allow only specific IP 744 addresses to have access to the infrastructure devices. This 745 limits but does not prevent spoofed DoS attacks directed at an 746 infrastructure device. However, the risk is lowered by using a 747 separate physical network for management purposes. 749 2.3.4 Additional Considerations 751 Password selection for any OOB device management protocol used is 752 critical to ensure that the passwords are hard to guess or break 753 using a brute-force attack. 755 IPsec is considered too difficult to deploy and the common protocol 756 to provide for confidential OOB management access is SSH. There are 757 exceptions for using SSH due to equipment limitations since SSH may 758 not be supported on legacy equipment. Also, in the case where the 759 SSH key is stored on a route processor card, a re-keying of SSH would 760 be required whenever the route processor card needs to be swapped. 761 Some providers feel that this operational impact exceeds the security 762 necessary and instead use Telnet from trusted inside hosts (called 763 'jumphosts') to manage those device. An individual would first SSH 764 to the jumphost and then Telnet from the jumphost to the terminal 765 server before logging in to the device console. All authentication 766 and authorization is still carried out using AAA servers. 768 In instances where Telnet access is used, the logs on the AAA servers 769 are more verbose and more attention is paid to them to detect any 770 abnormal behavior. The jumphosts themselves are carefully controlled 771 machines and usually have limited access. Note that Telent is NEVER 772 allowed to an infrastructure device except from specific jumphosts; 773 i.e. packet filters are used at the console server and/or 774 infrastructure device to ensure that Telnet is only allowed from 775 specific IP addresses. 777 In instances where SNMP is used, some legacy devices only support 778 SNMPv1 which then requires the provider to mandate its use across all 779 infrastructure devices for operational simplicity. SNMPv2 is 780 primarily deployed since it is easier to set up than v3. 782 2.4 Data Path 784 This section refers to how traffic is handled which traverses the 785 network infrastructure device. The primary goal of ISPs is to 786 forward customer traffic. However, due to the large amount of 787 malicious traffic that can cause DoS attacks and render the network 788 unavailable, specific measures are sometimes deployed to ensure the 789 availability to forward legitimate customer traffic. 791 2.4.1 Threats / Attacks 793 Any data traffic can potentially be attack traffic and the challenge 794 is to detect and potentially stop forwarding any of the malicious 795 traffic. The deliberately sourced attack traffic can consist of 796 packets with spoofed source and/or destination addresses or any other 797 malformed packet which mangle any portion of a header field to cause 798 protocol-related security issues (such as resetting connections, 799 causing unwelcome ICPM redirects, creating unwelcome IP options or 800 packet fragmentations). 802 2.4.2 Security Practices 804 Filtering and rate limiting are the primary mechanism to provide risk 805 mitigation of malicious traffic rendering the ISP services 806 unavailable. However, filtering and rate limiting of data path 807 traffic is deployed in a variety of ways depending on how automated 808 the process is and what the capabilities and performance limitations 809 of existing deployed hardware are. 811 The ISPs which do not have performance issues with their equipment 812 follow BCP38 [BCP38] guidelines. Null routes and black-hole 813 filtering are used to deter any detected malicious traffic streams. 814 Most ISPs consider layer 4 filtering useful but it is only 815 implemented if there is no performance limitations on the devices. 816 Netflow is used for tracking traffic flows but there is some concern 817 whether sampling is good enough to detect malicious behavior. 819 Unicast RPF is not consistently implemented. Some ISPs are in 820 process of doing so while other ISPs think that the perceived benefit 821 of knowing that spoofed traffic comes from legitimate addresses are 822 not worth the operational complexity. Some providers have a policy 823 of implementing uRPF at link speeds of DS3 and below. 825 2.4.3 Security Services 827 o User Authentication - Not applicable 829 o User Authorization - Not applicable 831 o Data Origin Authentication - When IP address filtering per BCP38 832 and uRPF are deployed at network edges it can ensure that any 833 spoofed traffic comes from at least a legitimate IP address and 834 can be tracked. 836 o Access Control - IP address filtering and layer 4 filtering is 837 used to deny forbidden protocols and limit traffic destined for 838 infrastructure device itself. 840 o Data Integrity - Not applicable 842 o Data Confidentiality - Not applicable 844 o Auditing / Logging - Filtering exceptions are logged for potential 845 attack traffic. 847 o DoS Mitigation - Black-hole triggered filtering and rate-limiting 848 are used to limit the risk of DoS attacks. 850 2.4.4 Additional Considerations 852 For layer 2 devices, MAC address filtering and authentication is not 853 used. This is due to the problems it can cause when troubleshooting 854 networking issues. Port security becomes unmanageable at a large 855 scale where 1000s of switches are deployed. 857 Rate limiting is used by some ISPs although other ISPs believe it is 858 not really useful since attackers are not well behaved and it doesn't 859 provide any operational benefit over the complexity. Rate limiting 860 may be improved by developing flow-based rate-limiting capabilities 861 with filtering hooks. This would improve the performance as well as 862 the granularity over current capabilities. 864 Lack of consistency regarding the ability to filter, especially with 865 respect to performance issues cause some ISPs to not implement BCP38 866 guidelines for ingress filtering. One such example is at edge boxes 867 where you have up to 1000 T1's connecting into a router with an OC-12 868 uplink. Some deployed devices experience a large performance impact 869 with filtering which is unacceptable for passing customer traffic 870 through. Where performance is not an issue, the ISPs make a tradeoff 871 between management versus risk. 873 2.5 Routing Control Plane 875 The routing control plane deals with all the traffic which is part of 876 establishing and maintaining routing protocol information. 878 2.5.1 Threats / Attacks 880 Attacks on the routing control plane can be both from passive or 881 active sources. Passive attacks are possible if someone has the 882 capability to intercept data between the communicating routing peers. 883 This can be accomplished if a single routing peer is somehow 884 compromised and can act as a network sniffer or if it is possible to 885 insert a new device which acts as a network sniffer. 887 Active attacks are possible for both on-path and off-path scenarios. 888 For on-path active attacks, the situation is the same as for a 889 passive attack, where either a device has to already be compromised 890 or a device can be inserted into the path. This may lead to an 891 attacker impersonating a legitimate routing peer and exchanging 892 routing information. Unintentional active attacks are more common 893 due to configuration errors, which cause legitimate routing peers to 894 feed invalid routing information to other neighboring peers. 896 For off-path active attacks, the attacks are generally limited to 897 message insertion or modification which can divert traffic to 898 illegitimate destinations and cause traffic to never reach its 899 intended destination. 901 2.5.2 Confidentiality Violations 903 Confidentiality violations can occur when a miscreant intercepts any 904 of the routing update traffic. This is becoming more of a concern 905 because many ISPs are classifying addressing schemes and network 906 topologies as private and proprietary information. It is also a 907 concern because the routing protocol packets contain information that 908 may show ways in which routing sessions could be spoofed or hijacked. 909 This in turn could lead into a man-in-the-middle attack where the 910 miscreants can insert themselves into the traffic path or divert the 911 traffic path and violate the confidentiality of user data. 913 2.5.3 Offline Cryptographic Attacks 915 If any cryptographic mechanism was used to provide for data integrity 916 and confidentiality, an offline cryptographic attack could 917 potentially compromise the data. The traffic would need to be 918 captured either by eavesdropping on the network or by being able to 919 divert traffic to a malicious user. Note that by using 920 cryptographically protected routing information, the latter would 921 require the cryptographic key to already be compromised anyway so 922 this attack is only feasible if a device was able eavesdrop and 923 capture the cryptographically protected routing information. 925 2.5.4 Replay Attacks 927 For a replay attack to be successful, the routing control plane 928 traffic would need to first be captured either on-path or diverted to 929 an attacker to later be replayed to the intended recipient. 931 2.5.5 Message Insertion/Deletion/Modification 933 Routing control plane traffic can be manipulated by someone in 934 control of intermediate hosts. In addition, traffic can be injected 935 by forging IP addresses, where a remote router sends out packets 936 which appear to come from another, trusted router. If enough traffic 937 is injected to be processed by limited memory routers it can cause a 938 DoS attack. 940 2.5.6 Man-In-The-Middle 942 A man-in-the-middle attack attacks the identity of a communicating 943 peer rather than the data stream itself. The attacker intercepts 944 traffic that is sent from one routing peer to the other and 945 communicates on behalf of one of the peers. This can lead to 946 diversion of the user traffic to either an unauthorized receiving 947 party or cause legitimate traffic to never reach its intended 948 destination. 950 2.5.7 Security Practices 952 Securing the routing control plane takes many features which are 953 generally deployed as a system. MD5 authentication is used by some 954 ISPs to validate the sending peer and to ensure that the data in 955 transit has not been altered. Some ISPs only deploy MD-5 956 authentication at customer's request. Additional sanity checks to 957 ensure with reasonable certainty that the received routing update was 958 originated by a valid routing peer include route filters and the BTSH 959 feature [BTSH]. Note that validating whether a legitimate peer has 960 the authority to send the contents of the routing update is a 961 difficult problem that needs yet to be resolved. 963 In the case of BGP routing, a variety of policies are deployed to 964 limit the propagation of invalid routing information. These include: 965 incoming and outgoing prefix filters for BGP customers, incoming and 966 outgoing prefix filters for peers and upstream neighbors, incoming 967 AS-PATH filter for BGP customers, outgoing AS-PATH filter towards 968 peers and upstream neighbors, route dampening and rejecting selected 969 attributes and communities. Consistency between these policies 970 varies greatly although there is a trend to start depending on AS- 971 PATH filters because they are much more manageable than the large 972 numbers of prefix filters that would need to be maintained. Many 973 ISPs also do not propagate interface IP addresses to further reduce 974 attack vectors on routers and connected customers. 976 2.5.8 Security Services 978 o User Authentication - Not applicable 980 o User Authorization - Not applicable 982 o Data Origin Authentication - By using MD5 authentication and/or 983 the TTL-hack a routing peer can be reasonably certain that traffic 984 originated from a valid peer. 986 o Access Control - Route filters, AS-PATH filters and prefix limits 987 are used to control access to specific parts of the network. 989 o Data Integrity - By using MD5 authentication a peer can be 990 reasonably certain that the data has not been modified in transit 991 but there is no mechanism to prove the validity of the routing 992 information itself. 994 o Data Confidentiality - Not implemented 996 o Auditing / Logging - TBD 998 o DoS Mitigation - Many DoS attacks are mitigated using a 999 combination of techniques including: MD5 authentication, the BTSH 1000 feature, filtering routing advertisements to bogons and filtering 1001 routing advertisements to one's own network. 1003 2.5.9 Additional Considerations 1005 So far the primary concern to secure the routing control plane has 1006 been to validate the sending peer and to ensure that the data in 1007 transit has not been altered. Although MD-5 routing protocol 1008 extensions have been implemented which can provide both services, 1009 they are not consistently deployed amongst ISPs. Two major 1010 deployment concerns have been implementation issues where both 1011 software bugs and the lack of graceful re-keying options have caused 1012 significant network down times. Also, some ISPs express concern that 1013 deploying MD5 authentication will itself be a worse DoS attack victim 1014 and prefer to use a combination of other risk mitigation mechanisms 1015 such as BTSH and route filters. 1017 Route filters are used to limit what routes are believed from a valid 1018 peer. Packet filters are used to limit which systems can appear as a 1019 valid peer. Due to the operational constraints of maintaining large 1020 prefix filter lists, many ISPs are starting to depend on BGP AS-PATh 1021 filters to/from their peers and upstream neighbors. 1023 IPsec is not deployed since the operational management aspects of 1024 ensuring interoperability and reliable configurations is too complex 1025 and time consuming to be operationally viable. There is also limited 1026 concern to the confidentiality of the routing information. The 1027 integrity and validity of the updates are of much greater concern. 1029 There is concern for manual or automated actions which introduce new 1030 routes and can affect the entire routing domain. 1032 2.6 Software Upgrades and Configuration Integrity / Validation 1034 Software upgrades and configuration changes are usually performed as 1035 part of either in-band or OOB management functions. However, there 1036 are additional considerations to be taken into account which are 1037 enumerated in this section. 1039 2.6.1 Threats / Attacks 1041 Attacks performed on system software and configurations can be both 1042 from passive or active sources. Passive attacks are possible if 1043 someone has the capability to intercept data between the network 1044 infrastructure device and the system which is downloading or 1045 uploading the software or configuration information. This can be 1046 accomplished if a single infrastructure device is somehow compromised 1047 and can act as a network sniffer or if it is possible to insert a new 1048 device which acts as a network sniffer. 1050 Active attacks are possible for both on-path and off-path scenarios. 1051 For on-path active attacks, the situation is the same as for a 1052 passive attack, where either a device has to already be compromised 1053 or a device can be inserted into the path. For off-path active 1054 attacks, the attacks are generally limited to message insertion or 1055 modification where the attacker may wish to load illegal software or 1056 configuration files to an infrastructure device. 1058 2.6.2 Confidentiality Violations 1060 Confidentiality violations can occur when a miscreant intercepts any 1061 of the software image or configuration information. The software 1062 image may give an indication of exploits which the device is 1063 vulnerable to while the configuration information can inadvertently 1064 lead attackers to identify critical infrastructure IP addresses and 1065 passwords. 1067 2.6.3 Offline Cryptographic Attacks 1069 If any cryptographic mechanism was used to provide for data integrity 1070 and confidentiality, an offline cryptographic attack could 1071 potentially compromise the data. The traffic would need to be 1072 captured either by eavesdropping on the network or by being able to 1073 divert traffic to a malicious user. 1075 2.6.4 Replay Attacks 1077 For a replay attack to be successful, the software image or 1078 configuration file would need to first be captured either on-path or 1079 diverted to an attacker to later be replayed to the intended 1080 recipient. 1082 2.6.5 Message Insertion/Deletion/Modification 1084 Software images and configuration files can be manipulated by someone 1085 in control of intermediate hosts. By forging an IP address and 1086 impersonating a valid host which can download software images or 1087 configuration files, invalid files can be downloaded to an 1088 infrastructure device. An invalid software image or configuration 1089 file can cause a device to hang and become inoperable. Spoofed 1090 configuration files can be hard to detect, especially when the only 1091 added command is to allow a miscreant access to that device by 1092 entering a filter allowing a specific host access and configuring a 1093 local username/password database entry for authentication to that 1094 device. 1096 2.6.6 Man-In-The-Middle 1098 A man-in-the-middle attack attacks the identity of a communicating 1099 peer rather than the data stream itself. The attacker intercepts 1100 traffic that is sent between the infrastructure device and the host 1101 used to upload/download the system image or configuration file. He/ 1102 she can then act on behalf of one or both of these systems. 1104 If an attacker obtained a copy of the software image being deployed, 1105 he could potentially exploit a known vulnerability and gain access to 1106 the system. From a captured configuration file, he could obtain 1107 confidential network topology information or even more damaging 1108 information if any of the passwords in the configuration file were 1109 not encrypted. 1111 2.6.7 Security Practices 1113 Images and configurations are stored on specific hosts which have 1114 limited access. All access and activity relating to these hosts are 1115 authenticated and logged via AAA services. When uploaded/downloading 1116 any system software or configuration files, either TFTP, FTP or SCP 1117 can be used. Where possible, SCP is used to secure the data transfer 1118 and FTP is generally never used. All TFTP and SCP access is 1119 username/password authenticated and in most environments scripts are 1120 used for maintaining a large number of routers. To ensure the 1121 integrity of the configurations, every hour the configuration files 1122 are polled and compared to the previously polled version to find 1123 discrepancies. In at least one environment these tools are 1124 Kerberized to take advantage of automated authentication (not 1125 confidentiality). 1127 Filters are used to limit access to uploading/downloading 1128 configuration files and system images to specific IP addresses and 1129 protocols. 1131 The software images perform CRC-checks but many ISPs expressed 1132 interest in having software image integrity validation based on the 1133 MD5 algorithm for enhanced security. The system binaries use the MD5 1134 algorithm to validate integrity. 1136 In all configuration files, the passwords are stored in an obfuscated 1137 format. This includes passwords for user authentication, MD5 shared 1138 secrets, AAA server shared secrets, NTP shared secrets, etc. For 1139 older software which may not support this functionality, 1140 configuration files are stored with passwords in readable format. [is 1141 this true? are configuration files then protected? if passwords in 1142 readable format, is the thought that an OOB management network with 1143 SCP will be enough protection? ] 1145 Automated security validation is performed on infrastructure devices 1146 using nmap and nessus to ensure valid configuration against many of 1147 the well-known attacks. 1149 2.6.8 Security Services 1151 o User Authentication - All users are authenticated before being 1152 able to download/upload any system images or configuration files. 1154 o User Authorization - All authenticated users are granted specific 1155 privileges to download or upload system images and/or 1156 configuration files. 1158 o Data Origin Authentication - TBD 1160 o Access Control - Filters are used to limit access to uploading/ 1161 downloading configuration files and system images to specific IP 1162 addresses and protocols. 1164 o Data Integrity - All systems use either a CRC-check or MD5 1165 authentication to ensure data integrity. 1167 o Data Confidentiality - If the SCP protocol is used then there is 1168 confidentiality of the downloaded/uploaded configuration files and 1169 system images. 1171 o Auditing / Logging - All access and activity relating to 1172 downloading/uploading system images and configuration files are 1173 logged via AAA services and filter exception rules. 1175 o DoS Mitigation - TBD 1177 2.6.9 Additional Considerations 1179 Where the MD5 algorithm is not used to perform data integrity 1180 checking of software images and configuration files, ISPs have 1181 expressed an interest in having this functionality. IPsec is 1182 considered too cumbersome and operationally difficult to use for data 1183 integrity and confidentiality. 1185 2.7 Logging Considerations 1187 Although logging is part of all the previous sections, it is 1188 important enough to be covered as a separate item. The main issues 1189 revolve around what gets logged, how long are logs kept and what 1190 mechanisms are used to secure the logged information while it is in 1191 transit and while it is stored. 1193 2.7.1 Threats / Attacks 1195 Attacks on the logged data can be both from passive or active 1196 sources. Passive attacks are possible if someone has the capability 1197 to intercept data between the recipient logging server and the device 1198 the logged data originated from. This can be accomplished if a 1199 single infrastructure device is somehow compromised and can act as a 1200 network sniffer or if it is possible to insert a new device which 1201 acts as a network sniffer. 1203 Active attacks are possible for both on-path and off-path scenarios. 1204 For on-path active attacks, the situation is the same as for a 1205 passive attack, where either a device has to already be compromised 1206 or a device can be inserted into the path. For off-path active 1207 attacks, the attacks are generally limited to message insertion or 1208 modification which can alter the logged data to keep any compromise 1209 from being detected or to destroy any evidence which could be used 1210 for criminal prosecution. 1212 2.7.1.1 Confidentiality Violations 1214 Confidentiality violations can occur when a miscreant intercepts any 1215 of the logging data which is in transit on the network. This could 1216 lead to privacy violations if some of the logged data has not been 1217 sanitized to disallow any data that could be a violation of privacy 1218 to be included in the logged data. 1220 2.7.1.2 Offline Cryptographic Attacks 1222 If any cryptographic mechanism was used to provide for data integrity 1223 and confidentiality, an offline cryptographic attack could 1224 potentially compromise the data. The traffic would need to be 1225 captured either by eavesdropping on the network or by being able to 1226 divert traffic to a malicious user. 1228 2.7.1.3 Replay Attacks 1230 For a replay attack to be successful, the logging data would need to 1231 first be captured either on-path or diverted to an attacker and later 1232 replayed to the recipient. [is reply handled by syslog protocol?] 1234 2.7.1.4 Message Insertion/Deletion/Modification 1236 Logging data could be injected, deleted or modified by someone in 1237 control of intermediate hosts. Logging data can also be injected by 1238 forging packets from either legitimate or illegitimate IP addresses. 1240 2.7.1.5 Man-In-The-Middle 1242 A man-in-the-middle attack attacks the identity of a communicating 1243 peer rather than the data stream itself. The attacker intercepts 1244 traffic that is sent between the infrastructure device and the 1245 logging server or traffic sent between the logging server and the 1246 database which is used to archive the logged data. Any unauthorized 1247 access to logging information could lead to knowledge of private and 1248 proprietary network topology information which could be used to 1249 compromise portions of the network. An additional concern is having 1250 access to logging information which could be deleted or modified so 1251 as to cover any traces of a security breach. 1253 2.7.2 Security Practices 1255 Logging is mostly performed on an exception auditing basis when it 1256 comes to filtering (i.e. traffic which is NOT allowed is logged). 1257 Typically the data logged will contain the source and destination IP 1258 addresses and layer 4 port numbers as well as a timestamp. The 1259 syslog protocol is used to transfer the logged data between the 1260 infrastructure device to the syslog server. Many ISPs use the OOB 1261 management network to transfer syslog data since there is virtually 1262 no security performed between the syslog server and the device. All 1263 ISPs have multiple syslog servers - some ISPs choose to use separate 1264 syslog servers for varying infrastructure devices (i.e. one syslog 1265 server for backbone routers, one syslog server for customer edge 1266 routers, etc.) 1268 The timestamp is derived from NTP which is generally configured as a 1269 flat hierarchy at stratum1 and stratum2 to have less configuration 1270 and less maintenance. Each router is configured with one stratum1 1271 peer both locally and remotely. 1273 In addition to logging filtering exceptions, the following is 1274 typically logged: Routing protocol state changes, all device access 1275 (regardless of authentication success or failure), all commands 1276 issued to a device, all configuration changes and all router events 1277 (boot-up/flaps). 1279 The main function of any of these log messages is to see what the 1280 device is doing as well as to try and ascertain what certain 1281 malicious attackers are trying to do. Some ISPs put in passive 1282 devices to see routing updates and withdrawals and not rely solely on 1283 the device for log files. This provides a backup mechanism to see 1284 what is going on in the network in the event that a device may 1285 'forget' to do syslog if the CPU is busy. 1287 The logs from the various syslog server devices are generally 1288 transferred into databases at a set interval which can be anywhere 1289 from every 10 minutes to every hour. One ISP uses Rsync to push the 1290 data into a database and then the information is sorted manually by 1291 someone SSH'ing to that database. 1293 2.7.3 Security Services 1295 o User Authentication - Not applicable 1297 o User Authorization - Not applicable 1299 o Data Origin Authentication - Not implemented 1301 o Access Control - Filtering on logging host and server IP address 1302 to ensure that syslog information only goes to specific syslog 1303 hosts. 1305 o Data Integrity - Not implemented 1306 o Data Confidentiality - Not implemented 1308 o Auditing / Logging - TBD 1310 o DoS Mitigation - TBD 1312 2.7.4 Additional Considerations 1314 There is no security with syslog and ISPs are fully cognizant of 1315 this. IPsec is considered too operationally expensive and cumbersome 1316 to deploy. Syslog-ng and stunnel are being looked at for providing 1317 better authenticated and integrity protected solutions. Mechanisms 1318 to prevent unauthorized personnel from tampering with logs is 1319 constrained to auditing who has access to the logging servers and 1320 files. 1322 ISPs expressed requirements for more than just UDP syslog. They 1323 would also like more granular and flexible facilities and priorities, 1324 i.e. specific logs to specific servers. 1326 2.8 Denial of Service Tracking / Tracing 1328 Denial of Service attacks are an ever increasing problem and require 1329 vast amounts of resources to combat effectively. Some large ISPs do 1330 not concern themselves with attack streams that are less than 1G in 1331 bandwidth - this is on the larger pipes where 1G is essentially less 1332 than 5% of offered load. This is largely due to the large amounts of 1333 DDoS traffic which continually requires investigation and mitigation. 1334 At last count the number of hosts making up large distributed DoS 1335 BOTnets exceeded 1 million hosts. 1337 New techniques are continually evolving to automate the process of 1338 detecting DoS sources and mitigating any adverse effects as quickly 1339 as possible. At this time, ISPs are using a variety of mitigation 1340 techniques including: sink hole routing, black-hole triggered 1341 routing, uRPF and rate limiting. Each of these techniques will be 1342 detailed below. 1344 2.8.1 Sink Hole Routing 1346 To be added. 1348 2.8.2 Black-Hole Triggered Routing 1350 To be added. 1352 2.8.3 Unicast Reverse Path Forwarding 1354 Unicast Reverse Path Forwarding (uRPF) is a mechanism for validating 1355 whether an incoming packet has a legitimate source address or not. 1356 It has two modes: strict mode and loose mode. In strict mode, uRPF 1357 checks whether the incoming packet has a source address that matches 1358 a prefix in the routing table, and whether the interface expects to 1359 receive a packet with this source address prefix. If the incoming 1360 packet fails the unicast RPF check, the packet is not accepted on the 1361 incoming interface. Loose mode uRPF is not as specific and the 1362 incoming packet is accepted if there is any route in the routing 1363 table for the source address. 1365 uRPF is not used on interfaces that are likely to have routing 1366 asymmetry, meaning multiple routes to the source of a packet. 1367 Usually for ISPs, uRPF is placed at the customer edge of a network. 1369 2.8.4 Rate Limiting 1371 Details of rate limiting 1373 3. Security Considerations 1375 This entire document deals with current security practices in large 1376 ISP environments. As a synopsis, a table is shown below which 1377 summarizes the operational functions which are to be protected and 1378 the security services which currently deployed security practices 1379 offer: [ Table to be added ] 1381 4. Normative References 1383 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1384 Requirement Levels", BCP 14, RFC 2119, March 1997. 1386 [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, 1387 May 2000. 1389 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1390 Text on Security Considerations", BCP 72, RFC 3552, 1391 July 2003. 1393 Author's Address 1395 Merike Kaeo 1396 Double Shot Security, Inc. 1397 520 Washington Blvd. #363 1398 Marina Del Rey, CA 90292 1399 U.S.A. 1401 Phone: +1 310 866 0165 1402 Email: merike@doubleshotsecurity.com 1404 Appendix A. Acknowledgments 1406 The editor gratefully acknowledges the contributions of: George 1407 Jones, who has been instrumental in providing guidance and direction 1408 for this document and the insighful comments from Ross Callon and the 1409 numerous ISP operators who supplied the information which is depicted 1410 in this document. 1412 Appendix B. Protocol Specific Attacks 1414 This section will enumerate many of the traditional protocol based 1415 attacks which have been observed over the years to cause malformed 1416 packets and/or exploit protocol deficiencies. 1418 o ARP Flooding 1420 o IP Stream Option 1422 o IP Address Spoofing 1424 o IP Source Route Option 1426 o IP Short header 1428 o IP Malformed Packet 1430 o Ip Bad Option 1432 o Ip Address Session Limit 1434 o Fragmenmts - too many 1436 o Fragments - large offset 1438 o Fragments - same offset 1440 o Fragments - reassembly with different offsets (TearDrop Attac) 1442 o Fragments - reassembly off by one IP header (Nestea Attack) 1444 o Fragment - flooding only initial fragment (Rose Attack) 1446 o IGMP oversized packet 1448 o ICMP Source Quench 1450 o ICMP Mask Request 1452 o ICMP Large Packet (> 1472) 1454 o ICMP Oversized packet (>65536) 1456 o ICMP Flood 1457 o ICMP Broadcast w/ Spoofed Source (Smurf Attack) 1459 o ICMP Error Packet Flood 1461 o ICMP Spoofed Unreachable 1463 o TCP Packet without Flag 1465 o TCP Oversized Packet 1467 o TCP FIN bit with no ACK bit 1469 o TCP Packet with URG/OOB flag (Nuke Attack) 1471 o SYN Fragments 1473 o SYN Flood 1475 o SYN with IP Spoofing (Land Attack) 1477 o SYN and FIN bits set 1479 o TCP port scan attack 1481 o UDP spoofed broadcast echo (Fraggle Attack) 1483 o UDP attack on diag ports (Pepsi Attack) 1485 Intellectual Property Statement 1487 The IETF takes no position regarding the validity or scope of any 1488 Intellectual Property Rights or other rights that might be claimed to 1489 pertain to the implementation or use of the technology described in 1490 this document or the extent to which any license under such rights 1491 might or might not be available; nor does it represent that it has 1492 made any independent effort to identify any such rights. Information 1493 on the procedures with respect to rights in RFC documents can be 1494 found in BCP 78 and BCP 79. 1496 Copies of IPR disclosures made to the IETF Secretariat and any 1497 assurances of licenses to be made available, or the result of an 1498 attempt made to obtain a general license or permission for the use of 1499 such proprietary rights by implementers or users of this 1500 specification can be obtained from the IETF on-line IPR repository at 1501 http://www.ietf.org/ipr. 1503 The IETF invites any interested party to bring to its attention any 1504 copyrights, patents or patent applications, or other proprietary 1505 rights that may cover technology that may be required to implement 1506 this standard. Please address the information to the IETF at 1507 ietf-ipr@ietf.org. 1509 Disclaimer of Validity 1511 This document and the information contained herein are provided on an 1512 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1513 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1514 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1515 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1516 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1517 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1519 Copyright Statement 1521 Copyright (C) The Internet Society (2005). This document is subject 1522 to the rights, licenses and restrictions contained in BCP 78, and 1523 except as set forth therein, the authors retain all their rights. 1525 Acknowledgment 1527 Funding for the RFC Editor function is currently provided by the 1528 Internet Society.