RPKI first pass

Author: drbruced12

figures/SecurityFigs.odp

@@ -30,8 +30,8 @@ make them more resistant to attacks as we discuss in the following
 sections.
 
 
-8.1 BGP
-----------
+8.1 BGP and Routing Security
+----------------------------
 
 In most respects, a router is just a special-purpose computer with
 some high-speed interfaces and specialized software to perform tasks
@@ -184,7 +184,170 @@ announcements. This quest, and the slowness of its progress, was well
 documented by Sharon Goldberg in 2014, and the progress continues
 today.
 
-Let's start with a simple and well-studied example. 
+Let's start with a simple and well-studied example. In 2008, ISPs in
+Pakistan were ordered by the government to block access to YouTube for
+users in the country. One ISP (Pakistan Telecom) chose to do this by
+advertising a route to a prefix that was within the range allocated to
+YouTube. In effect, the ISP announced "I have a good path to YouTube"
+so that it could then redirect traffic that would try to follow that
+path. The problem was that not only was this path not a viable way to
+reach YouTube, it was also a *more specific* path, that is, it was for
+a longer prefix than the true path to YouTube that was being
+advertised by other ASes. This turned into a problem well beyond the
+boundaries of Pakistan when the ISP advertised the route upstream to a
+larger ISP.  The upstream ISP now saw the more specific route as a
+distinct piece of routing information from the true, less specific
+route, and so it re-advertised this (false) path to its peers. Repeated
+application of this decision to accept the more specific path and
+re-advertise it caused much of the Internet to view the small ISP in
+Pakistan as a true path to YouTube. Within minutes a large percentage
+of the Internet was sending YouTube traffic to Pakistan, causing a
+global outage for YouTube. Resolution was achieved by manual
+intervention at multiple ISPs to stop the global advertisement of the
+false path.
+
+There are many other forms of attack possible on BGP, but they mostly
+take the form of a route being advertised and then propagated when it
+should not be. There is a relatively simple measure that should have
+prevented the incident described above: the provider AS immediately
+upstream from Pakistan Telecom  should not have accepted the
+advertisement that said "I have a route to YouTube". How would it know
+not to accept this? After all, BGP needs to be dynamic, so a newly
+advertised prefix is sometimes going to be correct. One solution to
+this problem is the use of Internet Routing Registries, which serve as
+databases mapping address prefixes to the ASes that are authorized to
+advertise them. In the prior example, since YouTube is not a customer
+of Pakistan Telecom, the IRR would show that the YouTube prefix should
+not be advertised by this AS. The responsibility to filter out the
+false announcement falls on the *upstream* ISP, who would need to
+periodically query one or more IRRs in order to maintain an up-to-date
+set of filters to apply to its downstream peers.
+
+There are numerous issues with the IRR approach, including the fact
+that this sort of filtering gets much more difficult the closer you
+get to the "core" of the Internet. It's one thing to filter prefixes
+from an ISP that serves a modest number of customers in a single
+country; it's another to filter prefixes coming from a large peer with
+global presence. Some obviously bad routes can be filtered but it's
+very hard to get a complete picture sufficient to rule out anything
+incorrect that could be advertised. The set of rules that need to be
+configured on a BGP router for an ISP that carries hundreds of
+thousands of routes can also get very large. 
+
+Furthermore, as noted by Sharon Goldberg in her article "*Why Is It
+Taking So Long to Secure Internet Routing?*", the incentives for
+prefix filtering are somewhat misaligned. The cost of filtering falls
+on the AS that is immediately upstream of the misbehaving ISP, while
+the benefit accrues to some distant entity (YouTube in our example)
+who avoids the impact to their traffic thanks to the work of a
+provider with whom they have no relationship.
+
+A more sophisticated approach relies on the use of cryptographically
+signed statements authorizing a particular AS to advertise paths to a
+particular prefix. This technology behind this is referred to as RPKI:
+Resource Public Key Infrastructure.
+
+RPKI provides a means by which entities involved in routing, such as
+the operator of an AS, can prove that they are authorized to advertise
+routing information such as address prefixes. A Route Origin
+Authorization (ROA), for example, contains a certificate, and AS
+number, and a set of prefixes that the AS is authorized to
+advertise. The ROA is cryptographically signed by an entity that is
+itself trusted to provide this authorization, such as Regional
+Internet Registry (RIR). Because RIRs a responsible for the allocation
+of address space, they are a logical place to locate trust for the
+RPKI. There are five RIRs globally and each has a root certificate in
+the RPKI.
+
+Address allocation is a hierarchical process. For example, an RIR can
+allocate a chunk of address space to an ISP, and the ISP can
+sub-allocate from that chunk to one of its customers. A hierarchy of
+certificates can be used that follows this hierarchy of address
+allocation.  The RIRs form "trust anchors" from which chains of trust
+can be built, much the way a modern browser comes with a set of
+trusted root certification authorities (CAs) so that the certificates
+issued by web sites can be checked for validity.
+
+A key distinction between RPKI and the certificates that we are
+familiar with from TLS is this: the certificates in TLS are used to
+validate the *identity* of a web site (e.g., a certificate for cnn.com
+tells your browser that it is actually talking to cnn.com), whereas
+RPKI certificates are used to validate the *authority* to advertise
+certain IP addresses. As IP address allocation starts with the RIRs
+and proceeds down through ISPs to end customers, resource certificates
+are generated at each level in the hierarchy.
+
+.. _fig-rpki:
+.. figure:: figures/rpki.png
+   :width: 600px
+   :align: center
+
+   Chain of trust for RPKI
+
+:numref:`Figure %s <fig-rpki>` shows how the
+certificates are arranged for a simple example of an ISP *A* with
+customer *C*. There is a chain of trust from the root certificate to
+the customer, much like the sort certification hierarchy we have seen
+used for TLS. However, because the goal here is to certify the
+authority of a certain AS to advertise a prefix, the details of the
+certificates are different from those used in TLS. For example, the
+certificate that ISP *A* issues, on the far right of the picture, says
+that some address prefix has been allocated to customer *C*, and
+includes the AS number of customer C. This certificate is signed by
+ISP *A* using the private key of *A*.
+
+One level higher in the chain, the Local Internet Registry (LIR) has
+issued a certificate that states ISP *A* has authority to allocate
+addresses out of some prefix. The prefix that *A* has allocated to *C*
+must be a subprefix within the allocation made by the LIR.
+By following the chain back to the root certificate, it is possible to
+establish that *C* is legitimately able to advertise the prefix
+allocated to it by *A*.
+
+*C* can now create a Route Origin Authorization (ROA) which it signs
+with its private key. The ROA contains the AS number of *C* and the
+prefix or prefixes that it wishes to advertise. Anyone who looks at
+the ROA and the resource certificate chain that leads from the root CA to *C*
+can validate that the ROA is legitimate. 
+
+
+Rather than being passed around in real time like certificates in TLS,
+the RPKI certificates are stored in repositories, which are typically
+operated by the RIRs. Address allocations happen at a relatively long
+timescale, and certificates can be issued at the same time. Thus it is
+feasible to fetch the entire contents of the RPKI repository to build up a
+complete picture of the chains of certificates that have been
+issued. With this information, a router running BGP can determine *in advance* which
+ASes could originate routing advertisements for which prefixes and use
+this to configure filtering rules on what advertisements they are
+willing to accept. There is a well-established set of software tools
+to automate this process for popular operating systems and commercial
+routing platforms.
+
+With the RPKI in place it is now possible to perform Route Origin
+Validation. That is, if a given AS claims to be the originator of a
+certain prefix, that claim can be checked against the information in
+the RPKI. So, for example, if Pakistan Telecom were now to claim to be the
+origin AS for a subprefix of YouTube, that could immediately be
+detected as false information and discarded by any router receiving
+such an advertiment, not just the neighbors of the offending ISP.
+
+While there are many forms of attack or misconfiguration that would
+not be caught by ROV (such as an AS falsely claiming a shorter path that
+doesn't actually exist) it does prevent a large number of issues,
+especially those caused by misconfiguration. To more fully combat the
+advertisement of false information in BGP, it is necessary to adopt
+some sort of path validation, as discussed below.
+
+
+ROV adoption
+
+.. rubric:: path validation
+
+
+
+
+
 
 .. _reading_rpki:
 .. admonition::  Further Reading
@@ -210,8 +373,7 @@ DNSSEC
 
    RFCs 4033-4035
 
-
-   ----
+   
    adoption of RPKI vs DNSSEC - the difference between detecting
    corrupt info vs. preventing spread of corrupt info