This Master's thesis deals with modeling and simulation of BGP protocol within the OMNeT++ environment. The BGP protocol is described with employed data structures and the finite state machine of BGP peering. Next, the basic configuration is outlined involving the setup of the BGP protocol on Cisco devices. Further, BGP for OMNeT++ state-of-the-art is investigated together with its lack of functionality and issues. The second part of this thesis deals with design, implementation, and testing of the new functionality of BGP protocol and simulation models. The last section describes the overall achieved results.

This master's work deals with the design of laboratory exercises for Cisco Academy courses. Especially is oriented on Cisco technology. The theoretical part describes various devices used in the laboratory and the issue of functionality of these devices, such as switching, routing and solve any problems with the configurations of these elements. The practical part is directly generated designs laboratory exercises, focusing on specific examples of the problems from the configuration and network management with Cisco. An integral part of work consists of supporting the presentation of individual laboratory tasks, including configuration files, settings of the device. Create labs and verify the functionality of their configuration has been realized in the laboratory Cisco Academy Brno.

Routing hijacks have plagued the Internet for decades. These attacks corrupt the routing table entries that networks use to forward traffic, causing affected network devices to route private and possibly sensitive Internet traffic towards the hijacker. Despite many failed attempts to thwart hijackers, recent Internet-wide routing monitoring infrastructures give us hope that future systems can quickly and ultimately mitigate hijacks. Such monitoring infrastructures consist of multiple globally distributed monitoring entities, called Route Collectors. To enable the whole community to monitor the validity and stability of the exchanged routing information, network volunteers disclose their routes to public route collectors. However, hijackers can also exploit this information to avoid being reported to route collectors. This thesis evaluates the effectiveness of monitoring infrastructures against two kinds of hijack scenarios: (i) an omniscient attacker with complete knowledge of both the Internet topology and the routing preferences of networks, and (ii) a realistic attacker which lacks such knowledge but gathers routing information from what networks themselves disclose to the public route collectors. Prior simulations showed that hijacks that affect more than 2% of the Internet are always visible to the public route collector infrastructure. However, our simulations show that omniscient and realistic hijackers that react to the deployment of public collectors could stealthily hijack up to 11.7× more (i.e., 23.5%) and 8.1× (i.e., 16.2%) more of the Internet (respectively) without being observed by the existing public route collector infrastructure. Having evaluated the effectiveness of the existing public route collector infrastructure with current Internet datasets, we evaluated the effectiveness in realistic future scenarios of (i) more interconnected (flatter) Internet topologies as well as (ii) topologies where more network volunteers disclose their routes to the public collectors. Unfortunately, both types of hijackers are more effective in flatter Internet topologies. Omniscient hijackers could stealthily hijack up to 24.5× (i.e., 49.0%) more of the Internet while realistic hijackers up to 22.7× (i.e., 45.5%) more without being observed by route collectors. In topologies with up to 4× more volunteers disclosing their routes to the public route collectors, hijackers could react to these new monitors by modifying their attacks to stealthily hijack up to 4× (i.e., 8.2%) and 2.9× (i.e., 5.9%) more of the Internet (respectively). Finally, we conclude with an analysis of two suggestions for improving the existing public route collector infrastructure: (i) selecting new network volunteers in more strategic locations and (ii) having volunteers disclose more routes to the route collectors. We hope that our findings in simulations will help towards the design of more reliable public route monitoring infrastructures. / Ruttkapningar har plågat internet i årtionden. Dessa attacker korrumperar poster i routingtabeller som används av nätverket för att vidarebefordra trafik, på ett sådant sätt att påverkade enheter dirigerar privat och tänkbart känslig trafik till kaparen. Trots många misslyckade försök att hindra kapare, ger på senare tid internetbred ruttövervakningsinfrastruktur oss förhoppningen att framtida system snabbt och slutgiltigt kan förhindra kapningar. Sådan övervakningsinfrastruktur består av flera globalt distribuerade övervakningsenheter kallade ruttinsamlare. Nätverksvolontärer uppger sina rutter till sådana publika ruttinsamlare så att hela nätverket kan övervaka validiteten och stabiliteten av den utbytta ruttinformationen. Dessvärre kan kapare utnyttja denna information för att undvika att bli rapporterade till ruttinsamlare. I denna avhandling utvärderar vi effektiviteten av sådan övervakningsinfrastruktur mot två typer av kapnings scenarier: Det första innefattar en allvetande attackerare med fullständig vetskap om både internettopologin och ruttpreferenser i nätverken. Det andra innefattar en realistisk attackerare som saknar sådan kunskap men som samlar upp den ruttinformation som nätverken själva lämnar ut till publika ruttinsamlare. Tidigare simuleringar har visat att kapningar som påverkar mer än 2% av internet alltid är synliga för den publika ruttinsamlarinfrastrukturen. Vår simulering visar däremot att allvetande och realistiska kapare som reagerar på utplaceringen av publika ruttinsamlare i smyg kan kapa upp till 11.7 gånger (d.v.s. 23.5%) respektive 8.1 gånger (d.v.s. 16.2%) mer av internet, utan att upptäckas av den existerande publika ruttinsamlarinfrastrukturen. Efter att ha utvärderat effektiviteten i den existerande publika infrastrukturen med nuvarande internet datamängder, utvärderade vi effektiviteten i realistiska framtida scenarier av för det första fler sammanlänkad (plattare) internet topologier samt för det andra topologier där fler nätverksvolontärer uppger sina rutter till publika ruttinsamlare. Dessvärre är båda typer av kapare mer effektiva i plattare internet topologier. Allvetande kapare kunde i smyg kapa upp till 24.5 gånger (d.v.s. 49.0%) mer av internet, medan realistiska kapare kunde kapa upp till 22.7 gånger (d.v.s. 45.5%) mer av internet, utan att upptäckas av ruttinsamlare. I topologier med upp till 4 gånger fler nätverksvolontärer som uppger sina rutter till publika ruttinsamlare, kunde allvetande och realistiska kapare reagerar på nya övervakare genom att modifiera sina attacker till att i smyg kapa upp till 4 gånger (d.v.s. 8.2%) respektive 2.9 gånger (d.v.s. 5.9%) mer av internet. Slutligen sammanfattar vi med en analys av två förslag till förbättring av den existerande ruttinsamlarinfrastrukturen: I det första väljes nya nätverksvolontärer på mer strategiska platser och i det andra låter vi nätverksvolontärer uppge fler rutter till ruttinsamlare. Vi hoppas att våra simuleringsresultat kan bidra till en design av en mer pålitlig publik rutt övervakningsinfrastruktur. / <p>QC 20220524</p>

