RFC 4778

Operational Security Current Practices in Internet Service Provider Environments

📅 published January 2007, from ietf

Current Operational Security Practices in Internet Service Provider Environments 🎀

okay bestie, welcome to part 1 of 8 🦋 this one is an RFC, so it's the actual spec-y kind of document. that means the vibe is going to be chatty, but every fact stays exactly the same ✨

Title block facts (the important stuff 💅):

  • Number: RFC 4778
  • Author: M. Kaeo of Double Shot Security, Inc.
  • Stream: Network Working Group
  • Category: Informational 📚 (it's giving "here's some info for the community," not a standard)
  • Date: January 2007
  • Obsoletes / Updates: the header doesn't list any RFCs as obsoleted or updated 🙈

Status of This Memo 📝

this memo is here to give the Internet community some information 🌸 it is not a standard of any kind, and it doesn't specify one. distribution of it is unlimited, so share away 💜

Copyright (C) The IETF Trust (2007).

Abstract 🔍

okay so the whole doc is a survey 📊 of how the big ISP networks in today's world secure their layer 2 and layer 3 infrastructure devices. the info in here came from people who are directly responsible for defining and building secure setups in ISP environments. they're the real ones 🫶

Table of Contents 🗂️

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
  1.1.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  2
  1.2.  Threat Model . . . . . . . . . . . . . . . . . . . . . . .  3
  1.3.  Attack Sources . . . . . . . . . . . . . . . . . . . . . .  4
  1.4.  Operational Security Impact from Threats . . . . . . . . .  5
  1.5.  Document Layout  . . . . . . . . . . . . . . . . . . . . .  7
2.  Protected Operational Functions  . . . . . . . . . . . . . . .  8
  2.1.  Device Physical Access . . . . . . . . . . . . . . . . . .  8
  2.2.  Device Management - In-Band and Out-of-Band (OOB)  . . . . 10
  2.3.  Data Path  . . . . . . . . . . . . . . . . . . . . . . . . 16
  2.4.  Routing Control Plane  . . . . . . . . . . . . . . . . . . 18
  2.5.  Software Upgrades and Configuration
        Integrity/Validation . . . . . . . . . . . . . . . . . . . 22
  2.6.  Logging Considerations . . . . . . . . . . . . . . . . . . 26
  2.7.  Filtering Considerations . . . . . . . . . . . . . . . . . 29
  2.8.  Denial-of-Service Tracking/Tracing . . . . . . . . . . . . 30
3.  Security Considerations  . . . . . . . . . . . . . . . . . . . 32
4.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 32
5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
  5.1.  Normative References . . . . . . . . . . . . . . . . . . . 33
  5.2.  Informational References . . . . . . . . . . . . . . . . . 33
Appendix A.  Protocol Specific Attacks . . . . . . . . . . . . . . 34
  A.1.  Layer 2 Attacks  . . . . . . . . . . . . . . . . . . . . . 34
  A.2.  IPv4 Protocol-Based Attacks  . . . . . . . . . . . . . . . 34
  A.3.  IPv6 Attacks . . . . . . . . . . . . . . . . . . . . . . . 36

1. Introduction ✨

okay so network operators have been through the growing pains of securing their infrastructures for years 😭 they totally know their stuff, but there's never been a written doc that lists all these security practices in one place. and attacks keep going up 📈 ngl, an ISP isn't really the Internet police, but each ISP still has to make sure certain practices are followed so their network stays operationally available for customers 💖

so this document is the result of a survey 📋 that asked what security practices are being used right now to protect network infrastructure. it's the receipts, bestie 🧾

1.1. Scope 🎯

the scope is basically security practices that cut down on risks which could hurt network availability and reliability ⭐ securing the actual data traffic is not part of this survey, so don't come for that 🙅‍♀️ the doc only covers what's currently deployed to secure layer 2 and layer 3 network infrastructure devices.

it's mostly focused on IPv4, but a lot of these same practices can (and should!) apply to IPv6 networks too 🧚 so both IPv4 and IPv6 infrastructures were taken into account in the survey 🌈

1.2. Threat Model 💀

okay, the threat model part is giving "define your terms" 🤓 a threat is a potential for a security violation. it shows up when there's a circumstance, capability, action, or event that could break security and cause harm [RFC2828].

every operational network deals with a bunch of threat actions, a.k.a. attacks 😤 an attack is an assault on system security that comes from an intelligent act, a deliberate attempt to get around security services and break the system's security policy [RFC2828]. a lot of threats to network infrastructure come from one of these (or a combo of them) 👇

  • Reconnaissance: an attack where info gets gathered to figure out the network topology or specific device details, which can then be used to exploit known vulnerabilities 🕵️‍♀️
  • Man-In-The-Middle: an attack where a bad actor impersonates either the sender or the recipient of a communication stream while inserting, modifying, or dropping certain traffic 🫣 this also covers phishing and session hijacks.
  • Protocol Vulnerability Exploitation: an attack that takes advantage of known protocol vulnerabilities, from design or implementation flaws, to cause inappropriate behavior 💥
  • Message Insertion: this can be a valid message (it could be a replay attack, where a message gets captured and resent later on 🔁). a message can also be inserted with any of its fields spoofed, like IP addresses, port numbers, header fields, or even packet content. flooding is part of this threat too 🌊
  • Message Diversion/Deletion: an attack where legit messages get removed before they reach the intended recipient, or get redirected to a network segment that's normally not part of the data path 🛤️
  • Message Modification: this is a subset of message insertion where a previous message has been captured and changed before being retransmitted 📝 the message can be captured using a man-in-the-middle attack or message diversion.
🚨 quick note: sometimes denial-of-service attacks get listed as their own separate categories. but a denial-of-service is a consequence of an attack, not a category of its own 💅 it can come from too much traffic (aka flooding), from exploiting protocols, or from inserting, deleting, diverting, or modifying messages.

1.3. Attack Sources 🎭

these attacks can come from a bunch of different sources 🌸 the doc sorts them into a few pairs:

Active vs Passive Attacks

okay so an active attack means writing data to the network ✍️ it's common for active attackers to disguise their address and hide who's actually sending the traffic. a passive attack only involves reading information off the network 👀 that's possible if the attacker controls a host on the path between two victim machines, or if they've compromised the routing infrastructure so traffic gets routed through a compromised machine. there are also cases where mirrored traffic (often used for debugging, performance monitoring, or accounting) gets diverted to a compromised machine. that doesn't necessarily mess with the existing topology, so it can be harder to detect 🫥 in general, the goal of a passive attack is to get info that the sender and receiver would rather keep private [RFC3552].

On-path vs Off-path Attacks

so for a datagram to get from one host to another, it usually has to go through some set of intermediate links and routers 🛣️ those routers can naturally read, modify, or remove any datagram sent along that path 😬 that makes it way easier to pull off all kinds of attacks if you're on-path. off-path hosts can send arbitrary datagrams that look like they're coming from any host, but they can't necessarily receive datagrams meant for other hosts 📭 so if an attack depends on receiving data, off-path hosts have to subvert the topology first to get themselves on-path. that's not impossible, but it's also not necessarily easy [RFC3552].

there's also a sneakier one: the traffic-mirroring capability of a device gets hijacked and traffic is diverted to a compromised host. this works because the network topology might not need to be subverted at all 🕳️

Insider vs Outsider Attacks

an "insider attack" starts from inside a given security perimeter, by an entity that's authorized to access system resources but uses them in a way the people who granted that authorization didn't approve 🧑‍💼 an "outside attack" starts from outside the perimeter, by an unauthorized or illegitimate user of the system 🚪

Deliberate Attacks vs Unintentional Events 😵

a deliberate attack is when a miscreant intentionally goes after system security 😈 but there are also times when unintentional events cause the same harm, even though nobody meant any malice. configuration errors and software bugs can be just as devastating to network availability as a deliberate attack on the infrastructure 💔

the attack source can be any combination of the above, and all of them need to be considered when figuring out how much impact an attack could have on the network's availability and reliability 🧮 it's nearly impossible to stop insider attacks or unintentional events 😮‍💨 but if the right monitoring mechanisms are in place, they can be detected and mitigated just like any other attack source 👀 how hard it is to identify and trace an attack depends, of course, on how resourceful the attacker is 🧠

any of the specific attacks discussed later in this document will focus on malicious behavior sourced by an "outsider" and that's deliberate 🎯 the doc also gets into the feasibility of passive vs active and on-path vs off-path attacks, which shows why certain security features are worth deploying 🛡️ 💜

1.4. Operational Security Impact from Threats

okay so the big question for every attack scenario is how much damage it can do to the network infrastructure 😭🫶 threat consequences are the security violations a threat action (aka an attack) actually causes. they usually fall into four buckets 💅

(Unauthorized) Disclosure 🔓 This is when someone gets their hands on data they were never allowed to see. not iconic behaviour, babe 🙈

Deception 🎭 This is when an authorized entity gets fake data and genuinely believes it's real. the worst kind of plot twist ngl 💀

Disruption 💥 This is anything that interrupts or stops system services and functions from working properly. a whole bunch of attacks, grouped together as denial of service (DoS) attacks, threaten the availability of systems and bandwidth for legitimate users. lots of them are built to eat up machine resources so real users can't get served. others just make the target machine crash, which shuts service down completely 😩

Usurpation 👑 This is when an unauthorized entity takes control of system services or functions. most network infrastructure systems are only meant to be fully accessible to certain authorized people. if some random person gets into critical layer 2/layer 3 infrastructure devices or services, they can seriously wreck the reliability and availability of the whole network 🚨

a full list of the threat actions that can cause these consequences is in [RFC2828]. ngl attackers usually don't do just one thing. they chain a bunch of different network attacks together to get one or more of the consequences above 🧩 for example, say a malicious user can eavesdrop on traffic. first they listen in for a while, doing recon and figuring out which IP addresses belong to specific devices, like routers 👀 if this miscreant grabs something like a router password sent in cleartext, they can go ahead and compromise the actual router. from there they can launch active attacks, like sending bogus routing updates to redirect traffic or capture even more traffic so they can compromise other network devices 😤 this document lists the countermeasures ISPs are deploying today, but if you want a solid general analysis of real backbone infrastructure attacks and the right countermeasures for them, check out [RTGWG] ✨

1.5. Document Layout

this document is a survey of the operational practices ISPs use right now to reduce the risk of being vulnerable to any threat action 🦋 so the main focus is on the security practices currently deployed to detect and/or mitigate attacks. the top-level categories are based on operational functions for ISPs, and they mostly line up with what needs protecting. each one walks through which attacks are possible and then the security practices currently in use. those practices give you the security services you need to help mitigate the attacks. the security services are classified as follows:

  • User Authentication
  • User Authorization
  • Data Origin Authentication
  • Access Control
  • Data Integrity
  • Data Confidentiality
  • Auditing/Logging
  • DoS Mitigation

a single protocol often offers a combo of these services 🎀 for example, Authentication, Authorization, and Accounting (AAA) can give you user authentication, user authorization, and audit/logging, while the Secure SHell (SSH) Protocol can provide data origin authentication, data integrity, and data confidentiality. the services themselves matter more than the specific protocol used 💜 also, access control here basically means logical access control, i.e., filtering. every section ends with an additional considerations section explaining why specific protocols may or may not be used, plus some info on capabilities that aren't possible today because of bugs or lack of usability 🙈

2. Protected Operational Functions ✨

2.1. Device Physical Access 🔐

device physical access is all about protecting the physical location of a layer 2 or layer 3 network infrastructure device and who can get to it. physical security is a huge field of study and practice on its own, probably the biggest, oldest, and most well-understood area of security 📚 contingency plans for natural disasters like earthquakes and floods that can damage networking devices are important too, but they're out of scope for this document 🌊 what we care about here is protecting access to the physical location, and how a device can still be protected from unauthorized access if that location gets compromised. in other words, protecting console access 🖥️ this is mostly about stopping an intruder with physical access from gaining operational control of the device(s). and heads up, nothing can stop an attacker with physical access from pulling off a denial-of-service attack. they can just power the device off or unplug some cables 💀

2.1.1. Threats/Attacks

if an intruder gets physical access to a layer 2 or layer 3 device, the whole network infrastructure can end up under their control 😱 at the very least, they can take the compromised device out of service and cause network disruption, and how bad that gets depends on the network topology. a worse scenario is when the intruder uses the device to crack the console password and gets complete control of the device, maybe without anyone noticing. or they plug another network device into a port and siphon off data so they can work out the network topology, and then the entire network is at risk 🫠

the threat of gaining physical access can happen in lots of ways, even when critical devices are under heavy security 🚪 there have been cases where attackers pretended to be maintenance workers to get physical access to critical devices, and that caused major outages and privacy breaches. insider attacks from authorized personnel are also a real threat, and they have to be properly recognized and dealt with 👀

2.1.2. Security Practices

for physical device security, equipment is kept in highly restrictive environments 🔒 only authorized users with card-key badges can get into any location that houses critical network infrastructure devices. these card-key systems track who accessed which location and when 🗝️ most card-key systems also have a fail-back "master key" in case the card system goes down. this "master key" usually has limited access, and its use is carefully logged (which should only happen if the card-key system is NOT online/functional).

all console access is always password protected, and the login times out after a set amount of inactivity, typically between 3-10 minutes ⏰ the privileges you get from a console login depend on the vendor device. on some devices you get basic access first and then have to do a second authentication step to get more privileged access (i.e., enable or root). on other vendors' devices, logging into the console as root gives you the more privileged access straight away, with no second authentication step 😤

how ISPs manage these logins varies a lot, but many of the bigger ISPs use some kind of AAA mechanism to automate privilege-level authorization, and they use that automation to skip the second authentication step 🤖 a lot of ISPs also define separate classes of users who get different privileges when they're logged into the console 🎀 typically, all console access goes through an out-of-band (OOB) management infrastructure, which is covered in Section 2.2 of this document 🌈

2.1.3. Security Services

the following security services come from the practices in the previous section ✨

  • User Authentication - Everyone who has access to the physical facility is authenticated. console access is authenticated too.
  • User Authorization - An authenticated individual has implicit authorization to run commands on the device. in some cases, multiple authentication is required to tell basic access apart from more privileged access.
  • Data Origin Authentication - NOT applicable.
  • Access Control - NOT applicable.
  • Data Integrity - NOT applicable.
  • Data Confidentiality - NOT applicable.
  • Auditing/Logging - All access to the physical locations of the infrastructure equipment is logged through the electronic card-key systems. All console access is logged (refer to Section 2.2 of this document for more details).
  • DoS Mitigation - NOT applicable.

2.1.4. Additional Considerations

physical security matters for the operational security practices in this document mostly from a console-access angle 🖥️ most ISPs provide console access through an OOB management infrastructure, which is discussed in Section 2.2 of this document.

the physical and logical authentication and logging systems should run independently of each other and live in different physical locations 🏢 these systems also need to be secured so they can't be compromised, because that could hand the intruder valuable authentication and logging information 🕵️

social engineering plays a huge role in lots of physical access compromises 🙈 most ISPs run training classes and awareness programs to teach company staff to deny physical access to anyone who hasn't been properly authenticated or authorized to get into critical infrastructure devices. no cap, the human firewall matters 💖

2.2. Device Management - In-Band and Out-of-Band (OOB) 🛰️

in-band management is generally device access where the control traffic takes the same data path as the traffic moving across the network. out-of-band management is generally device access where the control traffic takes a separate path from the network's data traffic 🛤️ in lots of environments, device management for layer 2 and layer 3 infrastructure devices is part of an out-of-band management infrastructure, though there are some cases where it's done in-band too. while a lot of the security concerns and practices are the same for OOB and in-band management, most ISPs prefer OOB, since access to the devices that make up the management network is protected more vigilantly and is considered less susceptible to malicious activity 🔐✨

console access is always set up over an OOB network 💜 right now, the mechanisms used for in-band management or OOB are virtual terminal access (i.e., Telnet or SSH), Simple Network Management Protocol (SNMP), or HTTP. in every large ISP that was interviewed, HTTP management was never used and was explicitly disabled 🚫 heads up that file transfer protocols (TFTP, FTP, and SCP) get covered in Section 2.5 of this document 🎀

2.2.1. Threats/Attacks 🕵️‍♀️

okay so for device management, passive attacks are possible if someone can intercept data between the management device and the managed device 👀 💅 That's a real threat if one infrastructure device gets compromised and starts acting as a network sniffer, or if someone can plug in a new device that sniffs traffic 😱

Active attacks are possible for both on-path and off-path scenarios 🦋 For on-path active attacks, it's the same deal as passive: either a device has to already be compromised, or a device can be inserted into the path. For off-path active attacks, the attacker has to subvert the topology to reroute traffic and basically get themselves on-path. Once they're there, the attack is generally limited to message insertion or modification 🫣

2.2.1.1. Confidentiality Violations 🔐

Confidentiality violations can happen when a miscreant intercepts any management data that was sent in cleartext or with weak encryption 😤 That includes usernames and passwords, which let an intruder get unauthorized access to network devices. It can also include other stuff, like logging or configuration information, if an administrator is remotely viewing local logfiles or configuration information 📜

2.2.1.2. Offline Cryptographic Attacks 🧮

If the username/password information was encrypted, but the cryptographic mechanism made it easy to capture data and break the encryption key, the device management traffic could be compromised 💀 The traffic would need to be captured either by eavesdropping on the network or by being able to divert traffic to a malicious user 🙈

2.2.1.3. Replay Attacks 🔁

For a replay attack to work, the management traffic would first need to be captured, either on-path or by being diverted to an attacker. Then it gets replayed to the intended recipient later 🎭

2.2.1.4. Message Insertion/Deletion/Modification ✏️

Data can be manipulated by someone who's in control of intermediary hosts 😬 Forging data is also possible with IP spoofing, where a remote host sends out packets that look like they came from another, trusted host 🫠

2.2.1.5. Man-In-The-Middle 🥷

A man-in-the-middle attack goes after the identity of a communicating peer rather than the data stream itself 🧐 The attacker intercepts traffic sent from a management system to the networking infrastructure device, and traffic sent from the networking infrastructure device to the management system. Iconic villain behavior, honestly 💅

2.2.2. Security Practices 🛡️

OOB management is done via a terminal server at each location 🏢 SSH access gets you to the terminal server, and that's where sessions to the devices get started from. Dial-in access is set up as a backup in case the network isn't available. However, it's common to use dial-back, encrypting modems, and/or one-time-password (OTP) modems to avoid the security weaknesses of plain dial-in access 🔒

All in-band management and OOB management access to layer 2 and layer 3 devices is authenticated ✅ User authentication and authorization is typically controlled by an AAA server (i.e., Remote Authentication Dial-in User Service (RADIUS) and/or Terminal Access Controller Access-Control System (TACACS+)) 🧠 Credentials used to determine a user's identity range from static username/password to one-time username/password schemes such as Secure-ID. Static username/passwords expire after a specified period of time, usually 30 days ⏳ Every authenticated entity via AAA is an individual user, for greater granularity of control 🎀 Note that the AAA server used for OOB management authentication is often a separate physical device from the AAA server used for in-band management user authentication 👯 In some deployments, the AAA servers used for device management authentication/authorization/accounting are on separate networks, to provide a demarcation for any other authentication functions 🚧

For backup purposes, there's often a single local database entry for authentication that is known to a very limited set of key personnel 🗝️ It's usually the highest privilege-level username/password combination, which in most cases is the same across all devices. This local device password is routinely regenerated once every 2-3 months 🔄 It's also regenerated immediately after an employee who had access to that password leaves the company or is no longer authorized to know it 🚪

Each individual user in the AAA database is configured with specific authorization capability 👑 Specific commands are either individually denied or permitted, depending on the capability of the device being accessed. Multiple privilege levels are deployed. Most individuals are authorized for basic access to a minimal set of commands, while a subset of individuals are authorized to run more privileged commands 💁‍♀️ Securing the AAA server is imperative, and access to the AAA server itself is strictly controlled 🔐 When an individual leaves the company, their AAA account is immediately deleted, and the TACACS/RADIUS shared secret is reset for all devices 💥

Some management functions are performed using command line interface (CLI) scripting 💻 In these scenarios, a dedicated user is used for the identity in the scripts that perform CLI scripting. Once authenticated, these scripts control which commands are legitimate, depending on the authorization rights of the authenticated individual 🤖

SSH is always used for virtual terminal access, to provide an encrypted communication channel 🫶 There are exceptions due to equipment limitations, which are described in the additional considerations section 📝

If SNMP is used for management, it's for read queries only and restricted to specific hosts 📖 If possible, the view is also restricted to only send the information the management station needs, rather than exposing the entire configuration file with the read-only SNMP community 🙅‍♀️ The community strings are carefully chosen to be difficult to crack, and there are procedures in place to change these community strings every 30-90 days 🔁 If systems support two SNMP community strings, the old string is replaced by first configuring a second, newer community string and then migrating from the currently used string to the newer one 🪄 Most large ISPs have multiple SNMP systems accessing their routers, so it takes more than one maintenance period to get all the strings fixed in all the right systems 🥲 SNMP RW is not used and is disabled by configuration 🚫

Access control is strictly enforced for infrastructure devices by using stringent filtering rules 🧱 A limited set of IP addresses are allowed to initiate connections to the infrastructure devices, and those addresses are specific to the services they're limited to (i.e., SSH and SNMP) 🎯

All device management access is audited, and any violations trigger alarms that set off automated email, pager, and/or telephone notifications 🚨 AAA servers keep track of the authenticated entity as well as all the commands carried out on a specific device 📋 Additionally, the device itself logs any access control violations (i.e., if an SSH request comes in from an IP address that isn't explicitly permitted, that event is logged so the offending IP address can be tracked down and investigations can be made into why it was trying to access a particular infrastructure device) 🕵️‍♀️✨

2.2.3. Security Services 🌟

The security services offered for device OOB management are nearly identical to those for device in-band management 👯‍♀️ Because controlling and limiting device access is so critical, many ISPs feel that physically separating management traffic from normal customer data traffic adds a layer of risk mitigation and limits the potential attack vectors 🧱 The following security services are offered through the practices described in the previous section 💖

  • User Authentication - All individuals are authenticated via AAA services. 🪪
  • User Authorization - All individuals are authorized via AAA services to perform specific operations once successfully authenticated. 👑
  • Data Origin Authentication - Management traffic is strictly filtered so only specific IP addresses can access the infrastructure devices. This does not alleviate risk from spoofed traffic. However, when combined with edge filtering using BCP38 [RFC2827] and BCP84 [RFC3704] guidelines (discussed in Section 2.5), the risk of spoofing is mitigated, barring a compromised internal system 🧯 Also, using SSH for device access ensures that no one can spoof the traffic during the SSH session 🫢
  • Access Control - Management traffic is filtered so only specific IP addresses can access the infrastructure devices. 🚪
  • Data Integrity - Using SSH provides data integrity and ensures that no one has altered the management data in transit. 🧩
  • Data Confidentiality - Using SSH provides data confidentiality. 🤫
  • Auditing/Logging - Using AAA provides an audit trail for who accessed which device and which operations were performed. 📚
  • DoS Mitigation - Using packet filters so only specific IP addresses can access the infrastructure devices. This limits, but does not prevent, spoofed DoS attacks directed at an infrastructure device. However, the risk is lowered by using a separate physical network for management purposes 🛟

2.2.4. Additional Considerations

okay so password selection for any device management protocol is critical, bestie 🔐 the passwords need to be hard to guess or break with a brute-force attack. no shortcuts 💅

IP security (IPsec) is considered too difficult to deploy 😭 so the common protocol for confidential management access is SSH ✨. there are exceptions for using SSH because of equipment limitations, since SSH may not be supported on legacy equipment 🙈. in some cases, changing the host name of a device requires an SSH rekey event, since the key is based on some combination of host name, Message Authentication Code (MAC) address, and time 🌀. also, if the SSH key is stored on a route processor card, SSH would need to be re-keyed whenever the route processor card needs to be swapped 🔄. some providers feel this operational impact exceeds the security necessary, so they use Telnet from trusted inside hosts (called 'jumphosts' or 'bastion hosts') to manage those devices 🦋. the individual first SSHes to the jumphost and then Telnets from the jumphost to the actual infrastructure device, fully understanding that any passwords will be sent in the clear between the jumphost and the device it's connecting to 👀. all authentication and authorization is still carried out using AAA servers 🫶.

when Telnet access is used, the logs on the AAA servers are more verbose and more attention is paid to them to detect any abnormal behavior 🔍. the jumphosts themselves are carefully controlled machines and usually have limited access 🔒. ngl this part is so important: Telnet is NEVER allowed to an infrastructure device except from specific jumphosts; i.e., packet filters are used at the console server and/or infrastructure device to ensure that Telnet is only allowed from specific IP addresses 🚫💜.

with thousands of devices to manage, some ISPs have created automated mechanisms to authenticate to devices 🧚. for example, Kerberos has been used to automate the authentication process for devices that support Kerberos ✨. the individual first logs in to a Kerberized UNIX server using SSH and generates a Kerberos 'ticket' 🎟️. this 'ticket' is generally set to have a lifespan of 10 hours and is used to automatically authenticate the individual to the infrastructure devices 🌸.

in instances where SNMP is used, some legacy devices only support SNMPv1, which then requires the provider to mandate its use across all infrastructure devices for operational simplicity 🍓. SNMPv2 is mostly deployed because it is easier to set up than v3 💅.

2.3. Data Path

this section is all about how traffic gets handled as it traverses the network infrastructure device 🛣️. the primary goal of ISPs is to forward customer traffic 💖. however, there's a LOT of malicious traffic that can cause DoS attacks and make the network unavailable 😭, so specific measures are sometimes deployed to make sure legitimate customer traffic can still get forwarded 🛡️.

2.3.1. Threats/Attacks

any data traffic can potentially be attack traffic 💀, and the challenge is to detect and potentially stop forwarding the malicious traffic 🚨. the deliberately sourced attack traffic can consist of packets with spoofed source and/or destination addresses, or any other malformed packet that mangles any portion of a header field to cause protocol-related security issues 🙃. these include resetting connections, causing unwelcome ICMP redirects, creating unwelcome IP options, or packet fragmentations 🌪️.

2.3.2. Security Practices

filtering and rate limiting are the primary mechanisms to mitigate the risk of malicious traffic making ISP services unavailable 🛑. filtering and rate limiting of data path traffic is deployed in a variety of ways, depending on how automated the process is and on the capabilities and performance limitations of the hardware already deployed 🔧.

ISPs that don't have performance issues with their equipment follow BCP38 [RFC2827] and BCP84 [RFC3704] guidelines for ingress filtering 🎀. BCP38 recommends filtering ingress packets with obviously spoofed and/or 'reserved' source addresses to limit the effects of denial-of-service attacks, while BCP84 extends that recommendation for multi-homed environments 🌈. filters also help alleviate issues between service providers 🤝. without any filtering, an inter-exchange peer could steal transit just by using static routes and essentially redirect data traffic 😤. so some ISPs have implemented ingress/egress filters that block unexpected source and destination addresses not defined in the above-mentioned documents 🚧. null routes and black-hole triggered routing [RFC3882] are used to deter any detected malicious traffic streams 🕳️. these two techniques are described in more detail in Section 2.8 below 📖.

most ISPs think layer 4 filtering is useful, but it's only implemented if performance limitations allow for it 🥺. since it poses a large administrative overhead, and ISPs are very much opposed to acting as the Internet firewall, Layer 4 filtering is typically implemented as a last option 🙅‍♀️. Netflow is used for tracking traffic flows, but there's some concern about whether sampling is good enough to detect malicious behavior 🤔.

Unicast Reverse Path Forwarding (RPF) is not consistently implemented 🌀. some ISPs are in the process of doing so, while other ISPs think the perceived benefit of knowing that spoofed traffic comes from legitimate addresses isn't worth the operational complexity 🙄. some providers have a policy of implementing uRPF at link speeds of Digital Signal 3 (DS3) and below, because all the hardware in the network supported uRPF for DS3 speeds and below 🧃. at higher-speed links, uRPF support was inconsistent, so it was easier for operational people to implement a consistent solution 💜.

2.3.3. Security Services

o User Authentication - Not applicable. 🙅‍♀️

o User Authorization - Not applicable. 🙅‍♀️

o Data Origin Authentication - When IP address filtering per BCP38, BCP84, and uRPF are deployed at network edges, it can ensure that any spoofed traffic comes from at least a legitimate IP address and can be tracked 🕵️‍♀️.

o Access Control - IP address filtering and layer 4 filtering are used to deny forbidden protocols and limit traffic destined for the infrastructure device itself 🔐. filters are also used to block unexpected source/destination addresses 🚫.

o Data Integrity - Not applicable. 🙅‍♀️

o Data Confidentiality - Not applicable. 🙅‍♀️

o Auditing/Logging - Filtering exceptions are logged for potential attack traffic 📝.

o DoS Mitigation - Black-hole triggered filtering and rate-limiting are used to limit the risk of DoS attacks 🛡️✨.

2.3.4. Additional Considerations

for layer 2 devices, MAC address filtering and authentication are not used in large-scale deployments 🙈. this is because of the problems they can cause when troubleshooting networking issues 😩. port security becomes unmanageable at a large scale where thousands of switches are deployed 🌪️.

rate limiting is used by some ISPs, although other ISPs believe it's not really useful, since attackers aren't well-behaved and it doesn't provide any operational benefit over the complexity 🤷‍♀️. some ISPs feel rate limiting can also make an attacker's job easier, by requiring the attacker to send less traffic to starve legitimate traffic that's part of a rate limiting scheme 😈. rate limiting may be improved by developing flow-based rate-limiting capabilities with filtering hooks 🌟. this would improve both the performance and the granularity over current capabilities 📈.

a lack of consistency regarding the ability to filter, especially with respect to performance issues, causes some ISPs not to implement BCP38 and BCP84 guidelines for ingress filtering 😮‍💨. one such example is at edge boxes, where up to 1000 T1s connect into a router with an OC-12 (Optical Carrier) uplink 🧩. some deployed devices experience a large performance impact with filtering, which is unacceptable for passing customer traffic through 💔, though ingress filtering (uRPF) might be applicable at the devices connecting these aggregation routers 🫧. where performance isn't an issue, ISPs make a tradeoff between management and risk ⚖️.

2.4. Routing Control Plane

the routing control plane deals with all the traffic that's part of establishing and maintaining routing protocol information 🗺️✨.

2.4.1. Threats/Attacks

attacks on the routing control plane can come from both passive and active sources 👀. passive attacks are possible if someone has the capability to intercept data between the communicating routing peers 🕳️. this can happen if a single routing peer is somehow compromised and acts as a network sniffer, or if it's possible to insert a new device that acts as a network sniffer 🐍.

active attacks are possible for both on-path and off-path scenarios 🎭. for on-path active attacks, the situation is the same as for a passive attack: either a device has to already be compromised, or a device can be inserted into the path 😱. this may lead to an attacker impersonating a legitimate routing peer and exchanging routing information 🥸. unintentional active attacks are more common, due to configuration errors that cause legitimate routing peers to feed invalid routing information to other neighboring peers 🤦‍♀️.

for off-path active attacks, the attacks are generally limited to message insertion or modification 🧾. these can divert traffic to illegitimate destinations, causing traffic to never reach its intended destination 💀.

2.4.1.1. Confidentiality Violations

confidentiality violations can occur when a miscreant intercepts any of the routing update traffic 🕵️. this is becoming more of a concern because many ISPs classify addressing schemes and network topologies as private and proprietary information 🔏. it's also a concern because the routing protocol packets contain information that may show ways routing sessions could be spoofed or hijacked 😬. this in turn could lead into a man-in-the-middle attack, where miscreants insert themselves into the traffic path or divert the traffic path, violating the confidentiality of user data 🚨🎀.

2.4.1.2. Offline Cryptographic Attacks

if any cryptographic mechanism was used to provide data integrity and confidentiality, an offline cryptographic attack could potentially compromise the data 🔓. the traffic would need to be captured, either by eavesdropping on the network or by being able to divert traffic to a malicious user 🎣. note that by using cryptographically protected routing information, the latter would require the cryptographic key to already be compromised anyway 🔑, so this attack is only feasible if a device was able to eavesdrop and capture the cryptographically protected routing information 🧠.

2.4.1.3. Replay Attacks

for a replay attack to succeed, the routing control plane traffic would first need to be captured, either on-path or diverted to an attacker, to later be replayed to the intended recipient 🔁. additionally, since many of these protocols include replay protection mechanisms, those would also need to be subverted, if applicable 🛠️💅.

2.4.1.4. Message Insertion/Deletion/Modification 🎀

Okay so routing control plane traffic can be messed with by anyone who controls intermediate hosts 😬. And it gets worse, bestie, because traffic can also be injected by forging IP addresses. A remote router can send out packets that look like they came from another, trusted router 🕵️‍♀️. If enough of that injected traffic lands on limited-memory routers, they have to process it all, and that can cause a DoS attack 💀.

2.4.1.5. Man-In-The-Middle 🦋

A man-in-the-middle attack goes after the identity of a communicating peer, not the data stream itself 👀. The attacker intercepts traffic sent from one routing peer to the other and then communicates on behalf of one of the peers. The result can be that user traffic gets diverted to an unauthorized receiving party, or legitimate traffic never reaches its intended destination. Yikes, not it 😭.

2.4.2. Security Practices 💅

Securing the routing control plane takes a lot of features, and they're generally deployed as a whole system 🧩. Some ISPs use Message Digest 5 (MD5) authentication to validate the sending peer and to make sure the data in transit hasn't been altered 🔐. Some ISPs only deploy MD5 authentication when a customer asks for it.

There are also extra sanity checks that give reasonable certainty a received routing update came from a valid routing peer. These include route filters and the Generalized TTL Security Mechanism (GTSM) feature [RFC3682], which is sometimes also called the TTL-Hack 🧠. GTSM is used for protocols like the Border Gateway Protocol (BGP). It makes use of a packet's Time To Live (TTL) field (IPv4) or Hop Limit (IPv6) to protect communicating peers. If GTSM is used, it's typically only deployed in limited scenarios between internal BGP peers, because vendor products and operating system versions don't consistently support it. Not consistent, not iconic 🙈.

Packet filters limit which systems can appear as a valid peer, while route filters limit which routes are believed to come from a valid peer 🌸. With BGP routing, a bunch of policies get deployed to limit the spread of invalid routing information 🚫. These include incoming and outgoing prefix filters for BGP customers, incoming and outgoing prefix filters for peers and upstream neighbors, an incoming AS-PATH filter for BGP customers, an outgoing AS-PATH filter towards peers and upstream neighbors, route dampening, and rejecting selected attributes and communities.

The consistency between these policies varies a lot, and it really matters whether the other end is an end-site, an internal peer, or another big ISP or customer 🌈. Mostly, ISPs prefix-filter their end-site customers. But maintaining large prefix filter lists is operationally a pain, so many ISPs are starting to depend on BGP AS-PATH filters to and from their peers and upstream neighbors ✨.

When prefix lists aren't used, operators often set a maximum prefix limit per peer. This guards against misconfiguration (for example, unintentional de-aggregation or a neighbor routing policy mis-configuration) or overload attacks 🛡️. ISPs need to coordinate with each other about what the expected prefix exchange looks like, then raise that number by some sane amount. It's important for ISPs to pad the max-prefix number enough to allow for valid swings in routing announcements, so the BGP session doesn't get shut down by accident 🫶. How ISPs implement this is unique to each one, and depending on their equipment supplier(s), different implementation options are available. Most equipment vendors offer options that range from just logging excessive prefixes being received, all the way to automatically shutting down the session 🔥.

If the option to re-establish a session after some pre-configured idle timeout is available, it should be understood that automatically re-establishing the session may potentially introduce instability into the overall routing table continuously, if a policy mis-configuration on the adjacent neighbor is causing the condition 🌀. If a serious mis-configuration has happened on a peering neighbor, then automatically shutting down the session and leaving it shut down until it's manually cleared is sometimes the best move. That allows an operator to step in and correct things as needed 👑.

Some large ISPs require routes to be registered in an Internet Routing Registry (IRR), which can then be part of the Routing Assets Database (RADb). RADb is a public registry of routing information for networks in the Internet that can be used to generate filter lists 📚. Some ISPs, especially in Europe, require registered routes before they'll agree to become an eBGP peer with someone 🇪🇺.

Many ISPs also don't propagate interface IP addresses, which further reduces attack vectors on routers and connected customers 🧚.

2.4.3. Security Services 🍓

  • User Authentication - Not applicable.
  • User Authorization - Not applicable.
  • Data Origin Authentication - By using MD5 authentication and/or the TTL-hack, a routing peer can be reasonably certain that traffic originated from a valid peer 💜.
  • Access Control - Route filters, AS-PATH filters, and prefix limits are used to control access to specific parts of the network 🚪.
  • Data Integrity - By using MD5 authentication, a peer can be reasonably certain that the data hasn't been modified in transit. But there's no mechanism to prove the validity of the routing information itself 🤔.
  • Data Confidentiality - Not implemented.
  • Auditing / Logging - Filter exceptions are logged 📝.
  • DoS Mitigation - Many DoS attacks are mitigated using a combination of techniques, including MD5 authentication, the GTSM feature, filtering routing advertisements to bogons, and filtering routing advertisements to one's own network 🛑.

2.4.4. Additional Considerations 🌷

So far, the main concern with securing the routing control plane has been validating the sending peer and making sure the data in transit hasn't been altered 🧐. MD5 routing protocol extensions have been implemented, and they can provide both of those services. But they aren't consistently deployed across ISPs 😤. There are two big deployment concerns. One is implementation issues, where both software bugs and a lack of graceful re-keying options have caused significant network downtime 📉. The other is that some ISPs worry that deploying MD5 authentication will make them a worse DoS attack victim. So they prefer a combination of other risk mitigation mechanisms, like GTSM (for BGP) and route filters 🫠. One issue with GTSM is that it isn't supported on all devices across different vendors' products.

IPsec isn't deployed, because the operational management needed to ensure interoperability and reliable configurations is too complex and time consuming to be operationally viable 🙅‍♀️. There's also limited concern about the confidentiality of routing information. The integrity and validity of the updates are of much greater concern 💖.

There's concern about manual or automated actions that introduce new routes, since those can affect the entire routing domain 🌍.

2.5. Software Upgrades and Configuration Integrity/Validation 🛠️

Software upgrades and configuration changes are usually performed as part of either in-band or OOB management functions. There are additional considerations to take into account, though, and they're listed in this section ✨.

2.5.1. Threats/Attacks 😈

Attacks on system software and configurations can come from passive or active sources 👻. Passive attacks are possible if someone can intercept data between the network infrastructure device and the system that's downloading or uploading the software or configuration information. That can happen if a single infrastructure device is somehow compromised and acts as a network sniffer, or if someone can insert a new device that acts as a network sniffer 🔍.

Active attacks are possible in both on-path and off-path scenarios. For on-path active attacks, the situation is the same as for a passive attack: either a device has to already be compromised, or a device can be inserted into the path. For off-path active attacks, the attacks are generally limited to message insertion or modification, where the attacker may want to load illegal software or configuration files onto an infrastructure device 🚨.

Note that similar issues are relevant when software updates are downloaded from a vendor site to an ISP's network management system, which is responsible for software updates and/or configuration information 📦.

2.5.1.1. Confidentiality Violations 🫣

Confidentiality violations can happen when a miscreant intercepts any of the software image or configuration information 👀. The software image may hint at exploits the device is vulnerable to. The configuration information can inadvertently lead attackers to critical infrastructure IP addresses and passwords. Scary stuff, bestie 😱.

2.5.1.2. Offline Cryptographic Attacks 🔑

If any cryptographic mechanism was used to provide data integrity and confidentiality, an offline cryptographic attack could potentially compromise the data 🧮. The traffic would first need to be captured, either by eavesdropping on the communication path or by being able to divert traffic to a malicious user.

2.5.1.3. Replay Attacks 🔁

For a replay attack to work, the software image or configuration file would first need to be captured, either on-path or by being diverted to an attacker. Then it gets replayed to the intended recipient later 📼. Also, since many protocols do have replay protection capabilities, those would have to be subverted as well in applicable situations. Not easy, not me 🙅‍♀️.

2.5.1.4. Message Insertion/Deletion/Modification 💀

Software images and configuration files can be manipulated by someone in control of intermediate hosts 🕸️. By forging an IP address and impersonating a valid host that can download software images or configuration files, invalid files can be downloaded to an infrastructure device. This can also happen with trusted vendors who, unbeknownst to them, have had trusted hosts compromised 😩. An invalid software image or configuration file can cause a device to hang and become inoperable. Spoofed configuration files can be really hard to detect, especially when the only added command is one that lets a miscreant access that device. That's done by entering a filter allowing a specific host access and configuring a local username/password database entry for authentication to the device 🔓.

2.5.1.5. Man-In-The-Middle 🪞

A man-in-the-middle attack goes after the identity of a communicating peer, not the data stream itself. The attacker intercepts traffic sent between the infrastructure device and the host used to upload or download the system image or configuration file. They can then act on behalf of one or both of those systems 🎭.

If an attacker obtained a copy of the software image being deployed, they could potentially exploit a known vulnerability and gain access to the system 🚪. From a captured configuration file, they could obtain confidential network topology information. Or, even more damaging, they could get passwords if any of them weren't encrypted in the configuration file 😭🔥.

2.5.2. Security Practices ✨

Okay bestie, so images and configs live on specific hosts with really limited access 🔒. Every bit of access and activity on those hosts gets authenticated and logged through AAA services 📝. When you upload or download system software or config files, you can use TFTP, FTP, or SCP. Where possible, SCP is used to lock down the transfer, and FTP is generally never used 🙅‍♀️. All SCP access is username/password authenticated, but since that needs an interactive shell, most ISPs use shared key authentication to skip the interactive shell 🔑.

TFTP has zero security measures, ngl 💀, but it's still super widely used, especially in OOB management setups. Some ISPs do IP-based restriction on the TFTP server, and some custom-written TFTP servers support MAC-based authentication. MAC-based auth is more common when you're using TFTP to bootstrap routers remotely 🦋.

In most environments, scripts maintain the images and configs for a huge number of routers 🧚. To keep the configs intact, the config files get polled every hour and compared to the previously polled version to catch any discrepancies 👀. In at least one environment, these tools are Kerberized to take advantage of automated authentication (not confidentiality) 🔐. 'Rancid' is one popular publicly available tool for detecting configuration and system changes 💜.

Filters are used to limit access to uploading and downloading config files and system images to specific IP addresses and protocols 🚧.

The software images perform Cyclic Redundancy Checks (CRC), and the system binaries use the MD5 algorithm to validate integrity 🔍. Many ISPs expressed interest in having software image integrity validation based on the MD5 algorithm for enhanced security 🌸.

In all config files, most passwords are stored in an encrypted format 🎀. Heads up: the encryption techniques vary between products, and some weaker encryption schemes may be subject to off-line dictionary attacks 🙈. This includes passwords for user authentication, MD5-authentication shared secrets, AAA server shared secrets, NTP shared secrets, etc. For older software that may not support this functionality, config files may contain some passwords in readable format 😬. Most ISPs mitigate the risk of password compromise by either storing these config files without the password lines, or by requiring authenticated and authorized access to the config files stored on protected OOB management devices 🛡️.

Automated security validation is performed on infrastructure devices using Network Mapping (Nmap) and Nessus, to make sure the config is valid against many of the well-known attacks ✅.

2.5.3. Security Services

  • User Authentication - All users are authenticated before being able to download or upload any system images or config files 🪪.
  • User Authorization - All authenticated users are granted specific privileges to download or upload system images and/or configuration files 🗝️.
  • Data Origin Authentication - Filters are used to limit access to uploading and downloading configuration files and system images to specific IP addresses 📍.
  • Access Control - Filters are used to limit access to uploading and downloading configuration files and system images to specific IP addresses and protocols 🚦.
  • Data Integrity - All systems use either a CRC-check or MD5 authentication to ensure data integrity. Also, tools such as rancid are used to automatically detect configuration changes 🧾.
  • Data Confidentiality - If the SCP protocol is used, then the downloaded and uploaded configuration files and system images are confidential 🤫.
  • Auditing/Logging - All access and activity relating to downloading and uploading system images and configuration files is logged via AAA services and filter exception rules 📚.
  • DoS Mitigation - A combination of filtering and CRC-check or MD5-based integrity checks is used to mitigate the risks of DoS attacks. If the software updates and config changes are performed via an OOB management system, that's extra protection too 🛡️✨.

2.5.4. Additional Considerations

Where the MD5 algorithm is not used to perform data-integrity checking of software images and config files, ISPs have expressed an interest in having this functionality 💭. IPsec is considered too cumbersome and operationally difficult to use for data integrity and confidentiality 😩.

2.6. Logging Considerations

Logging is part of all the previous sections, but it's important enough to get its own section 📋. The main issues revolve around what gets logged, how long logs are kept, and what mechanisms are used to secure the logged information while it's in transit and while it's stored 🔐.

2.6.1. Threats/Attacks

Attacks on the logged data can come from passive or active sources 👀. Passive attacks are possible if someone can intercept data between the recipient logging server and the device the logged data came from. This can happen if a single infrastructure device is somehow compromised and acts as a network sniffer, or if it's possible to insert a new device that acts as a network sniffer 🕵️‍♀️.

Active attacks are possible for both on-path and off-path scenarios 💥. For on-path active attacks, the situation is the same as for a passive attack: either a device already has to be compromised, or a device can be inserted into the path. For off-path active attacks, the attacks are generally limited to message insertion or modification that can alter the logged data to keep any compromise from being detected, or to destroy any evidence that could be used for criminal prosecution 😱.

2.6.1.1. Confidentiality Violations

Confidentiality violations can happen when a miscreant intercepts any of the logging data in transit on the network 🫣. This could lead to privacy violations if some of the logged data hasn't been sanitized to disallow any data that could violate privacy from being included in the logs 🙅‍♀️.

2.6.1.2. Offline Cryptographic Attacks

If any cryptographic mechanism was used to provide data integrity and confidentiality, an offline cryptographic attack could potentially compromise the data 🔓. The traffic would need to be captured either by eavesdropping on the network or by diverting traffic to a malicious user 🎣.

2.6.1.3. Replay Attacks

For a replay attack to succeed, the logging data would first need to be captured on-path or diverted to an attacker, and then replayed to the recipient 🔁.

2.6.1.4. Message Insertion/Deletion/Modification

Logging data could be injected, deleted, or modified by someone in control of intermediate hosts 🧌. Logging data can also be injected by forging packets from either legitimate or illegitimate IP addresses 🎭.

2.6.1.5. Man-In-The-Middle

A man-in-the-middle attack goes after the identity of a communicating peer rather than the data stream itself 🕵️. The attacker intercepts traffic sent between the infrastructure device and the logging server, or traffic sent between the logging server and the database used to archive the logged data 🚨. Any unauthorized access to logging information could reveal private and proprietary network topology information, which could be used to compromise portions of the network 😭. An additional concern is access to logging information that could be deleted or modified to cover any traces of a security breach 🫥.

2.6.2. Security Practices

When it comes to filtering, logging is mostly performed on an exception auditing basis (i.e., traffic that is NOT allowed is logged) 🚫. This makes sure the logging servers aren't overwhelmed with data, which would render most logs unusable 🧠. Typically, the data logged will contain the source and destination IP addresses and layer 4 port numbers, as well as a timestamp ⏰. The syslog protocol is used to transfer the logged data from the infrastructure device to the syslog server 📤. Many ISPs use the OOB management network to transfer syslog data, since there is virtually no security between the syslog server and the device 🫠. All ISPs have multiple syslog servers. Some ISPs choose separate syslog servers for different infrastructure devices (e.g., one syslog server for backbone routers, one syslog server for customer edge routers, etc.) 🗂️.

The timestamp is derived from NTP, which is generally configured as a flat hierarchy at stratum1 and stratum2, so there's less configuration and less maintenance 🕰️. Consistency of configuration and redundancy is the primary goal 💖. Each router is configured with several stratum1 server sources, chosen to make sure proper NTP time is available even during varying network outages 🌈.

Besides logging filtering exceptions, the following is typically logged: routing protocol state changes, all device access (regardless of authentication success or failure), all commands issued to a device, all configuration changes, and all router events (boot-up/flaps) 📜.

The main function of these log messages is to see what the device is doing, and to try to figure out what malicious attackers are up to 🔎. Since syslog is an unreliable protocol, when routers boot or lose adjacencies, not all messages will get delivered to the remote syslog server 😵. Some vendors may implement syslog buffering (e.g., buffer the messages until there's a route to the syslog destination), but this is not standard 🤷‍♀️. So operators often have to look at local syslog information on a device (which typically has very little memory allocated to it) to make up for the fact that the server-based syslog files can be incomplete 💻. Some ISPs also put in passive devices to see routing updates and withdrawals, and don't rely solely on the device for log files. This gives a backup mechanism to see what's going on in the network if a device 'forgets' to do syslog because the CPU is busy 🛟.

The logs from the various syslog server devices are generally transferred into databases at a set interval, anywhere from every 10 minutes to every hour ⏳. One ISP uses Rsync to push the data into a database, and then the information is sorted manually by someone SSH'ing to that database 🥱.

2.6.3. Security Services

  • User Authentication - Not applicable.
  • User Authorization - Not applicable.
  • Data Origin Authentication - Not implemented.
  • Access Control - Filtering on logging host and server IP address to ensure that syslog information only goes to specific syslog hosts 🎯.
  • Data Integrity - Not implemented.
  • Data Confidentiality - Not implemented.
  • Auditing/Logging - This entire section deals with logging 📖.
  • DoS Mitigation - An OOB management system is used, and sometimes different syslog servers are used for logging information from varying equipment. Exception logging tries to keep information to a minimum 🪶.

2.6.4. Additional Considerations 🔐

Okay bestie, the big tea is that there is literally no security with syslog 💀, and ISPs are fully aware of it. IPsec is considered too operationally expensive and cumbersome to deploy 😩. Syslog-ng and stunnel are being looked at to provide better authenticated and integrity-protected solutions ✨. For stopping unauthorized personnel from tampering with logs, the only thing going on is auditing who has access to the logging servers and files 👀.

ISPs want more than just UDP syslog 🫶. They also want more granular and flexible facilities and priorities, i.e., specific logs going to specific servers 🎯. And they want a common format for reporting standard events, so parsers don't need to be modified after each upgrade of a vendor device or software 🙅‍♀️💖.

2.7. Filtering Considerations 🛡️

Filtering has already come up in a bunch of the earlier sections, but this part gives some extra insight into the filtering considerations people are actually taking into account right now. Filtering is now sorted into three specific areas: data plane, management plane, and routing control plane 🍓.

2.7.1. Data Plane Filtering 🚰

Data plane filters control the traffic that traverses through a device and affects transit traffic. Most ISPs deploy these at their customer facing edge devices to mitigate spoofing attacks, following BCP38 and BCP84 guidelines 🦋.

2.7.2. Management Plane Filtering 🎀

Management filters control the traffic to and from a device. All of the protocols used for device management fall under this category, including SSH, Telnet, SNMP, NTP, HTTP, DNS, TFTP, FTP, SCP, and Syslog 📋. This traffic is often filtered per interface, based on any combination of protocol, source and destination IP address, and source and destination port number 🔍.

Some devices can apply management filters to the device itself rather than to specific interfaces (e.g., receive ACL or loopback interface ACL), and this is gaining wider acceptance 🌈. Heads up though: logging the filtering rules can today put a burden on many systems, and more granularity is often required to log the required exceptions more specifically 📝.

Any services that are not specifically used are turned off 🔌.

IPv6 networks need specific ICMP messages for proper protocol operation 🧚. That means ICMP cannot be completely filtered to and from a device. Instead, granular ICMPv6 filtering is always deployed to allow specific ICMPv6 types to be sourced or destined to a network device 💅. A good guideline for IPv6 filtering is in the Recommendations for Filtering ICMPv6 Messages in Firewalls [ICMPv6] 📚.

2.7.3. Routing Control Plane Filtering 🗺️

Routing filters control the flow of routing information. In IPv6 networks, some providers are liberal about accepting /48 prefixes because the multihoming issues are still unresolved 🤷‍♀️, while others filter at allocation boundaries, which are typically /32 🧱. Any announcement received that is longer than a /48 for IPv6 routing, or a /24 for IPv4 routing, is filtered out of eBGP 🚫. This is for non-customer traffic. Most ISPs will accept any agreed upon prefix length from their customer(s) 🫶.

2.8. Denial-of-Service Tracking/Tracing 🚨

Denial-of-Service attacks are an ever-increasing problem, and they take vast amounts of resources to combat effectively 😭. Some large ISPs don't concern themselves with attack streams under 1G in bandwidth. On the larger pipes, 1G is essentially less than 5% of an offered load 🙄. This is largely because of the huge amounts of DoS traffic, which keeps needing investigation and mitigation. At last count, the number of hosts making up large distributed DoS botnets exceeded 1 million hosts 🤯💀.

New techniques keep evolving to automate detecting DoS sources and mitigating their adverse effects as quickly as possible ⚡. Right now, ISPs use a variety of mitigation techniques, including sinkhole routing, black hole triggered routing, uRPF, rate limiting, and specific control plane traffic enhancements 🧰. Each of these will be detailed below 👇.

2.8.1. Sinkhole Routing 🕳️

Sinkhole routing means injecting a more specific route for any known attack traffic. This makes sure the malicious traffic gets redirected to a valid device or specific system where it can be analyzed 🔬.

2.8.2. Black Hole Triggered Routing 🖤

Black hole triggered routing (also called Remote Triggered Black Hole Filtering) is a technique where the BGP routing protocol propagates routes that redirect attack traffic to the null interface, where it's effectively dropped 🗑️. It's often used in large routing infrastructures because BGP can propagate the information in a fast, effective manner, as opposed to using packet-based filtering on hundreds or thousands of routers 🚀. For a more complete description, check out the NANOG presentation at http://www.nanog.org/mtg-0402/pdf/morrow.pdf 📽️.

Be aware that this black-holing technique may actually fulfill the attacker's goal if the goal was to make it look like traffic was coming from a certain site 😬. On the flip side, black hole routing can decrease the collateral damage caused by an overly large attack aimed at something other than critical services 🛟.

2.8.3. Unicast Reverse Path Forwarding 🔄

Unicast Reverse Path Forwarding (uRPF) is a mechanism for checking whether an incoming packet has a legitimate source address 🕵️‍♀️. It has two modes: strict mode and loose mode 🎭.

In strict mode, uRPF checks whether the incoming packet has a source address that matches a prefix in the routing table, and whether the interface expects to receive a packet with that source address prefix. If the incoming packet fails the unicast RPF check, the packet is not accepted on the incoming interface 🚪❌.

Loose mode uRPF is not as specific. The incoming packet is accepted if there is any route in the routing table for the source address 🫠.

BCP84 [RFC3704] and a study on uRPF experiences [BCP84-URPF] explain how asymmetry, i.e., multiple routes to the source of a packet, does not preclude applying feasible paths strict uRPF 🧠. Even so, strict uRPF is generally not used on interfaces that are likely to have routing asymmetry 🙅‍♀️. For the larger ISPs, uRPF is usually placed at the customer edge of the network 🏰.

2.8.4. Rate Limiting 🚦

Rate limiting means allocating a specific amount of bandwidth or packets per second to specific traffic types 📊. It's widely used to mitigate well-known protocol attacks such as the TCP-SYN attack, where a large number of resources get allocated for spoofed TCP traffic 🥲. Rate limiting doesn't stop an attack, but it can sometimes lessen the damage and impact on a specific service 🩹. The catch is that it can also make the impact of a DoS attack much worse if the rate limiting ends up discarding more legitimate traffic 😱.

2.8.5. Specific Control Plane Traffic Enhancements 🎛️

Some ISPs are starting to use capabilities available from some vendors to simplify filtering and rate limiting of control traffic 💫. Control traffic here refers to routing control plane and management plane traffic that requires CPU cycles 🧮. A DoS attack against any control plane traffic can therefore be much more damaging to a critical device than other types of traffic 💥. No consistent deployment of this capability was found at the time of this writing 🤷‍♀️.

3. Security Considerations 🛡️

This entire document deals with current security practices in large ISP environments 🧾. It lists specific practices used in today's environments and, as such, does not in itself pose any security risk 💜.

4. Acknowledgments ✨

The editor gratefully acknowledges the contributions of George Jones, who has been instrumental in providing guidance and direction for this document 👑. Thanks also to the insightful comments from Ross Callon, Ron Bonica, Ryan Mcdowell, Gaurab Upadhaya, Warren Kumari, Pekka Savola, Fernando Gont, Chris Morrow, Ted Seely, Donald Smith, and the numerous ISP operators who supplied the information depicted in this document 🫶🌸.

5. References

5.1. Normative References

  • [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
  • [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May 2000.
  • [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
  • [RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL Security Mechanism (GTSM)", RFC 3682, February 2004.
  • [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
  • [RFC3882] Turk, D., "Configuring BGP to Block Denial-of-Service Attacks", RFC 3882, September 2004.

5.2. Informational References

  • [BCP84-URPF] Savola, P., "Experiences from Using Unicast RPF", Work in Progress, November 2006.
  • [ICMPv6] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", Work in Progress, July 2006.
  • [RTGWG] Savola, P., "Backbone Infrastructure Attacks and Protections", Work in Progress, July 2006.

Appendix A. Protocol Specific Attacks ⚠️

This section lists many of the traditional protocol-based attacks that have been observed over the years to cause malformed packets and/or exploit protocol deficiencies 🕷️. Note that they all exploit vulnerabilities in the actual protocol itself, and additional authentication and auditing mechanisms are often used now to detect and mitigate their impact 🛡️. The list isn't exhaustive. It's just a fraction of what types of attacks are possible for varying protocols 🫣.

A.1. Layer 2 Attacks 🕸️

  • ARP Flooding

A.2. IPv4 Protocol-Based Attacks 🧨

  • IP addresses, either source or destination, can be spoofed, which in turn can circumvent established filtering rules 🎭.
  • The IP Source Route Option can allow attackers to establish stealth TCP connections 🥷.
  • The IP Record Route Option can disclose information about the topology of the network 🗺️.
  • An IP header that is too long or too short can cause DoS attacks to devices 💥.
  • The IP Timestamp Option can leak information that can be used to discern network behavior 👀.
  • Fragmentation attacks, which can vary widely. More detailed information can be found at http://www-src.lip6.fr/homepages/Fabrice.Legond-Aubry/www.ouah.org/fragma.html 🧩.
  • The IP ToS field (or the Differentiated Services (DSCP) field) can be used to reroute or reclassify traffic based on specified precedence 🔀.
  • The IP checksum field has been used for scanning purposes, for example when some firewalls did not check the checksum and allowed an attacker to tell when the response came from an end-system and when it came from a firewall 🔍.
  • The IP TTL field can be used to bypass certain network-based intrusion detection systems and to map network behavior 🫥.

A.2.1. Higher Layer Protocol Attacks 🎀

okay so this bit is a grab bag of extra attacks 🧚 it doesn't go through each one in detail, and it's only here for info, not rules 💅

  • IGMP oversized packet
  • ICMP Source Quench
  • ICMP Mask Request
  • ICMP Large Packet (> 1472)
  • ICMP Oversized packet (>65536)
  • ICMP Flood
  • ICMP Broadcast w/ Spoofed Source (Smurf Attack)
  • ICMP Error Packet Flood
  • ICMP Spoofed Unreachable
  • TCP Packet without Flag
  • TCP Oversized Packet
  • TCP FIN bit with no ACK bit
  • TCP Packet with URG/OOB flag (Nuke Attack)
  • SYN Fragments
  • SYN Flood
  • SYN with IP Spoofing (Land Attack)
  • SYN and FIN bits set
  • TCP port scan attack
  • UDP spoofed broadcast echo (Fraggle Attack)
  • UDP attack on diagnostic ports (Pepsi Attack)

A.3. IPv6 Attacks 💜

ngl this part is the spicy one 🌶️ basically any of the IPv4 attacks above could also show up in IPv6 networks, EXCEPT for the fragmentation and broadcast stuff, because that works differently in IPv6 🙈 and all of these attacks are built on either spoofing or messing with some part of the protocol fields ✨

the other big thing is that IPv6-enabled hosts are starting to get used to build IPv6 tunnels 🦋 and those tunnels can totally hide botnet and other shady traffic if your firewalls and flow collection tools can't spot it 💀 the security measures for protecting IPv6 infrastructure should be the same as for IPv4 networks, but with extra thinking for IPv6 operations, since those may be different from IPv4 🫶

Author's Address 🌸

Merike Kaeo
Double Shot Security, Inc.
3518 Fremont Avenue North #363
Seattle, WA  98103
U.S.A.

Phone: +1 310 866 0165
EMail: merike@doubleshotsecurity.com

Copyright (C) The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property ✨

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society. 💜

📦 where this page comes from