MANRS http://isoc.sd/ en Global Validation and RPKI Local situation in Sudan http://isoc.sd/node/18 <span class="field field--name-title field--type-string field--label-hidden">Global Validation and RPKI Local situation in Sudan</span> <span class="field field--name-uid field--type-entity-reference field--label-hidden"><span lang="" about="/user/1" typeof="schema:Person" property="schema:name" datatype="">sisman</span></span> <span class="field field--name-created field--type-created field--label-hidden">Mon, 06/01/2020 - 23:13</span> <div class="layout layout--onecol"> <div class="layout__region layout__region--content"> <div class="clearfix text-formatted field field--name-body field--type-text-with-summary field--label-hidden field__item"><p><strong>Abdelbasit Ali<br /> 01/06/2020</strong></p> <p>Insecure routing is one of the most common paths for malicious threats. Attacks can take anywhere from<br /> hours to months to recognize. Inadvertent errors can take entire countries offline, while attackers can steal<br /> an individual’s data or hold an organization’s network hostage.<br /> The routing system of the Internet is vulnerable to many security threats such as: Prefix Hijacks, Route Leaks,<br /> and IP Address Spoofing.</p> <p><br /> <strong>MANRS:</strong></p> <p><br /> MANRS (Mutually Agreed Norms for Routing Security) is a global initiative to implement crucial fixes needed<br /> to eliminate the most common routing threats. MANARS address these security threats through technical and<br /> collaborative actions from many players across the Internet and defines four concrete actions that network<br /> operators should implement. They are a technology‐neutral baseline so that they can globally adopted.<br /> ‐ Global Validation:<br /> In order to facilitate validation of routing information on a global scale, network operators must<br /> publish their routing information so that other parties can validate it.</p> <p><strong>‐ Filtering:</strong></p> <p><br /> In order to prevent propagation of incorrect routing information, network operators must ensure the<br /> correctness of their own announcements, and announcements from their customers to adjacent<br /> networks with prefix and AS‐path granularity.</p> <p><br /> ‐ Anti‐Spoofing:</p> <p><br /> In order to prevent traffic with spoofed source IP addresses, network operators must enable source<br /> address validation for at least single‐homed stub customer networks, their own end‐users, and<br /> infrastructure.</p> <p><br /> ‐ Coordination:</p> <p><br /> In order to facilitate global operational communication and coordination between network operators,<br /> they must maintain globally accessible and up‐to‐date contact information.<br /> Global Validation:<br /> In order to validate routing announcements on a global scale, your organization’s Network Routing Policy<br /> should be made available to other networks, to enable others to validate route announcements originating<br /> from your network by documenting a Network Routing Policy.<br /> Since any network that participates in BGP (Border Gateway Protocol) routing could require this information,<br /> it needs to be published to a well‐known place using a standard format.<br /> This includes the announcements that the network originates as well as the routing policy describing how<br /> reachability information exchanged with other networks is handled. That specifically covers routes that are:<br /> Announced to other networks.</p> <p>Why is Validation Routing Information Important?<br /> ASes communicate routing information using BGP; BGP lacks mechanisms to authenticate allocation of IP<br /> prefixes which can be exploited by a bad actor to carry out an attack using BGP Hijacking. BGP is mostly relying<br /> on trust. This contributes to various incidents due to operator errors, like the one that affected Cloudflare, or<br /> to malicious attackers, like the hijack of Amazon DNS.</p> <p><strong>What is BGP Hijacking?</strong><br /> BGP hijacking is when an attacker disguises itself as another network; it announces network prefixes belonging<br /> to another network as if those prefixes are theirs. If this false information is accepted by neighboring networks<br /> and propagated further using BGP, it distorts the “roadmap” of the Internet. As a result, traffic is forwarded<br /> to the attacker instead of its legitimate destination. Like Insecure routing redirects YouTube to Pakistan.<br /> Documentation of Expected Announcements:<br /> In order to facilitate Origin Validation, MANRS participants are required to publish their Network Routing<br /> Policy and other associated routing information to an IRR database and RPKI repository.<br /> Now we will look at how to do this:<br /> 1. Register their Network Routing Policy (aut‐num object), and their expected announcements (route<br /> object).<br /> 2. Document their customer cone (as‐set object).<br /> 3. Ensure their customers register their expected announcements (route object).<br /> 4. Register their expected announcements (ROA object) to an RPKI repository and ensure their<br /> customers do the same.</p> <p><strong>IRR database:</strong><br /> IRR stands for Internet Routing Registry and is a public database of Internet route objects. IRRs are used for<br /> determining and sharing route and other related information used for configuring routers. If RIR (Regional<br /> Internet Registry) in your region operates an Internet Routing Registry (IRR), you should use it to document<br /> your network Routing Policy and related route announcements, using RPSL (Routing Policy Specification<br /> Language). Information related to an Internet resource or supporting functions, are contained within RPSL<br /> objects, and stored in an IRR. Some of these objects include: AUT‐NUM, ROUTE/ROUTE6, and AS‐SET<br /> AUT‐NUM:<br /> aut‐num autonomous system number object, which will be used to tag each prefix for which Autonomous<br /> System it comes from, and specifies what sets of prefixes are exported from this AS to any of its peers.<br /> ROUTE/ROUTE6:<br /> route/route6 object is used to document which address prefix an ASN is allowed to announce. You will need<br /> to create one for each exact address prefix and AS that you want to see in the routing table.<br /> AS‐SET:<br /> as‐set object is used to document which ASes your customers own and is known as your customer cone.</p> <p><strong>RPKI repository:</strong></p> <p><br /> The global routing system of the Internet consists of a number of functionally independent actors<br /> (Autonomous Systems) which use BGP to exchange routing information. The system is very dynamic and<br /> flexible by design. Connectivity and routing topologies are subject to change. Changes easily propagate<br /> globally within a few minutes. One weakness of this system is that these changes cannot be validated against<br /> information existing outside of the BGP protocol itself.</p> <p><br /> RPKI (Resource Public Key Infrastructure) is a way to define data in an out‐of‐band system such that the<br /> information that are exchanged by BGP can be validated to be correct. The RPKI standards were developed by<br /> the IETF (Internet Engineering Task Force) to describe some of the resources of the Internet’s routing and<br /> addressing scheme in a cryptographic system. These information are public, and anyone can get access to<br /> validate their integrity using cryptographic methods.</p> <p>RPKI is used to let the legitimate holder of a block of IP addresses make an authoritative statement about<br /> which AS is authorized to originate their prefix in the BGP. In turn, other network operators can download and<br /> validate these statements and make routing decisions based on them.</p> <p><strong>Why is RPKI Important?</strong></p> <p><br /> The main weakness of the IRR is that it is not a globally deployed system and it lacks the authorization model<br /> to make the system water tight. The result is that out of all the information on routing intent that is published,<br /> it is difficult to determine what legitimate, authentic data is and what isn’t. RPKI solves these two problems,<br /> as you can be absolutely sure that an authoritative, cryptographically verifiable statement can be made by any<br /> legitimate IP resource holder in the world.<br /> So in addition to providing information to the IRR system, you also need to document your network’s expected<br /> announcements which will be stored within a ROA object on an RPKI repository.</p> <p><br /> <strong>What is a ROA?</strong></p> <p><br /> ROA (Route Origin Authorization) objects are an attestation of a BGP route announcement. It cryptographically<br /> signed objects that state which prefixes (not the full path) an AS is authorized to originate. The attestation can<br /> be verified cryptographically using RPKI.<br /> Global Validation and RPKI situation on Sudan:<br /> To measure MANRS readiness for a particular network a set of metrics has been proposed, one for each action,<br /> by MANRS Observatory to provide a factual state of security and resilience of the Internet routing system and<br /> track it over time.<br /> MANRS readiness indicates the level a network implements MANRS Actions. MANRS readiness index is<br /> measured per Action using the MANRS Measurement Framework.</p> <p><strong>Facilitate Global Validation Metrics are:</strong></p> <p><br /> <strong>M7IRR (Not registered routes):</strong></p> <p><br /> Calculates the percentage of routes originated by the AS that are not registered in an IRR as route objects.<br /> More specific routes that are advertised and covered by a less specific route object are also considered<br /> registered.</p> <p><br /> <strong>M7RPKI (Not registered ROAs):</strong></p> <p><br /> Calculates the percentage of the routes originated by the AS that are not covered by any ROA in RPKI.<br /> <strong>M7RPKIN</strong> (Invalid routes):<br /> Calculates the percentage of the routes originated by the AS that are invalidated by a corresponding ROA.<br /> Situation in Sudan based on this Measurement Framework, M7IRR reference 98%, M7RPKIN reference 100%,<br /> and<strong> M7RPKI</strong> reference 0%.<br /> The level a networks implements Global Validation and RPKI Actions in Sudan are:<br /> ‐ Global Validation IRR database readiness indicates the level a networks facilitates validation of routing<br /> information, by maintaining it in the IRR, is 85.71% Ready and 14.29% Aspiring.<br /> ‐ Global Validation RPKI repository readiness indicates the level a networks facilitates validation of<br /> routing information, by maintaining it in the RPKI, is 100% Lagging.</p></div> <div class="field field--name-field-tags field--type-entity-reference field--label-above"> <div class="field__label">Tags</div> <div class="field__items"> <div class="field__item"><a href="/taxonomy/term/17" hreflang="en">RPKI</a></div> </div> </div> <div class="field field--name-field-category field--type-entity-reference field--label-above"> <div class="field__label">Category</div> <div class="field__item"><a href="/taxonomy/term/4" hreflang="en">MANRS</a></div> </div> </div> </div> Mon, 01 Jun 2020 23:13:16 +0000 sisman 18 at http://isoc.sd