Since its commercialization, the Internet has grown exponentially. A large variety of devices can communicate creating advanced services for a diverse ecosystem of applications. However, as the number of Internet hosts has grown, the size of routing tables required to correctly route data between them has also increased exponentially. This growth rate necessitates increasingly frequent upgrades to routing device hardware, providing them with additional memory for fast-access storage of route information. These upgrades are both physically and fiscally untenable, and a new Internet routing solution is necessary for future growth. This research focuses around an incrementally deployable, reactive routing system that is scalable to projected Internet growth. It requires no hardware or software updates to Internet routers, and offoads processing to end hosts and the network's edge. Within this framework, routers can make accurate decisions about optimal data paths; incurring no increase in path length over the current routing system. A new architecture for IP Mobility is considered as a case study within this routing system, and compared with existing standards and implementations. The new architecture eliminates the triangle routing problem, while providing legacy hosts with connectivity to mobile devices. This mobility solution can integrate with a variety of hierarchical reactive routing systems with little overhead.

Major cloud service providers have become increasingly popular as the traditional way of storing data locally is turning more and more obsolete. Plenty of large companies have turned to cloud storage which have created business opportunities for the cloud service providers. The cloud service providers have to adapt the availability of their services as well as the security in relationship with the increasing demand of their services. With the growth of these providers, their increased presence in the global internet traffic is a fact as they establish more autonomous systems to increase their availability within the internet topology. This study is based on a couple of these cloud service providers such as Google Cloud, AWS and Microsoft Azure and their growth as well as how they route their data with the BGP protocol in general. A topology was created of how these providers have increased their presence on the internet to see how much of the traffic that goes through their autonomous systems today compared to what it looked like nearly 20 years ago. We have also performed a series of remote traceroutes from different locations around the world and compared the announced path from the BGP protocol to the route that the data actually takes for the same route. It is concluded that the tracerouted path is not always the same as the BGP path, and the reason for that is most likely a companies own routing policy that disrupts the announced path in one way or another.

