BGP Security
BGP Authentication
BGP can work properly only after BGP peer relationships are established. Authenticating BGP peers can improve BGP security.
MD5 authentication
BGP uses TCP as the transport layer protocol. Message Digest 5 (MD5) authentication can be used when establishing TCP connections to improve BGP security. MD5 authentication sets the MD5 authentication password for the TCP connection, and TCP performs the authentication. If the authentication fails, the TCP connection cannot be established.
The encryption algorithm used for MD5 authentication poses security risks. Therefore, you are advised to use an authentication mode based on a more secure encryption algorithm.
Keychain authentication
Keychain authentication is performed at the application layer. It improves security by periodically changing the password and encryption algorithms without interrupting services. When keychain authentication is configured for BGP peer relationships over TCP connections, BGP messages as well as the process of establishing TCP connections can be authenticated. For details about keychain, see "Keychain" in HUAWEI NetEngine 8000 F Series Feature Description - Security.
- TCP-AO authentication
The TCP authentication option (TCP-AO) is used to authenticate received and to-be sent packets during TCP session establishment and data exchange. It supports packet integrity check to prevent TCP replay attacks. TCP-AO authentication improves the security of the TCP connection between BGP peers and is applicable to the network that requires high security.
BGP GTSM
During network attacks, attackers may simulate BGP messages and continuously send them to the router. If the messages are destined for the router, it directly forwards them to the control plane for processing without validating them. As a result, the increased processing workload on the router's control plane results in high CPU usage. The Generalized TTL Security Mechanism (GTSM) defends against attacks by checking the time to live (TTL) value in each packet header. TTL refers to the maximum number of routers through which a packet can pass.
GTSM checks whether the TTL value in each IP packet header is within a pre-defined range, which protects services above the IP layer and improves system security.
After a GTSM policy of BGP is configured, an interface board checks the TTL values of all BGP messages. According to actual networking requirements, you can set the default action (to drop or pass) that GTSM will take on the messages whose TTL values are not within a pre-defined range. If a valid TTL range is specified based on the network topology and the default action that GTSM will take is set to drop, the BGP messages whose TTL values are not within the valid range are discarded directly by the interface board upon receipt. This prevents bogus BGP messages from consuming CPU resources.
You can enable the logging function so that the device can record information about message dropping in logs. The recorded logs facilitate fault locating.
BGP RPKI
Resource Public Key Infrastructure (RPKI) ensures BGP security by verifying the validity of the BGP route source AS or route advertiser.
Attackers can steal user data by advertising routes that are more specific than those advertised by carriers. For example, if a carrier has advertised a route destined for 10.10.0.0/16, an attacker can advertise a route destined for 10.10.153.0/24, which is more specific than 10.10.0.0/16. According to the longest match rule, the route 10.10.153.0/24 is preferentially selected for traffic forwarding. As a result, the attacker succeeds in illegally obtaining user data. RPKI can be used to prevent this problem.
To solve the preceding problems, you can configure Route Origination Authorization (ROA)and regional validation to ensure BGP security.
Route Origination Authentication (ROA)
ROA stores the mapping between prefix addresses and the origin AS and checks whether the routes with a specified IP address prefix are valid by authenticating the AS number.
In Figure 1, a connection is created between Device B and the RPKI server. Device B can download the ROA database from the RPKI database and verify the mapping between 10.1.1.0/24 and AS 100. When AS 200 receives a route with the prefix 10.1.1.0/24 from AS 100 and AS 300, it compares the origin AS with that in the ROA database. If they are the same, the route is considered valid. If they are different, the route is considered invalid. The route to 10.1.1.0/24 learned from AS 100 is valid because it matches the ROA database, and the route advertisement from the origin AS 100 is considered valid. The route to 10.1.1.0/24 learned from AS 300 is invalid because it does not match the ROA database, and the route advertisement from the origin AS 300 is considered invalid.
The ROA results for received routes are as follows:
- Valid: indicates that the route advertisement from the origin AS to the specified IP address prefix is valid.
- Invalid: indicates that the route advertisement from the origin AS to the specified IP address prefix is invalid and that the route is not allowed to participate in route selection.
- Not Found: indicates that the origin AS does not exist in the ROA database and that the route participates in route selection.
In addition, ROA can be applied to the routes to be advertised to an EBGP peer, which prevents route hijacking. In Figure 2, Device B is configured to apply ROA to the routes to be advertised. Before advertising a route that matches the export policy to an EBGP peer, Device B performs ROA on the route by comparing the origin AS of the route with that of the corresponding route in the ROA database. If the route is not found in the ROA database, the ROA result is NotFound. If the route is found in the ROA database and the origin AS of the route is the same as that of the corresponding route in the ROA database, the ROA result is Valid. If the origin AS of the route is different from that of the corresponding route in the ROA database, the ROA result is Invalid. If the result is Valid, the route is advertised by default. If the result is NotFound, the route is not advertised by default. If the result is Invalid, the route is not advertised by default and an alarm is generated and is cleared when all routes with the result of Invalid are withdrawn.
Regional validation
Regional validation: Users can manually configure regions by combining multiple trusted ASs into a region and combining multiple regions into a regional confederation. Regional validation controls route selection results by checking whether the routes received from EBGP peers in an external region belong to the local region. This prevents intra-region routes from being hijacked by attackers outside the local region, and ensures that hosts in the local region can securely access internal services.
Regional validation applies to the following typical scenarios: regional validation scenario and regional confederation validation scenario.
- As shown in Figure 3, AS 1, AS 2, and AS 3 belong to a carrier's network, and AS 3 connects to AS 100 of another carrier's network. The user accesses the server at 10.1.0.0/16 in AS 2 through AS 1. In normal cases, the user accesses the server through the path AS 1 -> AS 3 -> AS 2. If an attacker forges a route 10.1.1.0/24 in AS 100, the user-to-server traffic will be illegally obtained by the attacker because the route advertised by the attacker is more specific. To solve this problem, configure regional validation on the border device of AS 3 to combine AS 1, AS 2, and AS 3 into region 1. AS 3 receives the attack route from AS 100, and the route source is AS 2, indicating that the route belongs to the local region. However, as the route is received from the BGP peer outside region 1, the route is considered illegal by regional validation. As a result, the route is set to be invalid, or the preference of the route is reduced.
- As shown in Figure 3, AS 1, AS 2, and AS 3 belong to a carrier's network, and AS 4 and AS 5 belong to a partner carrier's network. Both AS 3 and AS 4 are connected to AS 100 of another carrier. The user accesses the server at 10.1.0.0/16 in AS 5 through AS 1. In normal cases, the user accesses the server through the path AS 1 -> AS 3 -> AS 4 -> AS 2. If an attacker forges a route 10.1.1.0/24 in AS 100, the user-to-server traffic will be illegally obtained by the attacker because the route advertised by the attacker is more specific. To solve this problem, configure regional validation on the border device of AS 3. Specifically, combine AS 1, AS 2, and AS 3 into region 1, and AS 4 and AS 5 into region 2, and then group the regions 1 and 2 into regional confederation 1. AS 3 receives the attack route from AS 100, and the route source is AS 5, indicating that the route belongs to the local regional confederation. However, as the route is received from the BGP peer outside the regional confederation, the route is considered illegal by regional validation. As a result, the route is set to be invalid, or the preference of the route is reduced.
SSL/TLS authentication
Secure Sockets Layer (SSL) is a security protocol that protects data privacy on the Internet. Transport Layer Security (TLS) is a successor of SSL. TLS protects data integrity and privacy by preventing attackers from eavesdropping the data exchanged between a client and server. To ensure data transmission security on a network, SSL/TLS authentication can be enabled for BGP message encryption.