| < draft-ietf-opsec-current-practices-06.txt | draft-ietf-opsec-current-practices-07.txt > | |||
|---|---|---|---|---|
| OPSEC M. Kaeo | OPSEC M. Kaeo | |||
| Internet-Draft Double Shot Security, Inc. | Internet-Draft Double Shot Security, Inc. | |||
| Expires: January 21, 2007 July 20, 2006 | Intended status: Informational August 29, 2006 | |||
| Expires: March 2, 2007 | ||||
| Operational Security Current Practices | Operational Security Current Practices | |||
| draft-ietf-opsec-current-practices-06 | draft-ietf-opsec-current-practices-07 | |||
| Status of this Memo | Status of this Memo | |||
| By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
| applicable patent or other IPR claims of which he or she is aware | 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 | 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. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
| skipping to change at page 1, line 33 ¶ | skipping to change at page 1, line 34 ¶ | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| This Internet-Draft will expire on January 21, 2007. | This Internet-Draft will expire on March 2, 2007. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (C) The Internet Society (2006). | Copyright (C) The Internet Society (2006). | |||
| Abstract | Abstract | |||
| This document is a survey of the current practices used in today's | This document is a survey of the current practices used in today's | |||
| large ISP operational networks to secure layer 2 and layer 3 | large ISP operational networks to secure layer 2 and layer 3 | |||
| infrastructure devices. The information listed here is the result of | infrastructure devices. The information listed here is the result of | |||
| skipping to change at page 2, line 20 ¶ | skipping to change at page 2, line 29 ¶ | |||
| 1.3. Attack Sources . . . . . . . . . . . . . . . . . . . . . . 4 | 1.3. Attack Sources . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 1.4. Operational Security Impact from Threats . . . . . . . . . 6 | 1.4. Operational Security Impact from Threats . . . . . . . . . 6 | |||
| 1.5. Document Layout . . . . . . . . . . . . . . . . . . . . . 7 | 1.5. Document Layout . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 2. Protected Operational Functions . . . . . . . . . . . . . . . 9 | 2. Protected Operational Functions . . . . . . . . . . . . . . . 9 | |||
| 2.1. Device Physical Access . . . . . . . . . . . . . . . . . . 9 | 2.1. Device Physical Access . . . . . . . . . . . . . . . . . . 9 | |||
| 2.2. Device Management - In-Band and Out-of-Band (OOB) . . . . 11 | 2.2. Device Management - In-Band and Out-of-Band (OOB) . . . . 11 | |||
| 2.3. Data Path . . . . . . . . . . . . . . . . . . . . . . . . 17 | 2.3. Data Path . . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
| 2.4. Routing Control Plane . . . . . . . . . . . . . . . . . . 19 | 2.4. Routing Control Plane . . . . . . . . . . . . . . . . . . 19 | |||
| 2.5. Software Upgrades and Configuration Integrity / | 2.5. Software Upgrades and Configuration Integrity / | |||
| Validation . . . . . . . . . . . . . . . . . . . . . . . . 23 | Validation . . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
| 2.6. Logging Considerations . . . . . . . . . . . . . . . . . . 26 | 2.6. Logging Considerations . . . . . . . . . . . . . . . . . . 27 | |||
| 2.7. Filtering Considerations . . . . . . . . . . . . . . . . . 30 | 2.7. Filtering Considerations . . . . . . . . . . . . . . . . . 30 | |||
| 2.8. Denial of Service Tracking / Tracing . . . . . . . . . . . 31 | 2.8. Denial of Service Tracking / Tracing . . . . . . . . . . . 31 | |||
| 3. Security Considerations . . . . . . . . . . . . . . . . . . . 33 | 3. Security Considerations . . . . . . . . . . . . . . . . . . . 34 | |||
| 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 | 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 | |||
| 4.1. Normative References . . . . . . . . . . . . . . . . . . . 34 | 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 | |||
| 4.2. Informational References . . . . . . . . . . . . . . . . . 34 | 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 | |||
| Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 35 | 6.1. Normative References . . . . . . . . . . . . . . . . . . . 37 | |||
| Appendix B. Protocol Specific Attacks . . . . . . . . . . . . . . 36 | 6.2. Informational References . . . . . . . . . . . . . . . . . 37 | |||
| B.1. Layer 2 Attacks . . . . . . . . . . . . . . . . . . . . . 36 | Appendix A. Protocol Specific Attacks . . . . . . . . . . . . . . 39 | |||
| B.2. IPv4 Protocol Based Attacks . . . . . . . . . . . . . . . 36 | A.1. Layer 2 Attacks . . . . . . . . . . . . . . . . . . . . . 39 | |||
| B.3. IPv6 Attacks . . . . . . . . . . . . . . . . . . . . . . . 38 | A.2. IPv4 Protocol Based Attacks . . . . . . . . . . . . . . . 39 | |||
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 39 | A.3. IPv6 Attacks . . . . . . . . . . . . . . . . . . . . . . . 41 | |||
| Intellectual Property and Copyright Statements . . . . . . . . . . 40 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 42 | |||
| Intellectual Property and Copyright Statements . . . . . . . . . . 43 | ||||
| 1. Introduction | 1. Introduction | |||
| Security practices are well understood by the network operators who | Security practices are well understood by the network operators who | |||
| have for many years gone through the growing pains of securing their | have for many years gone through the growing pains of securing their | |||
| network infrastructures. However, there does not exist a written | network infrastructures. However, there does not exist a written | |||
| document that enumerates these security practices. Network attacks | document that enumerates these security practices. Network attacks | |||
| are continually increasing and although it is not necessarily the | are continually increasing and although it is not necessarily the | |||
| role of an ISP to act as the Internet police, each ISP has to ensure | role of an ISP to act as the Internet police, each ISP has to ensure | |||
| that certain security practices are followed to ensure that their | that certain security practices are followed to ensure that their | |||
| skipping to change at page 3, line 39 ¶ | skipping to change at page 3, line 39 ¶ | |||
| infrastructures are taken into account in this survey. | infrastructures are taken into account in this survey. | |||
| 1.2. Threat Model | 1.2. Threat Model | |||
| A threat is a potential for a security violation, which exists when | A threat is a potential for a security violation, which exists when | |||
| there is a circumstance, capability, action, or event that could | there is a circumstance, capability, action, or event that could | |||
| breach security and cause harm [RFC2828]. Every operational network | breach security and cause harm [RFC2828]. Every operational network | |||
| is subject to a multitude of threat actions, or attacks, i.e. an | is subject to a multitude of threat actions, or attacks, i.e. an | |||
| assault on system security that derives from an intelligent act that | assault on system security that derives from an intelligent act that | |||
| is a deliberate attempt to evade security services and violate the | is a deliberate attempt to evade security services and violate the | |||
| security policy of a system [RFC2828]. All of the threats in any | security policy of a system [RFC2828]. Many of the threats to a | |||
| network infrastructure is an instantiation or combination of the | network infrastructure occur from an instantiation (or combination) | |||
| following: | of the following: | |||
| Reconnaissance: An attack whereby information is gathered to | Reconnaissance: An attack whereby information is gathered to | |||
| ascertain the network topology or specific device information which | ascertain the network topology or specific device information which | |||
| can be further used to exploit known vulnerabilities | can be further used to exploit known vulnerabilities | |||
| Man-In-The-Middle: An attack where a malicious user impersonates | Man-In-The-Middle: An attack where a malicious user impersonates | |||
| either the sender or recipient of a communication stream while | either the sender or recipient of a communication stream while | |||
| inserting, modifying or dropping certain traffic. This type of | inserting, modifying or dropping certain traffic. This type of | |||
| attack also covers phishing and session hijacks. | attack also covers phishing and session hijacks. | |||
| skipping to change at page 4, line 43 ¶ | skipping to change at page 4, line 43 ¶ | |||
| Active vs passive attacks | Active vs passive attacks | |||
| An active attack involves writing data to the network. It is | An active attack involves writing data to the network. It is | |||
| common practice in active attacks to disguise one's address and | common practice in active attacks to disguise one's address and | |||
| conceal the identity of the traffic sender. A passive attack | conceal the identity of the traffic sender. A passive attack | |||
| involves only reading information off the network. This is | involves only reading information off the network. This is | |||
| possible if the attacker has control of a host in the | possible if the attacker has control of a host in the | |||
| communications path between two victim machines or has compromised | communications path between two victim machines or has compromised | |||
| the routing infrastructure to specifically arrange that traffic | the routing infrastructure to specifically arrange that traffic | |||
| pass through a compromised machine. In general, the goal of a | pass through a compromised machine. There are also situations | |||
| passive attack is to obtain information that the sender and | where mirrored traffic (often used for debugging, performance | |||
| receiver would prefer to remain private. [RFC3552] | monitoring or accounting purposes) is diverted to a compromised | |||
| machine which would not necessarily subvert any existing topology | ||||
| and could be harder to detect. In general, the goal of a passive | ||||
| attack is to obtain information that the sender and receiver would | ||||
| prefer to remain private. [RFC3552] | ||||
| On-path vs off-path attacks | On-path vs off-path attacks | |||
| In order for a datagram to be transmitted from one host to | In order for a datagram to be transmitted from one host to | |||
| another, it generally must traverse some set of intermediate links | another, it generally must traverse some set of intermediate links | |||
| and routers. Such routers are naturally able to read, modify, or | and routers. Such routers are naturally able to read, modify, or | |||
| remove any datagram transmitted along that path. This makes it | remove any datagram transmitted along that path. This makes it | |||
| much easier to mount a wide variety of attacks if you are on-path. | much easier to mount a wide variety of attacks if you are on-path. | |||
| Off-path hosts can transmit arbitrary datagrams that appear to | Off-path hosts can transmit arbitrary datagrams that appear to | |||
| come from any hosts but cannot necessarily receive datagrams | come from any hosts but cannot necessarily receive datagrams | |||
| intended for other hosts. Thus, if an attack depends on being | intended for other hosts. Thus, if an attack depends on being | |||
| able to receive data, off-path hosts must first subvert the | able to receive data, off-path hosts must first subvert the | |||
| topology in order to place themselves on-path. This is by no | topology in order to place themselves on-path. This is by no | |||
| means impossible but is not necessarily trivial. [RFC3552] | means impossible but is not necessarily trivial. [RFC3552] A more | |||
| subtle attack is one where the traffic mirroring capability of a | ||||
| device is hijacked and the traffic is diverted to a compromised | ||||
| host since the network topology may not need to be subverted. | ||||
| Insider or outsider attacks | Insider or outsider attacks | |||
| An "insider attack" is one which is initiated from inside a given | An "insider attack" is one which is initiated from inside a given | |||
| security perimeter, by an entity that is authorized to access | security perimeter, by an entity that is authorized to access | |||
| system resources but uses them in a way not approved by those who | system resources but uses them in a way not approved by those who | |||
| granted the authorization. An "outside attack" is initiated from | granted the authorization. An "outside attack" is initiated from | |||
| outside the perimeter, by an unauthorized or illegitimate user of | outside the perimeter, by an unauthorized or illegitimate user of | |||
| the system. | the system. | |||
| skipping to change at page 17, line 45 ¶ | skipping to change at page 17, line 45 ¶ | |||
| follow BCP38 [RFC2827] and BCP84 [RFC3704] guidelines for ingress | follow BCP38 [RFC2827] and BCP84 [RFC3704] guidelines for ingress | |||
| filtering. BCP38 recommends filtering ingress packets with obviously | filtering. BCP38 recommends filtering ingress packets with obviously | |||
| spoofed and/or 'reserved' source addresses to limit the effects of | spoofed and/or 'reserved' source addresses to limit the effects of | |||
| denial of service attacks while BCP84 extends the recommendation for | denial of service attacks while BCP84 extends the recommendation for | |||
| multi-homed environments. Filters are also used to help alleviate | multi-homed environments. Filters are also used to help alleviate | |||
| issues between service providers. Without any filtering, an inter- | issues between service providers. Without any filtering, an inter- | |||
| exchange peer could steal transit just by using static routes and | exchange peer could steal transit just by using static routes and | |||
| essentially redirect data traffic. Therefore, some ISPs have | essentially redirect data traffic. Therefore, some ISPs have | |||
| implemented ingress/egress filters which block unexpected source and | implemented ingress/egress filters which block unexpected source and | |||
| destination addresses not defined in the above-mentioned documents. | destination addresses not defined in the above-mentioned documents. | |||
| Null routes and black-hole triggered routing are used to deter any | Null routes and black-hole triggered routing [RFC3882] are used to | |||
| detected malicious traffic streams. These two techniques are | deter any detected malicious traffic streams. These two techniques | |||
| described in more detail in section 2.8 below. | are described in more detail in section 2.8 below. | |||
| Most ISPs consider layer 4 filtering useful but it is only | Most ISPs consider layer 4 filtering useful but it is only | |||
| implemented if performance limitations allow for it. Layer 4 | implemented if performance limitations allow for it. Layer 4 | |||
| filtering is typically only when no other option exists since it does | filtering is typically only when no other option exists since it does | |||
| pose a large administrative overhead and ISPs are very much opposed | pose a large administrative overhead and ISPs are very much opposed | |||
| to acting as the Internet firewall. Netflow is used for tracking | to acting as the Internet firewall. Netflow is used for tracking | |||
| traffic flows but there is some concern whether sampling is good | traffic flows but there is some concern whether sampling is good | |||
| enough to detect malicious behavior. | enough to detect malicious behavior. | |||
| Unicast RPF is not consistently implemented. Some ISPs are in | Unicast RPF is not consistently implemented. Some ISPs are in | |||
| process of doing so while other ISPs think that the perceived benefit | process of doing so while other ISPs think that the perceived benefit | |||
| of knowing that spoofed traffic comes from legitimate addresses are | of knowing that spoofed traffic comes from legitimate addresses are | |||
| not worth the operational complexity. Some providers have a policy | not worth the operational complexity. Some providers have a policy | |||
| of implementing uRPF at link speeds of DS3 and below. | of implementing uRPF at link speeds of DS3 and below which was due to | |||
| the fact that all hardware in the network supported uRPF for DS3 | ||||
| speeds and below. At higher speed links the uRPF support was | ||||
| inconsistent and it was easier for operational people to implement a | ||||
| consistent solution. | ||||
| 2.3.3. Security Services | 2.3.3. Security Services | |||
| o User Authentication - Not applicable | o User Authentication - Not applicable | |||
| o User Authorization - Not applicable | o User Authorization - Not applicable | |||
| o Data Origin Authentication - When IP address filtering per BCP38, | o Data Origin Authentication - When IP address filtering per BCP38, | |||
| BCP84 and uRPF are deployed at network edges it can ensure that | BCP84 and uRPF are deployed at network edges it can ensure that | |||
| any spoofed traffic comes from at least a legitimate IP address | any spoofed traffic comes from at least a legitimate IP address | |||
| skipping to change at page 21, line 18 ¶ | skipping to change at page 21, line 20 ¶ | |||
| generally deployed as a system. MD5 authentication is used by some | generally deployed as a system. MD5 authentication is used by some | |||
| ISPs to validate the sending peer and to ensure that the data in | ISPs to validate the sending peer and to ensure that the data in | |||
| transit has not been altered. Some ISPs only deploy MD5 | transit has not been altered. Some ISPs only deploy MD5 | |||
| authentication at customer's request. Additional sanity checks to | authentication at customer's request. Additional sanity checks to | |||
| ensure with reasonable certainty that the received routing update was | ensure with reasonable certainty that the received routing update was | |||
| originated by a valid routing peer include route filters and the | originated by a valid routing peer include route filters and the | |||
| Generalized TTL Security Mechanism (GTSM) feature [RFC3682] | Generalized TTL Security Mechanism (GTSM) feature [RFC3682] | |||
| (sometimes also referred to as the TTL-Hack). The GTSM feature is | (sometimes also referred to as the TTL-Hack). The GTSM feature is | |||
| used for protocols such as BGP and makes use of a packet's Time To | used for protocols such as BGP and makes use of a packet's Time To | |||
| Live (TTL) field (IPv4) or Hop Limit (IPv6) to protect communicating | Live (TTL) field (IPv4) or Hop Limit (IPv6) to protect communicating | |||
| peers. | peers. If GTSM is used, it is typically only deployed in limited | |||
| scenarios between internal BGP peers due to lack of consistent | ||||
| support between vendor products and operating system versions. | ||||
| Packet filters are used to limit which systems can appear as a valid | Packet filters are used to limit which systems can appear as a valid | |||
| peer while route filters are used to limit which routes are believed | peer while route filters are used to limit which routes are believed | |||
| from a valid peer. In the case of BGP routing, a variety of policies | from a valid peer. In the case of BGP routing, a variety of policies | |||
| are deployed to limit the propagation of invalid routing information. | are deployed to limit the propagation of invalid routing information. | |||
| These include: incoming and outgoing prefix filters for BGP | These include: incoming and outgoing prefix filters for BGP | |||
| customers, incoming and outgoing prefix filters for peers and | customers, incoming and outgoing prefix filters for peers and | |||
| upstream neighbors, incoming AS-PATH filter for BGP customers, | upstream neighbors, incoming AS-PATH filter for BGP customers, | |||
| outgoing AS-PATH filter towards peers and upstream neighbors, route | outgoing AS-PATH filter towards peers and upstream neighbors, route | |||
| dampening and rejecting selected attributes and communities. | dampening and rejecting selected attributes and communities. | |||
| Consistency between these policies varies greatly and there is a | Consistency between these policies varies greatly and there is a | |||
| definite distinction whether the other end is an end-site vs an | definite distinction whether the other end is an end-site vs an | |||
| internal peer vs another big ISP or customer. Mostly ISPs do prefix- | internal peer vs another big ISP or customer. Mostly ISPs do prefix- | |||
| filter their end-site customers but due to the operational | filter their end-site customers but due to the operational | |||
| constraints of maintaining large prefix filter lists, many ISPs are | constraints of maintaining large prefix filter lists, many ISPs are | |||
| starting to depend on BGP AS-PATH filters to/from their peers and | starting to depend on BGP AS-PATH filters to/from their peers and | |||
| upstream neighbors. | upstream neighbors. | |||
| In cases where prefix lists are not used, operators often define a | In cases where prefix lists are not used, operators often define a | |||
| maximum prefix limit per peer to prevent misconfiguration (e.g., | maximum prefix limit per peer to prevent misconfiguration (e.g., | |||
| unintentional de-aggregation) or overload attacks. When the limit is | unintentional de-aggregation or neighbor routing policy mis- | |||
| exceeded, the session is either reset or further updates are denied. | configuration) or overload attacks. ISPs need to coordinate between | |||
| Typically a lower warning threshold is also configured. | each other what the expected prefix exchange is, and increase this | |||
| number by some sane amount. It is important for ISPs to pad the max- | ||||
| prefix number enough to allow for valid swings in routing | ||||
| announcements to prevent an unintentional shutting down of the BGP | ||||
| session. Individual implementation amongst ISPs are unique, and | ||||
| depending on equipment supplier(s) different implementation options | ||||
| are available. Most equipment vendors offer implementation options | ||||
| ranging from just logging excessive prefixes being received to | ||||
| automatically shutting down the session. If the option of | ||||
| reestablishing a session after some pre-configured idle timeout has | ||||
| been reached is available, it should be understood that automatically | ||||
| reestablishing the session may potentially introduce instability | ||||
| continuously into the overall routing table if a policy mis- | ||||
| configuration on the adjacent neighbor is causing the condition. If | ||||
| a serious mis-configuration on a peering neighbor has occurred then | ||||
| automatically shutting down the session and leaving it shut down | ||||
| until being manually cleared is sometimes best and allows for | ||||
| operator intervention to correct as needed. | ||||
| Some large ISPs require that routes be registered in an Internet | Some large ISPs require that routes be registered in an Internet | |||
| Routing Registry [IRR] which can then be part of the RADB - a public | Routing Registry [IRR] which can then be part of the RADB - a public | |||
| registry of routing information for networks in the Internet that can | registry of routing information for networks in the Internet that can | |||
| be used to generate filter lists. Some ISPs, especially in europe, | be used to generate filter lists. Some ISPs, especially in europe, | |||
| require registered routes before agreeing to become an eBGP peer with | require registered routes before agreeing to become an eBGP peer with | |||
| someone. | someone. | |||
| Many ISPs also do not propagate interface IP addresses to further | Many ISPs also do not propagate interface IP addresses to further | |||
| reduce attack vectors on routers and connected customers. | reduce attack vectors on routers and connected customers. | |||
| skipping to change at page 25, line 15 ¶ | skipping to change at page 25, line 37 ¶ | |||
| any system software or configuration files, either TFTP, FTP or SCP | any system software or configuration files, either TFTP, FTP or SCP | |||
| can be used. Where possible, SCP is used to secure the data transfer | can be used. Where possible, SCP is used to secure the data transfer | |||
| and FTP is generally never used. All SCP access is username/password | and FTP is generally never used. All SCP access is username/password | |||
| authenticated but since this requires an interactive shell, most ISPs | authenticated but since this requires an interactive shell, most ISPs | |||
| will use shared key authentication to avoid the interactive shell. | will use shared key authentication to avoid the interactive shell. | |||
| While TFTP access does not have any security measures, it is still | While TFTP access does not have any security measures, it is still | |||
| widely used especially in OOB management scenarios. Some ISPs | widely used especially in OOB management scenarios. Some ISPs | |||
| implement IP-based restriction on the TFTP server while some custom | implement IP-based restriction on the TFTP server while some custom | |||
| written TFTP servers will support MAC-based authentication. The MAC- | written TFTP servers will support MAC-based authentication. The MAC- | |||
| based authentication is more common when using TFTP to bootstrap | based authentication is more common when using TFTP to bootstrap | |||
| routers remotely using TFTP. | routers remotely. | |||
| In most environments scripts are used for maintaining the images and | In most environments scripts are used for maintaining the images and | |||
| configurations of a large number of routers. To ensure the integrity | configurations of a large number of routers. To ensure the integrity | |||
| of the configurations, every hour the configuration files are polled | of the configurations, every hour the configuration files are polled | |||
| and compared to the previously polled version to find discrepancies. | and compared to the previously polled version to find discrepancies. | |||
| In at least one environment these tools are Kerberized to take | In at least one environment these tools are Kerberized to take | |||
| advantage of automated authentication (not confidentiality). | advantage of automated authentication (not confidentiality). | |||
| 'Rancid' is one popular publicly available tool for detecting | 'Rancid' is one popular publicly available tool for detecting | |||
| configuration and system changes. | configuration and system changes. | |||
| skipping to change at page 26, line 34 ¶ | skipping to change at page 27, line 9 ¶ | |||
| rancid are used to automatically detect configuration changes. | rancid are used to automatically detect configuration changes. | |||
| o Data Confidentiality - If the SCP protocol is used then there is | o Data Confidentiality - If the SCP protocol is used then there is | |||
| confidentiality of the downloaded/uploaded configuration files and | confidentiality of the downloaded/uploaded configuration files and | |||
| system images. | system images. | |||
| o Auditing / Logging - All access and activity relating to | o Auditing / Logging - All access and activity relating to | |||
| downloading/uploading system images and configuration files are | downloading/uploading system images and configuration files are | |||
| logged via AAA services and filter exception rules. | logged via AAA services and filter exception rules. | |||
| o DoS Mitigation - TBD | o DoS Mitigation - A combination of filtering and CRC-check / MD5- | |||
| based integrity checks are used to mitigate the risks of DoS | ||||
| attacks. If the software updates and configuration changes are | ||||
| performed via an OOB management system, this is also added | ||||
| protection. | ||||
| 2.5.4. Additional Considerations | 2.5.4. Additional Considerations | |||
| Where the MD5 algorithm is not used to perform data integrity | Where the MD5 algorithm is not used to perform data integrity | |||
| checking of software images and configuration files, ISPs have | checking of software images and configuration files, ISPs have | |||
| expressed an interest in having this functionality. IPsec is | expressed an interest in having this functionality. IPsec is | |||
| considered too cumbersome and operationally difficult to use for data | considered too cumbersome and operationally difficult to use for data | |||
| integrity and confidentiality. | integrity and confidentiality. | |||
| 2.6. Logging Considerations | 2.6. Logging Considerations | |||
| skipping to change at page 32, line 4 ¶ | skipping to change at page 32, line 35 ¶ | |||
| Black-hole triggered routing (also referred to as Remote Triggered | Black-hole triggered routing (also referred to as Remote Triggered | |||
| Black Hole Filtering) is a technique where the BGP routing protocol | Black Hole Filtering) is a technique where the BGP routing protocol | |||
| is used to propagate routes which in turn redirects attack traffic to | is used to propagate routes which in turn redirects attack traffic to | |||
| the null interface where it is effectively dropped. This technique | the null interface where it is effectively dropped. This technique | |||
| is often used in large routing infrastructures since BGP can | is often used in large routing infrastructures since BGP can | |||
| propagate the information in a fast effective manner as opposed to | propagate the information in a fast effective manner as opposed to | |||
| using any packet-based filtering techniques on hundreds or thousands | using any packet-based filtering techniques on hundreds or thousands | |||
| of routers. [refer to the following NANOG presentation for a more | of routers. [refer to the following NANOG presentation for a more | |||
| complete description http://www.nanog.org/mtg-0402/pdf/morrow.pdf] | complete description http://www.nanog.org/mtg-0402/pdf/morrow.pdf] | |||
| Note that this black-holing technique may actually fulfill the goal | Note that this black-holing technique may actually fulfill the goal | |||
| of the attacker if the goal was to instigate blackholing traffic | of the attacker if the goal was to instigate blackholing traffic | |||
| which appeared to come from a certain site. On the other hand, this | which appeared to come from a certain site. On the other hand, this | |||
| blackhole technique can decrease the collateral damage caused by an | blackhole technique can decrease the collateral damage caused by an | |||
| overly large attack aimed at something other than critical services. | overly large attack aimed at something other than critical services. | |||
| 2.8.3. Unicast Reverse Path Forwarding | 2.8.3. Unicast Reverse Path Forwarding | |||
| Unicast Reverse Path Forwarding (uRPF) is a mechanism for validating | Unicast Reverse Path Forwarding (uRPF) is a mechanism for validating | |||
| whether an incoming packet has a legitimate source address or not. | whether an incoming packet has a legitimate source address or not. | |||
| It has two modes: strict mode and loose mode. In strict mode, uRPF | It has two modes: strict mode and loose mode. In strict mode, uRPF | |||
| checks whether the incoming packet has a source address that matches | checks whether the incoming packet has a source address that matches | |||
| a prefix in the routing table, and whether the interface expects to | a prefix in the routing table, and whether the interface expects to | |||
| receive a packet with this source address prefix. If the incoming | receive a packet with this source address prefix. If the incoming | |||
| packet fails the unicast RPF check, the packet is not accepted on the | packet fails the unicast RPF check, the packet is not accepted on the | |||
| incoming interface. Loose mode uRPF is not as specific and the | incoming interface. Loose mode uRPF is not as specific and the | |||
| incoming packet is accepted if there is any route in the routing | incoming packet is accepted if there is any route in the routing | |||
| table for the source address. | table for the source address. | |||
| While BCP84 [RFC3704] and a study on uRPF experiences [I-D.savola- | While BCP84 [RFC3704] and a study on uRPF experiences | |||
| bcp84-urpf-experiences] detail how asymmetry, i.e. multiple routes to | [I-D.savola-bcp84-urpf-experiences] detail how asymmetry, i.e. | |||
| the source of a packet, does not preclude applying feasible paths | multiple routes to the source of a packet, does not preclude applying | |||
| strict uRPF, it is generally not used on interfaces that are likely | feasible paths strict uRPF, it is generally not used on interfaces | |||
| to have routing asymmetry. Usually for the larger ISPs, uRPF is | that are likely to have routing asymmetry. Usually for the larger | |||
| placed at the customer edge of a network. | ISPs, uRPF is placed at the customer edge of a network. | |||
| 2.8.4. Rate Limiting | 2.8.4. Rate Limiting | |||
| Rate limiting refers to allocating a specific amount of bandwidth or | Rate limiting refers to allocating a specific amount of bandwidth or | |||
| packets per second to specific traffic types. This technique is | packets per second to specific traffic types. This technique is | |||
| widely used to mitigate well-known protocol attacks such as the TCP- | widely used to mitigate well-known protocol attacks such as the TCP- | |||
| SYN attack where a large number of resources get allocated for | SYN attack where a large number of resources get allocated for | |||
| spoofed TCP traffic. Although this technique does not stop an | spoofed TCP traffic. Although this technique does not stop an | |||
| attack, it can sometimes lessen the damage and impact on a specific | attack, it can sometimes lessen the damage and impact on a specific | |||
| service. However, it can also make the impact of a DDoS attack much | service. However, it can also make the impact of a DDoS attack much | |||
| skipping to change at page 34, line 5 ¶ | skipping to change at page 35, line 5 ¶ | |||
| against any control plane traffic can therefore be much more damaging | against any control plane traffic can therefore be much more damaging | |||
| to a critical device than other types of traffic. No consistent | to a critical device than other types of traffic. No consistent | |||
| deployment of this capability was found at the time of this writing. | deployment of this capability was found at the time of this writing. | |||
| 3. Security Considerations | 3. Security Considerations | |||
| This entire document deals with current security practices in large | This entire document deals with current security practices in large | |||
| ISP environments. It lists specific practices used in today's | ISP environments. It lists specific practices used in today's | |||
| environments and as such does not in itself pose any security risk. | environments and as such does not in itself pose any security risk. | |||
| 4. References | 4. IANA Considerations | |||
| 4.1. Normative References | This document has no actions for IANA. | |||
| 5. Acknowledgments | ||||
| The editor gratefully acknowledges the contributions of: George | ||||
| Jones, who has been instrumental in providing guidance and direction | ||||
| for this document and the insighful 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 which is depicted in this | ||||
| document. | ||||
| 6. References | ||||
| 6.1. Normative References | ||||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
| [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: | [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: | |||
| Defeating Denial of Service Attacks which employ IP Source | Defeating Denial of Service Attacks which employ IP Source | |||
| Address Spoofing", BCP 38, RFC 2827, May 2000. | Address Spoofing", BCP 38, RFC 2827, May 2000. | |||
| [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, | [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, | |||
| May 2000. | May 2000. | |||
| skipping to change at page 34, line 29 ¶ | skipping to change at page 37, line 29 ¶ | |||
| [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC | [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC | |||
| Text on Security Considerations", BCP 72, RFC 3552, | Text on Security Considerations", BCP 72, RFC 3552, | |||
| July 2003. | July 2003. | |||
| [RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL | [RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL | |||
| Security Mechanism (GTSM)", RFC 3682, February 2004. | Security Mechanism (GTSM)", RFC 3682, February 2004. | |||
| [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed | [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed | |||
| Networks", BCP 84, RFC 3704, March 2004. | Networks", BCP 84, RFC 3704, March 2004. | |||
| 4.2. Informational References | [RFC3882] Turk, D., "Configuring BGP to Block Denial-of-Service | |||
| Attacks", RFC 3882, September 2004. | ||||
| 6.2. Informational References | ||||
| [I-D.ietf-v6ops-icmpv6-filtering-recs] | [I-D.ietf-v6ops-icmpv6-filtering-recs] | |||
| Davies, E. and J. Mohacsi, "Recommendations for Filtering | Davies, E. and J. Mohacsi, "Recommendations for Filtering | |||
| ICMPv6 Messages in Firewalls", | ICMPv6 Messages in Firewalls", | |||
| draft-ietf-v6ops-icmpv6-filtering-recs-02 (work in | draft-ietf-v6ops-icmpv6-filtering-recs-02 (work in | |||
| progress), July 2006. | progress), July 2006. | |||
| [I-D.lewis-infrastructure-security] | [I-D.lewis-infrastructure-security] | |||
| Lewis, D., "Service Provider Infrastructure Security", | Lewis, D., "Service Provider Infrastructure Security", | |||
| draft-lewis-infrastructure-security-00 (work in progress), | draft-lewis-infrastructure-security-00 (work in progress), | |||
| skipping to change at page 35, line 5 ¶ | skipping to change at page 39, line 5 ¶ | |||
| [I-D.savola-bcp84-urpf-experiences] | [I-D.savola-bcp84-urpf-experiences] | |||
| Savola, P., "Experiences from Using Unicast RPF", | Savola, P., "Experiences from Using Unicast RPF", | |||
| draft-savola-bcp84-urpf-experiences-01 (work in progress), | draft-savola-bcp84-urpf-experiences-01 (work in progress), | |||
| June 2006. | June 2006. | |||
| [I-D.savola-rtgwg-backbone-attacks] | [I-D.savola-rtgwg-backbone-attacks] | |||
| Savola, P., "Backbone Infrastructure Attacks and | Savola, P., "Backbone Infrastructure Attacks and | |||
| Protections", draft-savola-rtgwg-backbone-attacks-02 (work | Protections", draft-savola-rtgwg-backbone-attacks-02 (work | |||
| in progress), July 2006. | in progress), July 2006. | |||
| Appendix A. Acknowledgments | Appendix A. Protocol Specific Attacks | |||
| The editor gratefully acknowledges the contributions of: George | ||||
| Jones, who has been instrumental in providing guidance and direction | ||||
| for this document and the insighful comments from Ross Callon, Ron | ||||
| Bonica, Gaurab Upadhaya, Warren Kumari, Pekka Savola, Fernando Gont, | ||||
| Chris Morrow, Donald Smith and the numerous ISP operators who | ||||
| supplied the information which is depicted in this document. | ||||
| Appendix B. Protocol Specific Attacks | ||||
| This section will list many of the traditional protocol based attacks | This section will list many of the traditional protocol based attacks | |||
| which have been observed over the years to cause malformed packets | which have been observed over the years to cause malformed packets | |||
| and/or exploit protocol deficiencies. Note that they all exploit | and/or exploit protocol deficiencies. Note that they all exploit | |||
| vulnerabilities in the actual protocol itself and often, additional | vulnerabilities in the actual protocol itself and often, additional | |||
| authentication and auditing mechanisms are now used to detect and | authentication and auditing mechanisms are now used to detect and | |||
| mitigate the impact of these attacks. The list is not exhaustive but | mitigate the impact of these attacks. The list is not exhaustive but | |||
| is a fraction of the representation of what types of attacks are | is a fraction of the representation of what types of attacks are | |||
| possible for varying protocols. | possible for varying protocols. | |||
| B.1. Layer 2 Attacks | A.1. Layer 2 Attacks | |||
| o ARP Flooding | o ARP Flooding | |||
| B.2. IPv4 Protocol Based Attacks | A.2. IPv4 Protocol Based Attacks | |||
| o IP Addresses, either source or destination, can be spoofed which | o IP Addresses, either source or destination, can be spoofed which | |||
| in turn can circumvent established filtering rules. | in turn can circumvent established filtering rules. | |||
| o IP Source Route Option can allows attackers to establish stealth | o IP Source Route Option can allows attackers to establish stealth | |||
| TCP connections | TCP connections | |||
| o IP Record Route Option can discloses information about the | o IP Record Route Option can discloses information about the | |||
| topology of the network. | topology of the network. | |||
| skipping to change at page 37, line 8 ¶ | skipping to change at page 40, line 8 ¶ | |||
| precedence. | precedence. | |||
| o IP checksum field has been used for scanning purposes, for example | o IP checksum field has been used for scanning purposes, for example | |||
| when some firewalls did not check the checksum and allowed an | when some firewalls did not check the checksum and allowed an | |||
| attacker to differentiate when the response came from an end- | attacker to differentiate when the response came from an end- | |||
| system, and when from a firewall | system, and when from a firewall | |||
| o IP TTL field can be used to bypass certain network based intrusion | o IP TTL field can be used to bypass certain network based intrusion | |||
| detection systems and to map network behavior. | detection systems and to map network behavior. | |||
| B.2.1. Higher Layer Protocol Attacks | A.2.1. Higher Layer Protocol Attacks | |||
| The following lists additional attacks but does not explicitly | The following lists additional attacks but does not explicitly | |||
| numerate them in detail. It is for informational purposes only. | numerate them in detail. It is for informational purposes only. | |||
| o IGMP oversized packet | o IGMP oversized packet | |||
| o ICMP Source Quench | o ICMP Source Quench | |||
| o ICMP Mask Request | o ICMP Mask Request | |||
| skipping to change at page 38, line 6 ¶ | skipping to change at page 41, line 6 ¶ | |||
| o SYN with IP Spoofing (Land Attack) | o SYN with IP Spoofing (Land Attack) | |||
| o SYN and FIN bits set | o SYN and FIN bits set | |||
| o TCP port scan attack | o TCP port scan attack | |||
| o UDP spoofed broadcast echo (Fraggle Attack) | o UDP spoofed broadcast echo (Fraggle Attack) | |||
| o UDP attack on diagnostic ports (Pepsi Attack) | o UDP attack on diagnostic ports (Pepsi Attack) | |||
| B.3. IPv6 Attacks | A.3. IPv6 Attacks | |||
| Any of the above-mentioned IPv4 attacks could be used in IPv6 | Any of the above-mentioned IPv4 attacks could be used in IPv6 | |||
| networks with the exception of any fragmentation and broadcast | networks with the exception of any fragmentation and broadcast | |||
| traffic, which operate differently in IPv6. Note that all of these | traffic, which operate differently in IPv6. Note that all of these | |||
| attacks are based on either spoofing or misusing any part of the | attacks are based on either spoofing or misusing any part of the | |||
| protocol field(s). | protocol field(s). | |||
| Today, IPv6 enabled hosts are starting to be used to create IPv6 | Today, IPv6 enabled hosts are starting to be used to create IPv6 | |||
| tunnels which can effectively hide botnet and other malicious traffic | tunnels which can effectively hide botnet and other malicious traffic | |||
| if firewalls and network flow collection tools are not capable of | if firewalls and network flow collection tools are not capable of | |||
| skipping to change at page 40, line 5 ¶ | skipping to change at page 43, line 5 ¶ | |||
| Merike Kaeo | Merike Kaeo | |||
| Double Shot Security, Inc. | Double Shot Security, Inc. | |||
| 3518 Fremont Avenue North #363 | 3518 Fremont Avenue North #363 | |||
| Seattle, WA 98103 | Seattle, WA 98103 | |||
| U.S.A. | U.S.A. | |||
| Phone: +1 310 866 0165 | Phone: +1 310 866 0165 | |||
| Email: merike@doubleshotsecurity.com | Email: merike@doubleshotsecurity.com | |||
| Intellectual Property Statement | Full Copyright Statement | |||
| Copyright (C) The Internet Society (2006). | ||||
| 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 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 | The IETF takes no position regarding the validity or scope of any | |||
| Intellectual Property Rights or other rights that might be claimed to | Intellectual Property Rights or other rights that might be claimed to | |||
| pertain to the implementation or use of the technology described in | pertain to the implementation or use of the technology described in | |||
| this document or the extent to which any license under such rights | 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 | might or might not be available; nor does it represent that it has | |||
| made any independent effort to identify any such rights. Information | made any independent effort to identify any such rights. Information | |||
| on the procedures with respect to rights in RFC documents can be | on the procedures with respect to rights in RFC documents can be | |||
| found in BCP 78 and BCP 79. | found in BCP 78 and BCP 79. | |||
| skipping to change at page 40, line 29 ¶ | skipping to change at page 43, line 45 ¶ | |||
| such proprietary rights by implementers or users of this | such proprietary rights by implementers or users of this | |||
| specification can be obtained from the IETF on-line IPR repository at | specification can be obtained from the IETF on-line IPR repository at | |||
| http://www.ietf.org/ipr. | http://www.ietf.org/ipr. | |||
| The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention any | |||
| copyrights, patents or patent applications, or other proprietary | copyrights, patents or patent applications, or other proprietary | |||
| rights that may cover technology that may be required to implement | rights that may cover technology that may be required to implement | |||
| this standard. Please address the information to the IETF at | this standard. Please address the information to the IETF at | |||
| ietf-ipr@ietf.org. | ietf-ipr@ietf.org. | |||
| Disclaimer of Validity | ||||
| 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 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. | ||||
| Copyright Statement | ||||
| Copyright (C) The Internet Society (2006). 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. | ||||
| Acknowledgment | Acknowledgment | |||
| Funding for the RFC Editor function is currently provided by the | Funding for the RFC Editor function is provided by the IETF | |||
| Internet Society. | Administrative Support Activity (IASA). | |||
| End of changes. 27 change blocks. | ||||
| 72 lines changed or deleted | 117 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||