The BGP (Border Gateway Protocol) is responsible for establishing routing at the core of the Internet, yet it was not designed with security in mind. The Internet routing protocol is currently not secure — but its security can be enhanced. Initially conceived as a small community of trusted peers, the Internet has grown over time into a robust network of complex processes and securing these has become a priority. Thanks to the research community, the RPKI (Resource Public Key Infrastructure) protocol was designed to provide a layer of security to routing — by securing the origin, i.e., attesting that the source of the routing announcements is authorized to do so. As RPKI route validation has been recently widely adopted by multiple large carrier networks, many research projects have sought to measure the adoption of RPKI. This work aims to measure the adoption and the effects of RPKI route validation and filtering through the use of active experiments. A peering session was first established with one of the largest Tier-1 ISP: Arelion (formerly known as Telia Carrier) to announce and propagate a prefix with RPKI Valid, Invalid, and Unknown records. Then, the visibility of the prefix (in the control plane) and reachability of the prefix (in the data plane) was measured using visibility feeds from public BGP Route Collectors and reachability feeds from RIPE Atlas probes. The obtained results confirmed that some, but not all previously believed major networks, drop RPKI Invalid prefixes, affecting the destination network’s visibility. For networks that could still reach the destination, the data plane probes demonstrated that parameters such as the RTT and the hop count were not generally affected. A small increase in the destination network visibility was observed when comparing RPKI Valid with Unknown routes. All RPKI Valid Invalid and Unknown effects and their behavior are deeply analyzed. Data sets have been made publicly available for other researchers to analyze the data, and ensure the future of a more secure Internet. / BGP (Border Gateway Protocol) används för att sprida routinginformation mellan routrar i de tusentals nätverk som tillsammans bildar Internet, men det utformades inte med säkerhet i åtanke. Protokollet är i grunden inte säkert - men det kan bli det. Det som ursprungligen var en liten grupp sammanlänkade universitetsnätverk växte med tiden till att bli Internet, ett robust globalt nätverk med komplexa processer för utbyte av routinginformation. I ett modernt samhälle där vi kommit till att förlita oss på dess existens och funktion så har det blivit en prioritet att säkra dessa. Tack vare initiativ tagna i forsknings- och utvecklingsgruppen IETF (Internet Engineering Taskforce) utformades RPKI (Resource Public Key Infrastructure) för att tillhandahålla ett säkerhetslager för routing – genom att säkra ursprunget till routinginformation. Eftersom RPKI-validering nyligen har anammats av flera stora operatörsnätverk, har många forskningsprojekt försökt mäta användningen av RPKI. Detta arbete syftar till att mäta användningen och effekterna av RPKI-validering och filtrering genom användning av aktiva experiment. En BGP peering-session etablerades först med en av de större Tier-1 ISP: Arelion (tidigare känd som Telia Carrier) för att originera och sprida ett IP prefix med RPKI Valid, Invalid och Unknown poster. Sedan mättes prefixets synlighet (i kontrollplanet) och prefixets nåbarhet (i dataplanet) med hjälp av synlighetsflöden från offentliga BGP Route Collectors och nåbarhetsflöden från RIPE Atlas-prober. De erhållna resultaten bekräftade att vissa, men inte alla, stora nätverk blockerar RPKI Invalid prefix, vilket påverkar dess synlighet och nåbarhet. För nätverk som fortfarande kunde nå destinationen visade dataplanssonderna att parametrar som RTT och hoppantal inte påverkades generellt. En liten ökning av destinationsnätverkets synlighet observerades vid jämförelse av RPKI Valid med Unknown rötter. Alla RPKI Valid Invalid och Unknown effekter och deras beteende analyseras djupt. Datauppsättningar har gjorts offentligt tillgängliga för andra forskare för att analysera data och säkerställa framtiden för ett säkrare Internet.

