idnits 2.17.00 (12 Aug 2021) /tmp/idnits29118/draft-ietf-opsec-current-practices-00.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.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1298. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1275. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1282. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1288. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 341 has weird spacing: '...ransfer proto...' == Line 512 has weird spacing: '...ss. An indiv...' == Line 688 has weird spacing: '...ere are excep...' == Line 859 has weird spacing: '... should more ...' == Line 875 has weird spacing: '...in that the d...' == (1 more instance...) == 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 (February 10, 2005) is 6308 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) ** Obsolete normative reference: RFC 2828 (Obsoleted by RFC 4949) Summary: 7 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: August 14, 2005 February 10, 2005 6 Operational Security Current Practices 7 draft-ietf-opsec-current-practices-00 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 14, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document is a survey of the current practices used in today's 43 large ISP operational networks to secure layer 2 and layer 3 44 infrastructure devices. The information listed here is the result of 45 information gathered from people directly responsible for defining 46 and implementing secure infrastructures in Internet Service Provider 47 environments. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1 Threat Model . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.2 Operational Security Impact from Threats . . . . . . . . . 3 54 1.3 Document Layout . . . . . . . . . . . . . . . . . . . . . 5 55 1.4 Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 56 2. Protected Operational Functions . . . . . . . . . . . . . . . 7 57 2.1 Device Physical Access . . . . . . . . . . . . . . . . . . 7 58 2.2 Device In-Band Management . . . . . . . . . . . . . . . . 8 59 2.3 Device Out-of-Band Management . . . . . . . . . . . . . . 12 60 2.4 Data Path . . . . . . . . . . . . . . . . . . . . . . . . 16 61 2.5 Routing Control Plane . . . . . . . . . . . . . . . . . . 18 62 2.6 Software Upgrades and Configuration Integrity / 63 Validation . . . . . . . . . . . . . . . . . . . . . . . . 20 64 2.7 Logging Considerations . . . . . . . . . . . . . . . . . . 23 65 2.8 Filtering Considerations . . . . . . . . . . . . . . . . . 26 66 2.9 Denial of Service Tracking / Tracing . . . . . . . . . . . 26 67 3. Security Considerations . . . . . . . . . . . . . . . . . . . 28 68 4. Normative References . . . . . . . . . . . . . . . . . . . . . 28 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 28 70 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 71 Intellectual Property and Copyright Statements . . . . . . . . 30 73 1. Introduction 75 Security practices are well understood by the network operators who 76 have for many years gone through the growing pains of securing their 77 network infrastructures. However, there does not exist a written 78 document that enumerates these security practices. Network attacks 79 are continually increasing and although it is not necessarily the 80 role of an ISP to act as the Internet police, each ISP has to ensure 81 that certain security practices are followed to ensure that their 82 network is operationally available for their customers. This 83 document is the result of a survey conducted to find out what current 84 security practices are being deployed to secure network 85 infrastructures. 87 1.1 Threat Model 89 The scope for this survey is restricted to security practices that 90 mitigate exposure to risks with the potential to adversely impact 91 network availability and reliability. Securing the actual data 92 traffic is outside the scope of the conducted survey. This document 93 focuses solely on documenting currently deployed security mechanisms 94 for layer 2 and layer 3 network infrastructure devices. 96 1.2 Operational Security Impact from Threats 98 A threat is a potential for a security violation, which exists when 99 there is a circumstance, capability, action, or event that could 100 breach security and cause harm [RFC2828]. Every operational network 101 is subject to a multitude of threat actions, or attacks, i.e. an 102 assault on system security that derives from an intelligent act that 103 is a deliberate attempt to evade security services and violate the 104 security policy of a system [RFC2828]. These attacks can be sourced 105 in a variety of ways: 107 Active vs passive attacks 108 An active attack involves writing data to the network. It is 109 common practice in active attacks to disguise one's address and 110 conceal the identity of the traffic sender. A passive attack 111 involves only reading information off the network. This is 112 possible if the attacker has control of a host in the 113 communications path between two victim machines or has compromised 114 the routing infrastructure to specifically arrange that traffic 115 pass through a compromised machine. In general, the goal of a 116 passive attack is to obtain information that the sender and 117 receiver would prefer to remain private. [RFC3552] 119 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 gateways. Such gateways are naturally able to read, modify, 123 or 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 133 An "insider attack" is one which is initiated from inside a given 134 security perimeter, by an entity that is authorized to access 135 system resources but uses them in a way not approved by those who 136 granted the authorization. An "outside attack" is initiated from 137 outside the perimeter, by an unauthorized or illegitimate user of 138 the system. 140 Deliberate attacks vs unintentional events 141 A deliberate attack is one where a miscreant intentionally 142 performs an assault on system security. However, there are also 143 instances where unintentional events cause the same harm yet are 144 performed without malice in mind. Configuration errors and 145 software bugs can be as devastating to network availability as any 146 deliberate attack on the network infrastructure. 148 The attack source can be a combination of any of the above, all of 149 which need to be considered when trying to ascertain what impact any 150 attack can have on the availability and reliability of the network. 151 It is nearly impossible to stop insider attacks or unintentional 152 events. However, if appropriate monitoring mechanisms are in place, 153 these attacks can be as easily detected and mitigated as with any 154 other attack source. Any of the specific attacks discussed further 155 in this document will elaborate on attacks which are sourced by an 156 "outsider" and are deliberate attacks. Some further elaboration will 157 be given to the feasibility of passive vs active and on-path vs 158 off-path attacks to show the motivation behind deploying certain 159 security features. 161 The threat consequences are the security violations which results 162 from a threat action, i.e. an attack. These are typically 163 classified as follows: 165 (Unauthorized) Disclosure 166 A circumstance or event whereby an entity gains access to data for 167 which the entity is not authorized. 169 Deception 170 A circumstance or event that may result in an authorized entity 171 receiving false data and believing it to be true. 173 Disruption 174 A circumstance or event that interrupts or prevents the correct 175 operation of system services and functions. A broad variety of 176 attacks, collectively called denial of service attacks, threaten 177 the availability of systems and bandwidth to legitimate users. 178 Many such attacks are designed to consume machine resources, 179 making it difficult or impossible to serve legitimate users. 180 Other attacks cause the target machine to crash, completely 181 denying service to users. 183 Usurpation 184 A circumstance or event that results in control of system services 185 or functions by an unauthorized entity. Most network 186 infrastructure systems are only intended to be completely 187 accessible to certain authorized individuals. Should an 188 unauthorized person gain access to critical layer 2 / layer 3 189 infrastructure devices or services, they could cause great harm to 190 the reliability and availability of the network. 192 A complete description of threat actions that can cause these threat 193 consequences can be found in [RFC2828]. Typically, a number of 194 different network attacks are used in combination to cause one or 195 more of the above mentioned threat consequences. An example would be 196 a malicious user who has the capability to eavesdrop on traffic. 197 First, he may listen in on traffic for a while to do some 198 reconnaissance work and ascertain which IP addresses belonged to 199 specific devices such as routers. Were this miscreant to obtain 200 information such as a router password sent in cleartext, he can then 201 proceed to compromise the actual router. From there, the miscreant 202 can launch various active attacks such as sending bogus routing 203 updates to redirect traffic or capture additional traffic to 204 compromise other network devices. 206 1.3 Document Layout 208 This document is a survey of current operational practices that 209 mitigate the risk of being susceptible to any threat actions. As 210 such, the main focus is on the currently deployed security practices 211 used to detect and/or mitigate attacks. The top-level categories in 212 this document are based on operational functions for ISPs and 213 generally relate to what is to be protected. This is followed by a 214 description of which attacks are possible and the security practices 215 currently deployed which will provide the necessary security services 216 to help mitigate these attacks. These security services are 217 classified as: 219 o User Authentication 220 o User Authorization 221 o Data Origin Authentication 222 o Access Control 223 o Data Integrity 224 o Data Confidentiality 225 o Auditing / Logging 226 o DoS Mitigation 228 In many instances, a specific protocol currently deployed will offer 229 a combination of these services. For example, AAA can offer user 230 authentication, user authorization and audit / logging services while 231 SSH can provide data origin authentication, data integrity and data 232 confidentiality. The services offered are more important than the 233 actual protocol used. Each section ends with an additional 234 considerations section which explains why specific protocols may or 235 may not be used and also gives some information regarding 236 capabilities which are not possible today due to bugs or lack of ease 237 of use. 239 1.4 Definitions 240 RFC 2119 Keywords 241 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 242 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 243 in this document are to be interpreted as described in [RFC2119]. 244 The use of the RFC 2119 keywords is an attempt, by the editor, to 245 assign the correct requirement levels ("MUST", "SHOULD", 246 "MAY"...). It must be noted that different organizations, 247 operational environments, policies and legal environments will 248 generate different requirement levels. 250 2. Protected Operational Functions 252 2.1 Device Physical Access 254 Device physical access pertains to protecting the physical location 255 of the layer 2 or layer 3 network infrastructure device. Although it 256 is important to have contingency plans for natural disasters such as 257 earthquakes and floods which can cause damage to networking devices, 258 this is out-of-scope for this document. Here we concern ourselves 259 with protecting access to the physical location and how a device can 260 be further protected from unauthorized access if the physical 261 location has been compromised, i.e protecting the console access. 263 2.1.1 Threats / Attacks 265 If any intruder gets physical access to a layer 2 or layer 3 device, 266 the entire network infrastructure can be under the control of the 267 intruder. At a minimum, the intruder can take the compromised device 268 out-of-service, causing network disruption, the extent of which 269 depends on the network topology. A worse scenario is where the 270 intruder can use this device to crack the console password and have 271 complete control of the device, perhaps without anyone detecting such 272 a compromise, or to attach another network device onto a port and 273 siphon off data with which the intruder can ascertain the network 274 topology and take control of the entire network. 276 The threat of gaining physical access can be realized in a variety of 277 ways even if critical devices are under high-security. There still 278 occur cases where attackers have impersonated maintenance workers to 279 gain physical access to critical devices that have caused major 280 outages and privacy compromises. Insider attacks from authorized 281 personnel also pose a real threat and must be adequately recognized 282 and dealt with. 284 2.1.2 Security Practices 286 For physical device security, equipment is kept in highly restrictive 287 environments. Only authorized users with card key badges have access 288 to any of the physical locations that contain critical network 289 infrastructure devices. These card-key systems keep track of who 290 accessed which location and at what time. 292 All console access is always password protected and the login time is 293 set to time out after a specified amount of inactivity - typically 294 between 3-10 minutes. Individual users are authentication to get 295 basic access. For privileged (i.e. enable) access, a second 296 authentication step needs to be completed. Typically all console 297 access is provided via an out-of-band (OOB) management infrastructure 298 which is discussed in the section on OOB management. 300 2.1.3 Security Services 302 The following security services are offered through the use of the 303 practices described in the previous section: 305 o User Authentication - All individuals who have access to the 306 physical facility are authenticated. Console access is 307 authenticated. 308 o User Authorization - An authenticated individual has implicit 309 authorization to perform commands on the device. Console access 310 is usually granted via at least two privilege levels: 311 authorization for performing a basic set of commands vs 312 authorization for performing all commands. 313 o Data Origin Authentication - Not applicable 314 o Access Control - Not applicable 315 o Data Integrity - Not applicable 316 o Data Confidentiality - Not applicable 317 o Auditing / Logging - All access to the physical locations of the 318 infrastructure equipment is logged via electronic card-key 319 systems. All console access is logged (refer to the OOB 320 management section for more details) 321 o DoS Mitigation - Not applicable 323 2.1.4 Additional Considerations 325 Physical security is relevant to operational security practices as 326 described in this document mostly from a console access perspective. 327 Most ISPs provide console access via an OOB management infrastructure 328 which is discussed in the OOB management section of this document. 330 2.2 Device In-Band Management 332 In-band management is generally considered to be device access where 333 the control traffic takes the same data path as the data which 334 traverses the network. In many environments, device management for 335 layer 2 and layer 3 infrastructure devices is deployed as part of an 336 out-of-band management infrastructure although there are some 337 instances where it is deployed in-band as well. Presently, the 338 mechanisms used for in-band management are via virtual terminal 339 access (i.e. Telnet or SSH), SNMP, or HTTP. In all large ISP 340 environments, HTTP management is never used and is explicitly 341 disabled. Note that file transfer protocols (TFTP, FTP, SCP) will 342 be covered in the 'Software Upgrades and Configuration 343 Integrity/Validation' section. 345 2.2.1 Threats / Attacks 347 For in-band device management, passive attacks are possible if 348 someone has the capability to intercept data between the management 349 device and the managed device. The threat is possible if a single 350 infrastructure device is somehow compromised and can act as a network 351 sniffer or if it is possible to insert a new device which acts as a 352 network sniffer. 354 Active attacks are possible for both on-path and off-path scenarios. 355 For on-path active attacks, the situation is the same as for a 356 passive attack, where either a device has to already be compromised 357 or a device can be inserted into the path. For off-path active 358 attacks, the attack is generally limited to message insertion or 359 modification. 361 2.2.1.1 Confidentiality Violations 363 Confidentiality violations can occur when a miscreant intercepts 364 confidential data that has been sent in cleartext. This includes 365 interception of usernames and passwords with which an intruder can 366 obtain unauthorized access to network devices. It can also include 367 other information such as logging or configuration information if an 368 administrator is remotely viewing local logfiles or configuration 369 information. 371 2.2.1.2 Offline Cryptographic Attacks 373 If username/password information was encrypted but the cryptographic 374 mechanism used made it easy to capture data and break the encryption 375 key, the device management traffic could be compromised. The traffic 376 would need to be captured either by eavesdropping on the network or 377 by being able to divert traffic to a malicious user. 379 2.2.1.3 Replay Attacks 381 For a replay attack to be successful, in-band management traffic 382 would need to first be captured either on-path or diverted to an 383 attacker to later be replayed to the intended recipient. 385 2.2.1.4 Message Insertion/Deletion/Modification 387 Data can be manipulated by someone in control of intermediary hosts. 388 Forging data is also possible with IP spoofing, where a remote host 389 sends out packets which appear to come from another, trusted host. 391 2.2.1.5 Man-In-The-Middle 393 A man-in-the-middle attack attacks the identity of a communicating 394 peer rather than the data stream itself. The attacker intercepts 395 traffic that is sent from an in-band management system to the 396 networking infrastructure device and traffic that is sent from the 397 network infrastructure device to the in-band management system. 399 2.2.2 Security Practices 401 All in-band management access to layer 2 and layer 3 devices is 402 authenticated. The user authentication and authorization is 403 typically controlled by a AAA server (i.e. RADIUS and/or TACACS+). 404 Credentials used to determine the identity of the user vary from 405 static username/password to one-time username/password scheme such as 406 Secure-ID. Static username/passwords are expired after a specified 407 period of time, usually 30 days. Every authenticated entity via AAA 408 is an individual user for greater granularity of control. In some 409 deployments, The AAA servers used for in-band management 410 authentication/authorization/accounting are on separate out-of-band 411 networks to provide a demarcation for any other authentication 412 functions. 414 For backup purposes, there is often a single local database entry for 415 authentication which is known to a very limited set of key personnel. 416 It is usually the highest privilege level username/password 417 combination, which in most cases is the same across all devices. 418 This local device password is routinely regenerated once every 2-3 419 months and is also regenerated immediately after an employee who had 420 access to that password leaves the company or is no longer authorized 421 to have knowledge of that password. 423 Each individual user in the AAA database is configured with specific 424 authorization capability. Specific commands are either individually 425 denied or permitted depending on the capability of the device to be 426 accessed. Multiple privilege levels are deployed. Most individuals 427 are authorized with basic authorization to perform a minimal set of 428 commands while a subset of individuals are authorized to perform more 429 privileged commands. 431 SSH is always used for virtual terminal access to provide for an 432 encrypted communication channel. There are exceptions due to 433 equipment limitations which are described in the additional 434 considerations section. 436 If SNMP is used for in-band management, it is for read queries only 437 and restricted to specific hosts. The community strings are 438 carefully chosen to be difficult to crack and there are procedures in 439 place to change these community strings between 30-90 days. If 440 systems support two SNMP strings, a second new string is set and then 441 migrate over from the 1st to the 2nd. Most large ISPs have multiple 442 SNMP systems accessing their routers so it takes more then one 443 maintenance period to get all the strings fixed in all the right 444 systems. SNMP RW is not used and disabled by configuration. 446 Access control is strictly enforced for infrastructure devices by 447 using stringent filtering rules. A limited set of IP addresses are 448 allowed to initiate connections to the infrastructure devices and are 449 specific to the services which they are to limited to (i.e. SSH and 450 SNMP). 452 All in-band device management access is audited. The AAA server 453 keeps track of the authenticated entity as well as all the commands 454 that were carried out on a specific device. Additionally, the device 455 itself logs any access control violations (i.e. if an SSH request 456 comes in from an IP address which is not explicitly permitted, that 457 event is logged so that the offending IP address can be tracked down 458 and investigations made as to why it was trying to access a 459 particular infrastructure device) 461 2.2.3 Security Services 463 The following security services are offered through the use of the 464 practices described in the previous section: 466 o User Authentication - All individuals are authenticated via AAA 467 services. 468 o User Authorization - All individuals are authorized via AAA 469 services to perform specific operations once successfully 470 authenticated. 471 o Data Origin Authentication - Management traffic is strictly 472 filtered to allow only specific IP addresses to have access to the 473 infrastructure devices. This does not alleviate risk from spoofed 474 traffic. Using SSH for device access ensures that noone can spoof 475 the traffic during the SSH session. 476 o Access Control - In-band management traffic is filtered to allow 477 only specific IP addresses to have access to the infrastructure 478 devices. 479 o Data Integrity - Using SSH provides data integrity and ensures 480 that noone has altered the management data in transit. 481 o Data Confidentiality - Using SSH provides data confidentiality. 482 o Auditing / Logging - Using AAA provides an audit trail for who 483 accessed which device and which operations were performed. 484 o DoS Mitigation - Filtering to allow only specific IP addresses to 485 have access to the infrastructure devices. This does not defend 486 against spoofed traffic which may be used to source a DoS attack. 488 Often OOB management is used to lower that risk. 490 2.2.4 Additional Considerations 492 IPsec is considered too difficult to implement and the common 493 protocol to provide for confidential in-band management access is 494 SSH. There are exceptions for using SSH due to equipment limitations 495 since SSH may not be supported on legacy equipment. Also, in the 496 case where the SSH key is stored on a route processor card, a 497 re-keying of SSH would be required whenever the route processor card 498 needs to be swapped. Some providers feel that this operational 499 impact exceeds the security necessary and instead use Telnet from 500 trusted inside hosts (called 'jumphosts') to manage those devices. 501 An individual would first SSH to the jumphost and then Telnet from 502 the jumphost to the actual infrastructure device. All authentication 503 and authorization is still carried out using AAA servers. In 504 instances where Telnet access is used, the logs on the AAA servers 505 are more verbose and more attention is paid to them to detect any 506 abnormal behavior. Note that Telent is NEVER allowed to an 507 infrastructure device except from specific jumphosts whose IP 508 addresses are filtered at the infrastructure device. 510 With thousands of devices to manage, some ISPs have created automated 511 mechanisms to authenticate to devices. Kerberos is used to automate 512 the authentication process. An individual would first log in to a 513 Kerberized UNIX server using SSH and generate a Kerberos 'ticket'. 514 This 'ticket' is generally set to have a lifespan of 10 hours and is 515 used to automatically authenticate the individual to the 516 infrastructure devices. 518 In instances where SNMP is used, some legacy devices only support 519 SNMPv1 which then requires the provider to mandate its use across all 520 infrastructure devices for operational simplicity. SNMPv2 is 521 primarily deployed since it is easier to set up than v3. 523 2.3 Device Out-of-Band Management 525 Out-of-band management is generally considered to be device access 526 where the control traffic takes a separate path as the data which 527 traverses the network. Console access is always architected via an 528 OOB network. SNMP management is also usually carried out via that 529 same OOB network infrastructure. 531 2.3.1 Threats / Attacks 533 For OOB device management, passive attacks are possible if someone 534 has the capability to intercept data between the management device 535 and the managed device. The threat is possible if a single 536 infrastructure device is somehow compromised and can act as a network 537 sniffer or if it is possible to insert a new device which acts as a 538 network sniffer. 540 Active attacks are possible for both on-path and off-path scenarios. 541 For on-path active attacks, the situation is the same as for a 542 passive attack, where either a device has to already be compromised 543 or a device can be inserted into the path. For off-path active 544 attacks, the attack is generally limited to message insertion or 545 modification. 547 2.3.1.1 Confidentiality Violations 549 Confidentiality violations can occur when a miscreant intercepts any 550 of the OOB management data that has been sent in cleartext. This 551 includes interception of usernames and passwords with which an 552 intruder can obtain unauthorized access to network devices. It can 553 also include other information such as logging or configuration 554 information if an administrator is remotely viewing local logfiles or 555 configuration information. 557 2.3.1.2 Offline Cryptographic Attacks 559 If username/password information was encrypted but the cryptographic 560 mechanism used made it easy to capture data and break the encryption 561 key, the OOB management traffic could be compromised. The traffic 562 would need to be captured either by eavesdropping on the network or 563 by being able to divert traffic to a malicious user. 565 2.3.1.3 Replay Attacks 567 For a replay attack to be successful, the OOB management traffic 568 would need to first be captured either on-path or diverted to an 569 attacker to later be replayed to the intended recipient. 571 2.3.1.4 Message Insertion/Deletion/Modification 573 Data can be manipulated by someone in control of intermediary hosts. 574 Forging data is also possible with IP spoofing, where a remote host 575 sends out packets which appear to come from another, trusted host. 577 2.3.1.5 Man-In-The-Middle 579 A man-in-the-middle attack attacks the identity of a communicating 580 peer rather than the data stream itself. The attacker intercepts 581 traffic that is sent from an OOB management system to the networking 582 infrastructure device and traffic that is sent from the network 583 infrastructure device to the OOB management system. 585 2.3.2 Security Practices 587 OOB is done via a terminal server at each location. SSH access is 588 used to get to the terminal server from where sessions to the devices 589 are initiated. Dial-in access is deployed as a backup if the network 590 is not available. 592 All OOB management access to layer 2 and layer 3 devices is 593 authenticated. The user authentication and authorization is 594 typically controlled by a AAA server (i.e. RADIUS and/or TACACS+). 595 Credentials used to determine the identity of the user vary from 596 static username/password to one-time username/password scheme such as 597 Secure-ID. Static username/passwords are expired after a specified 598 period of time, usually 30 days. Every authenticated entity via AAA 599 is an individual user for greater granularity of control. Note that 600 often the AAA server used for OOB management authentication is a 601 separate physical device from the AAA server used for in-band 602 management user authentication. 604 For backup purposes, there is often a single local database entry for 605 authentication which is known to a very limited set of key personnel. 606 It is usually the highest privilege level username/password 607 combination, which in most cases is the same across all devices. 608 This local device password is routinely regenerated once every 2-3 609 months and is also regenerated immediately after an employee who had 610 access to that password leaves the company or is no longer authorized 611 to have knowledge of that password. 613 Each individual user in the AAA database is configured with specific 614 authorization capability. Specific commands are either individually 615 denied or permitted depending on the capability of the device to be 616 accessed. Multiple privilege levels are deployed. Most individuals 617 are authorized with basic authorization to perform a minimal set of 618 commands while a subset of individuals are authorized to perform more 619 privileged commands. 621 Some OOB management functions are performed using command line 622 interface (CLI) scripting. In these scenarios, a dedicated user is 623 used for the identity in scripts that perform CLI scripting. Once 624 authenticated, these scripts control which commands are legitimate 625 depending on authorization rights of the authenticated individual. 627 SSH is always used for virtual terminal access to provide for an 628 encrypted communication channel. There are exceptions due to 629 equipment limitations which are described in the additional 630 considerations section. 632 If SNMP is used for OOB management, it is for read queries only and 633 restricted to specific hosts. The community strings are carefully 634 chosen to be difficult to crack and there are procedures in place to 635 change these community strings between 30-90 days. If systems 636 support two SNMP strings, a second new string is set and then migrate 637 over from the 1st to the 2nd. Most large ISPs have multiple SNMP 638 systems accessing their routers so it takes more then one maintenance 639 period to get all the strings fixed in all the right systems. SNMP 640 RW is not used and disabled by configuration. 642 Access control is strictly enforced for infrastructure devices by 643 using stringent filtering rules. A limited set of IP addresses are 644 allowed to initiate connections to the infrastructure devices and are 645 specific to the services which they are to limited to (i.e. SSH and 646 SNMP). 648 All OOB device management access is audited. The AAA server keeps 649 track of the authenticated entity as well as all the commands that 650 were carried out on a specific device. Additionally, the device 651 itself logs any access control violations (i.e. if an SSH request 652 comes in from an IP address which is not explicitly permitted, that 653 event is logged so that the offending IP address can be tracked down 654 and investigations made as to why it was trying to access a 655 particular infrastructure device) 657 2.3.3 Security Services 659 o User Authentication - All individuals are authenticated via AAA 660 services. 661 o User Authorization - All individuals are authorized via AAA 662 services to perform specific operations once successfully 663 authenticated. 664 o Data Origin Authentication - Management traffic is strictly 665 filtered to allow only specific IP addresses to have access to the 666 infrastructure devices. This does not alleviate risk from spoofed 667 traffic. Using SSH for device access ensures that noone can spoof 668 the traffic during the SSH session. 669 o Access Control - In-band management traffic is filtered to allow 670 only specific IP addresses to have access to the infrastructure 671 devices. 672 o Data Integrity - Using SSH provides data integrity and ensures 673 that noone has altered the management data in transit. 674 o Data Confidentiality - Using SSH provides data confidentiality. 675 o Auditing / Logging - Using AAA provides an audit trail for who 676 accessed which device and which operations were performed. 677 o DoS Mitigation - Filtering to allow only specific IP addresses to 678 have access to the infrastructure devices. This does not defend 679 against spoofed traffic which may be used to source a DoS attack. 681 The risk is lowered by using a separate network for management 682 purposes. 684 2.3.4 Additional Considerations 686 IPsec is considered too difficult to implement and the common 687 protocol to provide for confidential OOB management access is SSH. 688 There are exceptions for using SSH due to equipment limitations 689 since SSH may not be supported on legacy equipment. Also, in the 690 case where the SSH key is stored on a route processor card, a 691 re-keying of SSH would be required whenever the route processor card 692 needs to be swapped. Some providers feel that this operational 693 impact exceeds the security necessary and instead use Telnet from 694 trusted inside hosts (called 'jumphosts') to manage those device. An 695 individual would first SSH to the jumphost and then Telnet from the 696 jumphost to the terminal server before logging in to the device 697 console. All authentication and authorization is still carried out 698 using AAA servers. In instances where Telnet access is used, the 699 logs on the AAA servers are more verbose and more attention is paid 700 to them to detect any abnormal behavior. Note that Telent is NEVER 701 allowed to a console server or infrastructure device except from 702 specific jumphosts whose IP addresses are filtered at the console 703 server and/or infrastructure device. 705 In instances where SNMP is used, some legacy devices only support 706 SNMPv1 which then requires the provider to mandate its use across all 707 infrastructure devices for operational simplicity. SNMPv2 is 708 primarily deployed since it is easier to set up than v3. 710 2.4 Data Path 712 This section refers to how traffic is handled which traverses the 713 network infrastructure device. The primary goal of ISPs is to 714 forward customer traffic. However, due to the large amount of attack 715 traffic that can cause DoS attacks and render the network 716 unavailable, specific measures are sometimes deployed to ensure the 717 availability to forward legitimate customer traffic. 719 2.4.1 Threats / Attacks 721 Any data traffic can potentially be attack traffic and the challenge 722 is to detect and potentially stop forwarding any of the malicious 723 traffic. 725 2.4.2 Security Practices 727 Filtering and rate limiting are the primary mechanism to provide risk 728 mitigation of malicious traffic rendering the ISP services 729 unavailable. However, filtering and rate limiting of data path 730 traffic is deployed in a variety of ways depending on how automated 731 the process is and the reliability of existing deployed hardware. 733 The ISPs which do not have performance issues with their equipment 734 follow BCP38 guidelines. Null routes and black-hole filtering are 735 used to deter any detected malicious traffic streams. Most ISPs 736 consider layer 4 filtering useful but it is only implemented if there 737 is no performance limitations on the devices. Netflow is used for 738 tracking traffic flows but there is some concern whether sampling is 739 good enough to detect malicious behavior. 741 Unicast RPF is not consistently implemented. Some ISPs are in 742 process of doing so while other ISPs think that the perceived benefit 743 of knowing that spoofed traffic comes from legitimate addresses are 744 not worth the operational complexity. Some providers have a policy 745 of implementing uRPF at link speeds of DS3 and below. 747 2.4.3 Security Services 749 o User Authentication - Not applicable 750 o User Authorization - Not applicable 751 o Data Origin Authentication - When IP address filtering per BCP38 752 and uRPF are deployed at network edges it can ensure that any 753 spoofed traffic comes from at least a legitimate IP address and 754 can be tracked. 755 o Access Control - IP address filtering and layer 4 filtering is 756 used to deny forbidden protocols and limit traffic destined for 757 infrastructure device itself. 758 o Data Integrity - Not applicable 759 o Data Confidentiality - Not applicable 760 o Auditing / Logging - Filtering exceptions are logged for potential 761 attack traffic. 762 o DoS Mitigation - Black-hole triggered filtering and rate-limiting 763 are used to limit the risk of DoS attacks. 765 2.4.4 Additional Considerations 767 For layer 2 devices, MAC address filtering and authentication is not 768 used. This is due to the problems it can cause when troubleshooting 769 networking issues. Port security becomes unmanageable at a large 770 scale where 1000s of switches are deployed. 772 Rate limiting is used by some ISPs although other ISPs believe it is 773 not really useful since attackers are not well behaved and it doesn't 774 provide any operational benefit over the complexity. Rate limiting 775 can be improved by (need info) 776 Performance issues cause some ISPs to not implement BCP38 guidelines 777 for ingress filtering. One such example is at edge boxes where you 778 have up to 1000 T1's connecting into a router with an OC-12 uplink. 779 Some ISP's experience a large performance impact with filtering which 780 is unacceptable for passing customer traffic through. Where 781 performance is not an issue, the ISPs make a tradeoff between 782 management versus risk. 784 2.5 Routing Control Plane 786 The routing control plane deals with all the traffic which is part of 787 establishing and maintaining routing protocol information. 789 2.5.1 Threats / Attacks 791 Attacks on the routing control plane can be both from passive or 792 active sources. Passive attacks are possible if someone has the 793 capability to intercept data between the communicating routing peers. 794 This can be accomplished if a single routing peer is somehow 795 compromised and can act as a network sniffer or if it is possible to 796 insert a new device which acts as a network sniffer. 798 Active attacks are possible for both on-path and off-path scenarios. 799 For on-path active attacks, the situation is the same as for a 800 passive attack, where either a device has to already be compromised 801 or a device can be inserted into the path. For off-path active 802 attacks, the attacks are generally limited to message insertion or 803 modification which can divert traffic to illegitimate destinations 804 and cause traffic to never reach its intended destination. 806 2.5.2 Confidentiality Violations 808 Confidentiality violations can occur when a miscreant intercepts any 809 of the routing update traffic. [is this an issue?] 811 2.5.3 Offline Cryptographic Attacks 813 If any cryptographic mechanism was used to provide for data integrity 814 and confidentiality, an offline cryptographic attack could 815 potentially compromise the data. The traffic would need to be 816 captured either by eavesdropping on the network or by being able to 817 divert traffic to a malicious user. Note that by using 818 cryptographically protected routing information, the latter would 819 require the cryptographic key to already be compromised anyway so 820 this attack is only feasible if a device was able eavesdrop and 821 capture the cryptographically protected routing information. 823 2.5.4 Replay Attacks 825 For a replay attack to be successful, the routing control plane 826 traffic would need to first be captured either on-path or diverted to 827 an attacker to later be replayed to the intended recipient. 829 2.5.5 Message Insertion/Deletion/Modification 831 Routing control plane traffic can be manipulated by someone in 832 control of intermediate hosts. In addition, traffic can be injected 833 by forging IP addresses, where a remote router sends out packets 834 which appear to come from another, trusted router. If enough traffic 835 is injected to be processed by limited memory routers it can cause a 836 DoS attack. 838 2.5.6 Man-In-The-Middle 840 A man-in-the-middle attack attacks the identity of a communicating 841 peer rather than the data stream itself. The attacker intercepts 842 traffic that is sent from one routing peer to the other and 843 communicates on behalf of one of the peers. 845 2.5.7 Security Practices 847 Securing the routing control plane takes many features which are 848 generally deployed as a system. MD5 authentication is used by some 849 ISPs to validate the sending peer and to ensure that the data in 850 transit has not been altered. Some ISPs only do MD-5 authentication 851 at customer's request. Many ISPs also deploy sanity checks to ensure 852 with some certainty that the received routing update has been 853 authorized to be sent by the sending party. In the case of BGP 854 routing, this is accomplished through the use of routing registries 855 and prefix limits. Additionally, route filters and the ttl-hack 856 (politically correct name? BTSH?) ensure with reasonable probability 857 that the routing update came from a valid peer. 859 [editor's note: should more info be included on secure BGP policy? 860 Rejecting advertisements for your own backbone, advertisements to 861 bogons, route damping, rejecting selected attributes and communities, 862 etc. (Will need more specific input from provider deployment)] 864 2.5.8 Security Services 866 o User Authentication - Not applicable 867 o User Authorization - Not applicable 868 o Data Origin Authentication - By using MD5 authentication and/or 869 the TTL-hack a routing peer can be reasonably certain that traffic 870 originated from a valid peer. 872 o Access Control - Route filtering and prefix limits are used to 873 control access to specific parts of the network. 874 o Data Integrity - By using MD5 authentication a peer can be 875 reasonably certain that the data has not been modified in transit 876 but there is no mechanism to prove the validity of the routing 877 information itself. 878 o Data Confidentiality - Not implemented 879 o Auditing / Logging - TBD 880 o DoS Mitigation - Many DoS attacks are mitigated using a 881 combination of techniques including: MD5 authentication, the 882 ttl-hack, filtering advertisements to bogons and filtering 883 advertisements to one's own network. 885 2.5.9 Additional Considerations 887 So far the primary concern to secure the routing control plane has 888 been to validate the sending peer and to ensure that the data in 889 transit has not been altered. Although MD-5 routing protocol 890 extensions have been implemented which can provide both services, 891 they are not consistently deployed amongst ISPs. Two major 892 deployment concerns have been implementation issues where both 893 software bugs and the lack of graceful re-keying options have caused 894 significant network down times. Also, some ISPs express concern that 895 deploying MD5 authentication will itself be a worse DoS attack victim 896 and prefer to use a combination of other risk mitigation mechanisms 897 (ttl-hack and route filters). 899 IPsec is not deployed since the operational management aspects of 900 ensuring interoperability and reliable configurations is too complex 901 and time consuming to be operationally viable. There is also limited 902 concern to the confidentiality of the routing information. The 903 integrity and validity of the updates are of much greater concern. 905 There is concern for manual or automated actions which introduce new 906 routes and can affect the entire routing domain. 908 2.6 Software Upgrades and Configuration Integrity / Validation 910 Software upgrades and configuration changes are usually performed as 911 part of either in-band or OOB management functions. However, there 912 are additional considerations to be taken into account which are 913 enumerated in this section. 915 2.6.1 Threats / Attacks 917 Attacks performed on system software and configurations can be both 918 from passive or active sources. Passive attacks are possible if 919 someone has the capability to intercept data between the network 920 infrastructure device and the system which is downloading or 921 uploading the software or configuration information. This can be 922 accomplished if a single infrastructure device is somehow compromised 923 and can act as a network sniffer or if it is possible to insert a new 924 device which acts as a network sniffer. 926 Active attacks are possible for both on-path and off-path scenarios. 927 For on-path active attacks, the situation is the same as for a 928 passive attack, where either a device has to already be compromised 929 or a device can be inserted into the path. For off-path active 930 attacks, the attacks are generally limited to message insertion or 931 modification where the attacker may wish to load illegal software or 932 configuration files to an infrastructure device. 934 2.6.2 Confidentiality Violations 936 Confidentiality violations can occur when a miscreant intercepts any 937 of the software image or configuration information. The software 938 image may give an indication of exploits which the device is 939 vulnerable to while the configuration information can inadvertently 940 lead attackers to identify critical infrastructure IP addresses and 941 passwords. 943 2.6.3 Offline Cryptographic Attacks 945 If any cryptographic mechanism was used to provide for data integrity 946 and confidentiality, an offline cryptographic attack could 947 potentially compromise the data. The traffic would need to be 948 captured either by eavesdropping on the network or by being able to 949 divert traffic to a malicious user. 951 2.6.4 Replay Attacks 953 For a replay attack to be successful, the software image or 954 configuration file would need to first be captured either on-path or 955 diverted to an attacker to later be replayed to the intended 956 recipient. 958 2.6.5 Message Insertion/Deletion/Modification 960 Software images and configuration files can be manipulated by someone 961 in control of intermediate hosts. By forging an IP address and 962 impersonating a valid host which can download software images or 963 configuration files, invalid files can be downloaded to an 964 infrastructure device. An invalid software image or configuration 965 file can cause a device to hang and become inoperable. Spoofed 966 configuration files can be hard to detect, especially when the only 967 added command is to allow a miscreant access to that device by 968 entering a filter allowing a specific host access and configuring a 969 local username/password database entry for authentication to that 970 device. 972 2.6.6 Man-In-The-Middle 974 A man-in-the-middle attack attacks the identity of a communicating 975 peer rather than the data stream itself. The attacker intercepts 976 traffic that is sent between the infrastructure device and the host 977 used to upload/download the system image or configuration file and 978 acts on behalf of one or both of these systems. 980 2.6.7 Security Practices 982 Images and configurations are stored on specific hosts which have 983 limited access. All access and activity relating to these hosts are 984 authenticated and logged via AAA services. When uploaded/downloading 985 any system software or configuration files, either TFTP, FTP or SCP 986 can be used. Where possible, SCP is used to secure the data transfer 987 and FTP is generally never used. All TFTP and SCP access is 988 username/password authenticated and in most environments scripts are 989 used for maintaining a large number of routers. To ensure the 990 integrity of the configurations, every hour the configuration files 991 are polled and compared to the previously polled version to find 992 discrepancies. In at least one environment these tools are 993 Kerberized to take advantage of automated authentication (not 994 confidentiality). 996 Filters are used to limit access to uploading/downloading 997 configuration files and system images to specific IP addresses and 998 protocols. 1000 The software images perform CRC-checks but many ISPs expressed 1001 interest in having software image integrity validation based on the 1002 MD5 algorithm for enhanced security. The system binaries use the MD5 1003 algorithm to validate integrity. 1005 In all configuration files, the passwords are stored in an obfuscated 1006 format. This includes passwords for user authentication, MD5 shared 1007 secrets, AAA server shared secrets, NTP shared secrets, etc. For 1008 older software which may not support this functionality, 1009 configuration files are stored with passwords in readable format. 1010 [is this true? are configuration files then protected? if passwords 1011 in readable format, is the thought that an OOB management network 1012 with SCP will be enough protection? ] 1014 Automated security validation is performed on infrastructure devices 1015 using nmap and nessus to ensure valid configuration against many of 1016 the well-known attacks. 1018 2.6.8 Security Services 1020 o User Authentication - All users are authenticated before being 1021 able to download/upload any system images or configuration files. 1022 o User Authorization - All authenticated users are granted specific 1023 privileges to download or upload system images and/or 1024 configuration files. 1025 o Data Origin Authentication - TBD 1026 o Access Control - Filters are used to limit access to 1027 uploading/downloading configuration files and system images to 1028 specific IP addresses and protocols. 1029 o Data Integrity - All systems use either a CRC-check or MD5 1030 authentication to ensure data integrity. 1031 o Data Confidentiality - If the SCP protocol is used then there is 1032 confidentiality of the downloaded/uploaded configuration files and 1033 system images. 1034 o Auditing / Logging - All access and activity relating to 1035 downloading/uploading system images and configuration files are 1036 logged via AAA services and filter exception rules. 1037 o DoS Mitigation - TBD 1039 2.6.9 Additional Considerations 1041 Where the MD5 algorithm is not used to perform data integrity 1042 checking, ISPs have expressed an interest in having this 1043 functionality. IPsec is considered too cumbersome and operationally 1044 difficult to use for data integrity and confidentiality. 1046 2.7 Logging Considerations 1048 Although logging is part of all the previous sections, it is 1049 important enough to be covered as a separate item. The main issues 1050 revolve around what gets logged, how long are logs kept and what 1051 mechanisms are used to secure the logged information while it is in 1052 transit and while it is stored. 1054 2.7.1 Threats / Attacks 1056 Attacks on the logged data can be both from passive or active 1057 sources. Passive attacks are possible if someone has the capability 1058 to intercept data between the recipient logging server and the device 1059 the logged data originated from. This can be accomplished if a 1060 single infrastructure device is somehow compromised and can act as a 1061 network sniffer or if it is possible to insert a new device which 1062 acts as a network sniffer. 1064 Active attacks are possible for both on-path and off-path scenarios. 1065 For on-path active attacks, the situation is the same as for a 1066 passive attack, where either a device has to already be compromised 1067 or a device can be inserted into the path. For off-path active 1068 attacks, the attacks are generally limited to message insertion or 1069 modification which can alter the logged data to keep any compromise 1070 from being detected or to destroy any evidence which could be used 1071 for criminal prosecution. 1073 2.7.1.1 Confidentiality Violations 1075 Confidentiality violations can occur when a miscreant intercepts any 1076 of the logging data which is in transit on the network. This could 1077 lead to privacy violations if some of the logged data has not been 1078 sanitized to disallow any data that could be a violation of privacy 1079 to be included in the logged data. 1081 2.7.1.2 Offline Cryptographic Attacks 1083 If any cryptographic mechanism was used to provide for data integrity 1084 and confidentiality, an offline cryptographic attack could 1085 potentially compromise the data. The traffic would need to be 1086 captured either by eavesdropping on the network or by being able to 1087 divert traffic to a malicious user. 1089 2.7.1.3 Replay Attacks 1091 For a replay attack to be successful, the logging data would need to 1092 first be captured either on-path or diverted to an attacker and later 1093 replayed to the recipient. [is reply handled by syslog protocol?] 1095 2.7.1.4 Message Insertion/Deletion/Modification 1097 Logging data could be injected, deleted or modified by someone in 1098 control of intermediate hosts. Logging data can also be injected by 1099 forging packets from either legitimate or illegitimate IP addresses. 1101 2.7.1.5 Man-In-The-Middle 1103 A man-in-the-middle attack attacks the identity of a communicating 1104 peer rather than the data stream itself. The attacker intercepts 1105 traffic that is sent between the infrastructure device and the 1106 logging server or traffic sent between the logging server and the 1107 database which is used to archive the logged data. 1109 2.7.2 Security Practices 1111 Logging is mostly performed on an exception auditing basis when it 1112 comes to filtering (i.e. traffic which is NOT allowed is logged). 1113 Typically the data logged will contain the source and destination IP 1114 addresses and layer 4 port numbers as well as a timestamp. The 1115 syslog protocol is used to transfer the logged data between the 1116 infrastructure device to the syslog server. Many ISPs use the OOB 1117 management network to transfer syslog data since there is virtually 1118 no security performed between the syslog server and the device. All 1119 ISPs have multiple syslog servers - some ISPs choose to use separate 1120 syslog servers for varying infrastructure devices (i.e. one syslog 1121 server for backbone routers, one syslog server for customer edge 1122 routers, etc.) 1124 The timestamp is derived from NTP which is generally configured as a 1125 flat hierarchy at stratum1 and stratum2 to have less configuration 1126 and less maintenance. Each router is configured with one stratum1 1127 peer both locally and remotely. 1129 In addition to logging filtering exceptions, the following is 1130 typically logged: Routing protocol state changes, all device access 1131 (regardless of authentication success or failure), all commands 1132 issued to a device, all configuration changes and all router events 1133 (boot-up/flaps). 1135 The main function of any of these log messages is to see what the 1136 device is doing as well as to try and ascertain what certain 1137 malicious attackers are trying to do. Some ISPs put in passive 1138 devices to see routing updates and withdrawals and not rely solely on 1139 the device for log files. This provides a backup mechanism to see 1140 what is going on in the network in the event that a device may 1141 'forget' to do syslog if the CPU is busy. 1143 The logs from the various syslog server devices are generally 1144 transferred into databases at a set interval which can be anywhere 1145 from every 10 minutes to every hour. One ISP uses Rsync to push the 1146 data into a database and then the information is sorted manually by 1147 someone SSH'ing to that database. 1149 2.7.3 Security Services 1151 o User Authentication - Not applicable 1152 o User Authorization - Not applicable 1153 o Data Origin Authentication - TBD 1154 o Access Control - Filtering on logging host and server IP address 1155 to ensure that syslog information only goes to specific syslog 1156 hosts. 1157 o Data Integrity - Not implemented 1158 o Data Confidentiality - Not implemented 1159 o Auditing / Logging - TBD 1160 o DoS Mitigation - TBD 1162 2.7.4 Additional Considerations 1164 There is no security with syslog and ISPs are fully cognizant of 1165 this. IPsec is considered too operationally expensive and cumbersome 1166 to deploy. Syslog-ng and stunnel are being looked at for providing 1167 better authenticated and integrity protected solutions. 1169 ISPs expressed requirements for more than just UDP syslog. They 1170 would also like more granular and flexible facilities and priorities, 1171 i.e. specific logs to specific servers. 1173 2.8 Filtering Considerations 1175 [Editor note: Already covered but could be a sum up. This section to 1176 be added if enough proponents for it ] 1178 2.8.1 Threats / Attacks 1180 To be added. 1182 2.8.2 Security Mechanisms 1184 To be added. 1186 2.8.3 Security Services 1188 To be added. 1190 o TBD 1191 o TBD 1193 2.8.4 Additional Considerations 1195 TBD. 1197 2.9 Denial of Service Tracking / Tracing 1199 [special section for describing security techniques to avoid well 1200 known attacks? Includes sink hole routing, black-hole filtering, 1201 uRPF, rate limiting] 1203 2.9.1 Threats / Attacks 1205 To be added. 1207 2.9.2 Security Mechanisms 1209 To be added. 1211 2.9.3 Security Services 1213 To be added. 1215 o TBD 1216 o TBD 1218 2.9.4 Additional Considerations 1220 TBD 1222 3. Security Considerations 1224 This entire document deals with current security practices in large 1225 ISP environments. As a synopsis, a table is shown below which 1226 summarizes the operational functions which are to be protected and 1227 the security services which currently deployed security practices 1228 offer: [ Table to be added ] 1230 4. Normative References 1232 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1233 Requirement Levels", BCP 14, RFC 2119, March 1997. 1235 [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May 1236 2000. 1238 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1239 Text on Security Considerations", BCP 72, RFC 3552, July 1240 2003. 1242 Author's Address 1244 Merike Kaeo 1245 Double Shot Security, Inc. 1246 520 Washington Blvd. #363 1247 Marina Del Rey, CA 90292 1248 U.S.A. 1250 Phone: +1 310 866 0165 1251 Email: merike@doubleshotsecurity.com 1253 Appendix A. Acknowledgments 1255 The editor gratefully acknowledges the contributions of: 1257 o George Jones, who has been instrumental in providing guidance and 1258 direction for this document. 1259 o To be named 1260 o To be named 1262 This listing is intended to acknowledge contributions, not to imply 1263 that the individual or organizations approve the content of this 1264 document. 1266 Intellectual Property Statement 1268 The IETF takes no position regarding the validity or scope of any 1269 Intellectual Property Rights or other rights that might be claimed to 1270 pertain to the implementation or use of the technology described in 1271 this document or the extent to which any license under such rights 1272 might or might not be available; nor does it represent that it has 1273 made any independent effort to identify any such rights. Information 1274 on the procedures with respect to rights in RFC documents can be 1275 found in BCP 78 and BCP 79. 1277 Copies of IPR disclosures made to the IETF Secretariat and any 1278 assurances of licenses to be made available, or the result of an 1279 attempt made to obtain a general license or permission for the use of 1280 such proprietary rights by implementers or users of this 1281 specification can be obtained from the IETF on-line IPR repository at 1282 http://www.ietf.org/ipr. 1284 The IETF invites any interested party to bring to its attention any 1285 copyrights, patents or patent applications, or other proprietary 1286 rights that may cover technology that may be required to implement 1287 this standard. Please address the information to the IETF at 1288 ietf-ipr@ietf.org. 1290 Disclaimer of Validity 1292 This document and the information contained herein are provided on an 1293 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1294 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1295 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1296 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1297 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1298 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1300 Copyright Statement 1302 Copyright (C) The Internet Society (2005). This document is subject 1303 to the rights, licenses and restrictions contained in BCP 78, and 1304 except as set forth therein, the authors retain all their rights. 1306 Acknowledgment 1308 Funding for the RFC Editor function is currently provided by the 1309 Internet Society.