router solution

So, just trust in many cases is not enough. Even if you trust your immediate feasts, where is the guarantee that there will not be a weak link among the crossroads of Internet connectivity? The network should be able to distinguish the truth from the lie, which in most cases considered is expressed in the misappropriation of someone else's prefix (prefix hijacking). In this case, the network routing policy may include filtering illegal announcements, and, accordingly, prevent the further penetration of false information on the Internet why are routers needed in networking?.
The safety and reliability of the routing system largely depends on the ability to correctly answer the questions:

1. Is the prefix received in the BGP message legitimate (i.e. representing the legally allocated address space and the right to use it)?
2. is the autonomous sender system of the BGP message the source of origin of the prefix?
3. Does the AS_PATH attribute received in the BGP message match the actual path that the message passed on the Internet?

Unfortunately, it is very difficult to give the correct answers to the questions posed due to the lack of a reliable source of information. So, what is available in the arsenal of the service provider?

Internet Routing Registries (IRR)

Partial assistance in solving this problem is provided by the Internet Routing Registry (IRR). Their essence is as follows: network operators register their routing policies in the database, namely with whom and how the network interacts, and the prefixes that the network uses and announces on the Internet. As part of the IETF () a special language was developed - RPSL (Routing Policy Specification Language), which allows to describe the routing policy. The toolkit was also developed, the most famous - IRRToolset (http://irrtoolset.isc.org/ ), which allows you to automate the routing configuration of the provider according to IRR data.
But IRRs display a very incomplete picture, since the registration of data in these databases is purely voluntary. Many operators do not want to fool themselves with some IRR; some operators do not register because of their reluctance to disclose their policies. Those who nevertheless registered their policies do not always maintain the relevance of the data. The problem is that although this activity serves the benefit of a common cause - a secure routing system, the benefit for the provider itself is not always tangible.
Incompleteness and unreliable data quality, as well as poor scalability of the approach - try creating filters for all prefixes registered in the IRR! - significantly limit their use to solve global routing security problems.
As a result, IRRs have a very limited distribution and are mainly used for the administration of connected clients by the provider router solution.

whois

You can use more reliable data - databases of address space distribution at the level of Regional Internet Registry (RIR). Although this information can be obtained through the corresponding whois registry server, sometimes the more practical way is to use the so-called statistics files available on the ftp website ( ftp://ftp.ripe.net/pub/stats ). For example, Internet resources distributed by RIPE NCC are presented in the file: ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest .
As you can see, the number of entries is quite impressive, and the list of prefixes in the configuration of your border routers is also impressive.
The IANA database (Internet Assigned Number Authority, www.iana.org ), for example http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml for IPv4 resources, is more compact, although it does not contain details - each entry has a size of / 8 in the case of IPv4, and the granularity for the IPv6 address space is even less. However, this approach allows at least blocking networks that use unallocated address resources.

Border Reliability

Global routing security is a desirable goal, but hardly easily achievable. Meanwhile, if each operator monitors the “hygiene” of its customer networks, the situation may noticeably improve.
Such a strategy has the greatest chances in networks with only one level of connected clients. For providers of a higher level (for example, tier-2 or tier-1), the task of accounting for clients of their clients is insurmountably difficult.
The task of reliability of borders is twofold:

• at the routing level, do not accept the announcement of unregistered networks of their customers, and
• at the traffic transfer level, do not accept traffic originating from unregistered networks (for example, using fabricated source addresses)

As we have already discussed, a public IRR can be used to solve the first part of the problem, or, if the operator does not want to publish all its customers explicitly, its own customer database.
To counteract traffic from a source with a fabricated address, ingress filtering is required. Packets in which the sender address does not match the address space of the connected client are discarded. This approach is described in IETF BCP38 ( http://www.ietf.org/rfc/rfc2827.txt ).
One of the mechanisms for implementing such filtering is the use of the so-called reverse path forwarding (RPF) method. Its essence is to use the information available on the network topology at the router, namely routing tables. Only those packets received from the direction of the best path to the sender are transmitted by the router. The logic here is simple - if the packet came along the same path that replies are sent, the chances are high that the sender is true. However, this provides for the symmetry of the transmission of direct and reverse traffic, which is generally incorrect. The solution to some of these problems is described in another IETF document - BCP84 ( http://www.ietf.org/rfc/rfc3704.txt) At the same time, in the case of directly connected terminal client networks, such a mechanism works quite well.