The Domain Name System (DNS) provides a mapping between host names and Internet Protocol (IP) addresses. Hosts that are configured using the Dynamic Host Configuration Protocol (DHCP) can have their assigned IP addresses updated in a Dynamic DNS (DDNS). DNS and DDNS are critical components of the Internet. Most applications use host names rather than IP addresses, allowing the underlying operating system (OS) to translate these host names to IP addresses on behalf of the application. When the DDNS service is unavailable, applications that use DNS cannot contact the hosts served by that DDNS server. Unfortunately, the current DDNS implementation cannot continue to operate under failure of a master DNS server. Although a slave DNS server can continue to translate names to addresses, new IP addresses or changes to existing IP addresses cannot be added. Therefore, those new hosts cannot be reached by the DDNS. A new architecture is presented that eliminates this single point of failure. In this design, instead of storing resource records in a flat text file, all name servers connect to a Lightweight Directory Access Protocol (LDAP) directory to store and retrieve resource records. These directory servers replicate all resource records across each other using a multi-master replication mechanism. The DHCP servers can add records to any of the functioning DNS servers in event of an outage. In this scheme, all DNS servers use the anycast Border Gateway Protocol (BGP). This allows any of the DNS servers to answer queries sent to a single IP address. The DNS clients always use the same IP address to send queries. The routing system removes routes to non-functional name servers and delivers the request to the closest (according to network metrics) available DNS server. This thesis also describes a concrete implementation of this system that was created to demonstrate the viability of this solution. A reference implementation was built in a laboratory to represent an Internet Service Provider (ISP) with three identical regions. This implementation was built using Quagga as the BGP routing software running on a set of core routers and on each of the DNS servers. The Berkeley Internet Name Daemon (BIND) was used as an implementation of the DNS. The BIND Simplified Database Backend (SDB) interface was used to allow the DNS server to store and retrieve resource records in an LDAP directory. The Fedora Directory Server was used as a multi-master LDAP directory. DHCP service was provided by the Internet Systems Consortium's (ISC) DHCP server. The objectives for the design were high-availability, scalability and consistency. These properties were analyzed using the metrics of downtime during failover, replication overhead, and latency of replication. The downtime during failover was less than one second. The precision of this metric was limited by the synchronization provided by the Network Time Protocol (NTP) implementation used in the laboratory. The network traffic overhead for a three-way replication was shown to be only 3.5 times non-replicated network traffic. The latency of replication was also shown to be less than one second. The results show the viability of this approach and indicate that this solution should be usable over a wide area network, serving a large number of clients. / Master of Science

