Tutorial 2 - Autonomous Systems
Submission process:
- Submission deadline is November 14, 14:00 CET (before the lecture) .
- Commit and push your solution as single notebook file via git as ./tutorial/tutorial2/tutorial2.ipynb. Please take care of the correct subfolder/filename since submission is denied otherwise.
- During the first lecture after the deadline we will discuss a sample solution in class.
- Afterwards, you have time until December 21, 14:00 CET (before the lecture) to submit a corrected version of your submission:
- Rework your solution according to our discussion in class.
- Commit and push the corrected version as single file via git as ./tutorial/tutorial2/tutorial2.ipynb. Please take care of the correct filename since submission is denied otherwise.
Remarks:
- Grading is done based on both versions of your submission.
- If the first submission is missing your submission will not be graded.
- If the second submission contains major flaws after revision not more than half of the credits for this tutorial can be achieved.
- A sample solution is provided after December 21, 14:00 CET eventually.
- Please use acn@net.in.tum.de for questions regarding lecture, tutorial, and project of ACN.
Problem 1 Autonomous Systems (10.0 credit)
Consider the following AS topology. The lines in the following graph show the AS relationships:
- A line with a single arrow symbolizes a consumer provider relationship with the arrow end marking the provider, e.g. AS 99 provides connectivity to other ASes for AS 60.
- A line with two arrows symbolizes a peering relationship with both ASes exchanging traffic for free, e.g. AS 63 and AS 60 exchange their traffic.
For this exercise, the NetworkX library is used. Execute the following cell to install the required packages.
# only needs to be executed once
!pip3 install networkx==3.4.2
Collecting networkx==3.4.2
Downloading networkx-3.4.2-py3-none-any.whl.metadata (6.3 kB) Downloading networkx-3.4.2-py3-none-any.whl (1.7 MB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 0.0/1.7 MB ? eta -:--:--
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.7/1.7 MB 38.8 MB/s eta 0:00:00
Installing collected packages: networkx
Successfully installed networkx-3.4.2
%matplotlib inline
import networkx as nx
import matplotlib.pyplot as plt
edges = [
# (src, dst, weight)
('as27', 'as15', 1),
('as92', 'as70', 1),
('as85', 'as60', 1),
('as85', 'as63', 1),
('as35', 'as63', 1),
('as70', 'as60', 1),
('as60', 'as70', 1),
('as63', 'as60', 1),
('as60', 'as63', 1),
('as92', 'as70', 1),
('as15', 'as70', 1),
('as70', 'as15', 1),
('as70', 'as20', 1),
('as60', 'as20', 1),
('as20', 'as99', 1),
('as99', 'as20', 1),
('as60', 'as99', 1),
('as63', 'as99', 1),
('as85', 'as35', 1),
('as35', 'as85', 1)
]
ases = {
# 'name':(posX, posY)
'as27':(0,0),
'as92':(20,0),
'as85':(40,0),
'as35':(60,0),
'as15':(-10,20),
'as70':(10,20),
'as60':(30,20),
'as63':(50,20),
'as20':(20,40),
'as99':(40,40)
}
def plotNetwork(graph):
# set plot size
plt.figure(3,figsize=(14,8))
# draw graph
nodz = {k:ases[k] for k in ases if k in graph.nodes()}
nx.draw_networkx_nodes(graph, pos=nodz, nodelist=nodz.keys(), node_color = 'lightblue', node_size=1500)
nx.draw_networkx_edges(graph, pos=nodz, nodelist = [], edgelist = graph.edges(), node_size=1500)
nx.draw_networkx_labels(graph, pos=nodz)
# remove axis and plot
plt.axis('off')
plt.show()
# create graph
G = nx.DiGraph()
G.add_weighted_edges_from(edges)
# draw network
plotNetwork(G)
a) [1 credits] Program a function which takes a unidirectional NetworkX graph and removes all nodes of the given or smaller degree recursively. Have a look at the function reference of NetworkX before starting the exercise. Do not use the kcore algorithm already integrated in NetworkX.
def remove_nodes_of_degree(unigraph, degree):
# begin insert code
nodelist = unigraph.nodes()
node_deleted = False
# remove nodes of 'degree'
for node in list(nodelist):
if unigraph.degree(node) <= degree:
unigraph.remove_node(node)
# uncomment following lines to see intermediate steps
#print('Removing node %s' % node)
#plotNetwork(unigraph)
node_deleted = True
# recursive call in case of node deletion
if node_deleted:
return remove_nodes_of_degree(unigraph, degree)
# end insert code
return unigraph
# convert to unidirectional graph to simplify kcore
unigraph = G.to_undirected().copy()
one_degree_graph = remove_nodes_of_degree(unigraph, 1)
# plot
print("Resulting graph:")
plotNetwork(one_degree_graph)
Resulting graph:
b) [0.5 credits] Write your own function perform_kcore() which performs the kcore algorithm on a given unidirectional NetworkX graph. The function should return a graph representing the core of the given network. You may use functions available from previous subproblems.
Have a look at the function reference of NetworkX before starting the exercise. Do not use the kcore algorithm already integrated in NetworkX.
def perform_kcore(graph):
# begin insert code
degree = 0
while graph.nodes():
graph_tmp = graph.copy() # copy original graph in case of all nodes being removed
graph = remove_nodes_of_degree(graph, degree)
if graph.nodes():
# print("Network without nodes of degree %s:" % degree)
# plotNetwork(graph)
pass
else:
# print("The network drawn above is the core of the network, the nodes have a degree of %s" % degree)
print('All nodes of the core have at least degree {}.'.format(degree))
return graph_tmp
degree = degree + 1
# end insert code
return graph
# convert to unidirectional graph to simplify kcore
unigraph2 = G.to_undirected().copy()
# plot
plotNetwork(perform_kcore(unigraph2))
All nodes of the core have at least degree 2.
c) [0.25 credits] Increase the degree of the nodes in the core of the network for the given topology. You may add exactly one connection between two arbitrary ASes
# convert to unidirectional graph to simplify kcore
unigraph2 = G.to_undirected().copy()
unigraph2.add_edge(
# e.g. :
# 'as1', 'as2'
# begin insert code
# e.g. one of the following edges increases the core
'as85', 'as70'
# 'as35', 'as70'
# 'as63', 'as70'
# 'as99', 'as35'
# end insert code
)
# plot
plotNetwork(perform_kcore(unigraph2))
All nodes of the core have at least degree 3.
For the following subproblems only the original network topology is considered. Not the extended network with the additional edge.
plotNetwork(G)
d) [1.5 credits] Define the terms “Tier-1 provider”, “stub network” and “multi-homed AS”.
Substantiate your answer by referring to an RFC.
- Tier 1 provider: "An IP transit provider that can reach any network on the Internet without purchasing transit services"[RFC 7454] for marketing purposes less restricted definitions are used by some providers to call themselves Tier 1.
- stub AS: AS having only a single connection to one other AS. Does not carry transit traffic. [RFC 1772]
- multihomed AS: AS connected to multiple transit ASes. Does not carry transit traffic. [RFC 1772]
e) [1 credits] Define the terms “peering” and “transit”.
Substantiate your answer by referring to an RFC.
f) [0.25 credits] How can a transit agreement be trivially represented in the routing table of the client?
Via default route pointing to the transit provider.
g) [2.5 credits] AS35 has been assigned the IPv6 Network 2001:db8:91::/56. Hosts in different networks want to reach a server in this network. Reason how the traffic to AS35 will be routed on AS level for sources in AS85, AS27, AS63, AS60 and AS70 considering common peering and transit agreements?
- AS85 – AS35, direct peering, cheaper for both
- AS27 can not reach AS35, since AS70 will only announce its own prefixes and AS92 prefixes to AS15.
- AS63 – AS35, AS63 can directly reach AS35 and will profit from dumping traffic
- AS60 – AS63 – AS35, AS63 will announce transit client on peering, AS60 and AS63 don’t need to utilize transit with upstream
- AS70 – AS20 – AS99 – AS63 – AS35, AS60 will not announce prefixes of AS35 (learned from AS63) over the peering to AS70, since it would not gain money from this transit traffic through its own network.
For the following subproblems, assume that all ASes apply the following policies ordered by their priority:
- Accept and use the more specifc announcement
- Accept and use the shorter path
- Accept and use announcements with a better economical value (generates money or is free to use)
h) [0.5 credits] Explain what happens when AS60 announces the prefix 2001:db8:91::/57. How does this impact other ASes?
AS60 announces the prefix to its neighbors. The announcement is accepted by all neighbors because a more specifc prefix is announced. This case is covered by the first policy. Therefore, traffic to this prefix is routed towards AS60 instead of AS35.
i) [1 credits] Explain what happens when AS60 announces the prefix 2001:db8:91::/56 instead. How does this impact other ASes?
AS60 announces the prefix to its neighbors. The announcement is only accepted by some neighbors. This time, the first policy does not apply. Thus each AS has to decide based on the later policies.
AS99, AS20, AS70 and thus AS92 receive routes with shorter paths. Therefore, they accept the announcement and route traffic towards AS60.
For AS63 and AS85 the path towards AS60 and the original AS35 have the same length. Therefore, they need to consider the third policy. AS63 would not accept the new announcement because AS35 is a customer generating money. AS85 would also not accept the route because it has a peering agreement with AS35 but AS60 is a provider.
j) [0.5 credits] Shortly explain why neither the h) nor i) fully hijacks the prefix 2001:db8:91::/56 of AS35 with the given policies. How can h) be addapted to hijack the prefix?
The approach used in i) is not accpeted throughout the complete network. Therefore, some traffic towards the prefix still reaches AS35.
The approac used in h) only hijacks a subprefix. Traffic towards 2001:db8:91:80::/57 still reaches AS35. To hijack the prefix with the given policies AS60 could announce 2001:db8:91:80::/57 and 2001:db8:91::/57 to cover 2001:db8:91::/56 completely.
k) [1 credits] Find and shortly explain at least one solutions that tries to prevent some sorts of BGP hijacking.
There is currently no final conclusive answer on how to completely prevent BGP hijacking. The most deployed and discussed mechanisms are the following:
- IRR filtering [5]
- Internet Routing Registries are central places where routing information is published. They document which ASNs are allowed to announce which IP addresses and what the policies are for exchanging routes between ASNs. This information can be used in router configurations to validate the received routes.
- Based on this data AS operators can validate BGP announcements
- Route Origin Validation via resource public key infrastructure (ROV - RPKI)
- ROV - RPKI is built on signatures of prefix announcements from the owning AS (route origin announcement - ROA [3]). This also includes the valid origins for the prefix.
- These ROAs are distributed by the RIRs (e.g. RIPE [2])
- The RIRs are also the trust anchor of the RPKI [4].
- ROV can not protect from path hijacks. It can only validate the origin of an prefix announcement
- Or like MANRS [1] puts it:
- ROV - RPKI is built on signatures of prefix announcements from the owning AS (route origin announcement - ROA [3]). This also includes the valid origins for the prefix.
A network operator registers their announcements in the form of ROAs and they are subsequently used by operators to either generate filters (pseudo-IRR) or to tag/validate announcements using more advanced techniques like the RPKI-to-router protocol.
- Use an internal database with the information provided as part of the provisioning process [1]
- Provides a defense especially from and for customer AS hijacks
Mutually Agreed Norms for Routing Security (MANRS) [1] is a global initiative to improve routing security. It provides several guidelines on how to improve the security of the routing setup at AS owners.
[1] https://www.manrs.org/about/
[2] https://www.ripe.net/manage-ips-and-asns/resource-management/rpki
[3] https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/resource-certification-roa-management
[4] https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/ripe-ncc-rpki-trust-anchor-structure
[5] http://www.irr.net/
Advanced Computer Networking by Prof. Dr.-Ing. Georg Carle
Teaching assistants: Christian Dietze, Sebastian Gallenmüller, Max Helm, Benedikt Jaeger, Marcel Kempf, Jihye Kim, Patrick Sattler