Economic incentives and the need to efficiently deliver Internet have led to the growth of Internet eXchange Points (IXPs), i.e., the interconnection networks through which a multitude of possibly competing network entities connect to each other with the goal of exchanging traffic. At IXPs, the exchange of traffic between two or more member networks is dictated by the Border gateway Protocol (BGP), i.e., the inter-domain routing protocol used by network operators to exchange reachability information about IP prefix destinations. There is a common “honest-closed-world” assumption at IXPs that two IXP members exchange data traffic only if they have exchanged the corresponding reachability information via BGP. This state of affairs severely hinders security as any IXP member can send traffic to another member without having received a route from that member. Filtering traffic according to BGP routes would solve the problem. However, IXP members can install filters but the number of filtering rules required at a large IXP can easily exceed the capacity of the network devices. In addition, an IXP cannot filter this type of traffic as the exchanged BGP routes between two members are not visible to the IXP itself. In this thesis, we evaluated the design space between reactive and proactive approaches for guaranteeing consistency between the BGP control-plane and the data-plane. In a reactive approach, an IXP member operator monitors, collects, and analyzes the incoming traffic to detect if any illegitimate traffic exists whereas, in a proactive approach, an operator configures its network devices to filter any illegitimate traffic without the need to perform any monitoring. We focused on proactive approaches because of the increased security of the IXP network and its inherent simplified network management. We designed and implemented a solution to this problem by leveraging the emerging Software Defined Networking (SDN) paradigm, which enables the programmability of the forwarding tables by separating the controland dataplanes. Our approach only installs rules in the data-plane that allow legitimate traffic to be forwarded, dropping anything else. As hardware switches have high performance but low memory space, we decided to make also use of software switches. A “heavy-hitter” module detects the forwarding rules carrying most of the traffic and installs them into the hardware switch. The remaining forwarding rules are installed into the software switches.We evaluated the prototype in an emulated testbed using the Mininet virtualnetwork environment. We analyzed the security of our system with the help of static verification tests, which confirmed compliance with security policies. The results reveal that with even just 10% of the rules installed in the hardware switch, the hardware switch directly filter 95% of the traffic volume with nonuniform Internet-like traffic distribution workloads. We also evaluated the latency and throughput overheads of the system, though the results are limited by the accuracy of the emulated environment. The scalability experiments show that, with 10K forwarding rules, the system takes around 40 seconds to install and update the data plane. This is due to inherent slowness of emulated environment and limitations of the POX controller, which is coded in Python. / Ekonomiska incitament och behovet av att effektivt leverera Internet har lett till tillväxten av Internet eXchange Points (IXP), dvs de sammankopplingsnät genom vilka en mängd möjligen konkurrerande nätverksenheter förbinder varandra med målet att utbyta trafik. Vid IXPs dikteras utbytet av trafik mellan två eller flera medlemsnät av gränsgatewayprotokollet (BGP), dvs det inter-domänroutingprotokollet som används av nätoperatörer för att utbyta tillgänglighetsinformation om IP-prefixdestinationer. Det finns ett gemensamt antagande om "honest-closed-world" vid IXP, att två IXP-medlemmar endast utbyter datatrafik om de har bytt ut motsvarande tillgänglighetsinformation via BGP. Detta tillstånd försvårar allvarligt säkerheten eftersom varje IXP-medlem kan skicka trafik till en annan medlem utan att ha mottagit en rutt från den medlemmen. Filtrering av trafik enligt BGP-vägar skulle lösa problemet. IXPmedlemmar kan dock installera filter men antalet filtreringsregler som krävs vid en stor IXP kan enkelt överskrida nätverksenheternas kapacitet. Dessutom kan en IXP inte filtrera denna typ av trafik eftersom de utbytta BGP-vägarna mellan två medlemmar inte är synliga för IXP-enheten själv.I denna avhandling utvärderade vi utrymmet mellan reaktiva och proaktiva metoder för att garantera överensstämmelse mellan BGP-kontrollplanet och dataplanet. I ett reaktivt tillvägagångssätt övervakar, samlar och analyserar en inkommande trafik en IXP-medlem för att upptäcka om någon obehörig trafik finns, medan en operatör konfigurerar sina nätverksenheter för att filtrera någon obehörig trafik utan att behöva övervaka . Vi fokuserade på proaktiva tillvägagångssätt på grund av den ökade säkerheten för IXP-nätverket och dess inneboende förenklad nätverkshantering. Vi konstruerade och genomförde en lösning på detta problem genom att utnyttja det nya SDN-paradigmet (Software Defined Networking), vilket möjliggör programmerbarheten hos vidarebefordringsborden genom att separera kontrolloch dataplanerna. Vårt tillvägagångssätt installerar bara regler i dataplanet som tillåter legitim trafik att vidarebefordras, släppa allt annat. Eftersom hårdvaruomkopplare har hög prestanda men lågt minne, bestämde vi oss för att även använda programvaruomkopplare. En "heavy-hitter" -modul detekterar vidarebefordringsreglerna som transporterar större delen av trafiken och installerar dem i hårdvaruomkopplaren. De återstående spolningsreglerna installeras i programvaruomkopplarna.Vi utvärderade prototypen i en emulerad testbädd med hjälp av virtuella nätverksmiljö Mininet. Vi analyserade säkerheten för vårt system med hjälp av statiska verifieringsprov, vilket bekräftade överensstämmelse med säkerhetspolicyerna. Resultaten visar att med bara 10% av de regler som installerats i hårdvaruomkopplaren filtrerar hårdvaruomkopplaren direkt 95% av trafikvolymen med ojämn Internetliknande trafikfördelningsarbete. Vi utvärderade också latensoch genomströmningsomkostnaderna för systemet, även om resultaten begränsas av noggrannheten hos den emulerade miljön. Skalbarhetsexperimenten visar att med 10K-vidarebefordringsregler tar systemet cirka 40 sekunder för att installera och uppdatera dataplanet. Detta beror på inneboende långsamma emulerade miljöer och begränsningar av POX-kontrollern, som kodas i Python.

A Internet pode não atender às necessidades exigidas por aplicações sensíveis a atraso tais como voz, video ou até jogos em redes. A distância de saltos entre o cliente e o servidor, o congestionamento dos links e a aleatoriedade do caminho do pacote, podem causar atrasos. Existem motivações e até implementações de infra-estruturas alternativas para atender necessidades não garantidas pela Internet. Um exemplo é o projeto Rede COMEP, que propõe uma rede alternativa a fim de diminuir a distância e aumentar a capacidade entre os usuários (alunos e professores) e o conteúdo. Esta tese propõe uma infra-estrutura de rede de alta velocidade, exclusiva para aplicações sensíveis a atraso. A rede, denominada de IXnet, origina-se de experimentos de roteamento compartilhado por meio do IXP, estudo do tráfego de uma aplicação sensível a atraso e uso de simulador de rede. O uso da IXnet pode ampliar a frente de negócios para as operadoras e usuários que fazem uso de aplicações sensíveis a atraso, melhorando a qualidade na prestação de seus serviços. / The Internet may does not meet all the demands required by applications sensitive to delay. Voice, video or even game applications demand low delay. The distance of hops between client and server, link traffic and the ramdomness of the package path, may cause delays. There is motivation and even implementation of alternative infra-structure to improve access. One example is the COMEP Network project, that proposes an alternative network in order to comply with the specific demands of such applications. This thesis proposes a high speed infra-structure network, exclusive for delay sensitive applications. This network, named IXnet, has it\'s origins in experiments with shared routing IXP, traffic studies of a sensitive to delay application and use of network simulator. The use of IXnet may increase the business front for operators and users that utilize sensitive to delay applications, improving the quality of the services provided.

A Internet pode não atender às necessidades exigidas por aplicações sensíveis a atraso tais como voz, video ou até jogos em redes. A distância de saltos entre o cliente e o servidor, o congestionamento dos links e a aleatoriedade do caminho do pacote, podem causar atrasos. Existem motivações e até implementações de infra-estruturas alternativas para atender necessidades não garantidas pela Internet. Um exemplo é o projeto Rede COMEP, que propõe uma rede alternativa a fim de diminuir a distância e aumentar a capacidade entre os usuários (alunos e professores) e o conteúdo. Esta tese propõe uma infra-estrutura de rede de alta velocidade, exclusiva para aplicações sensíveis a atraso. A rede, denominada de IXnet, origina-se de experimentos de roteamento compartilhado por meio do IXP, estudo do tráfego de uma aplicação sensível a atraso e uso de simulador de rede. O uso da IXnet pode ampliar a frente de negócios para as operadoras e usuários que fazem uso de aplicações sensíveis a atraso, melhorando a qualidade na prestação de seus serviços. / The Internet may does not meet all the demands required by applications sensitive to delay. Voice, video or even game applications demand low delay. The distance of hops between client and server, link traffic and the ramdomness of the package path, may cause delays. There is motivation and even implementation of alternative infra-structure to improve access. One example is the COMEP Network project, that proposes an alternative network in order to comply with the specific demands of such applications. This thesis proposes a high speed infra-structure network, exclusive for delay sensitive applications. This network, named IXnet, has it\'s origins in experiments with shared routing IXP, traffic studies of a sensitive to delay application and use of network simulator. The use of IXnet may increase the business front for operators and users that utilize sensitive to delay applications, improving the quality of the services provided.