Hi,
This post mainly talks about the BGP GTSM security mechanism (TTL security mechanism) and interconnection with the devices of vendors C and J.
1. TTL Security Issues of BGP Packets and improvement ideas
Some security measures are taken in the design of the EBGP peer relationship to prevent attackers from attempting to establish EBGP peer relationships:
By default, an EBGP peer relationship is established through a single hop. Therefore, the sending side sets the TTL value in BGP packets to 1. The receiving side receives and processes BGP packets with the TTL value being 1. When the packet forwarding path exceeds one hop, the TTL value in the IP header of the packets changes to 0 and the packets are discarded. This prevents multi-hop attacks to some extent.
Checks whether the IP address of the EBGP peer and the local IP address are in the same network segment.
However, the preceding two methods have the following disadvantages:
First, attackers can forge the source address of packets. In the case of indirect connection, the router does not verify the IP addresses of BGP peers on the same network segment.
Secondly, if the TTL value of a BGP packet is required to be 1, the attacker can also perform spoofing in the following way: After the attacker detects the number of hops with the router, an appropriate TTL value is set locally to make the TTL value of the BGP packet be 1 when the attack packet reaches the router. In this way, the attacked router processes the attack packet and its resource usage increases.
To address the security issue, RFC 5082 defines a new security mechanism: Generalized TTL Security Mechanism (GTMS).
The default TTL value of packets from a common EBGP peer is 1. You can use the ebgp-max-hop command to set the TTL value of EBGP packets. When receiving a packet, the device processes the packet if the TTL value of the packet is smaller than or equal to the value of ebgp-max-hop.
The GTSM mechanism of BGP, however, has the following feature: By default, the TTL value of the locally sent packets is 255. If the number of hops is X, the BGP module processes the received BGP packet whose TTL is greater than or equal to 255-X. Otherwise, the BGP module does not process the received BGP packet. The mechanism ensures that attackers cannot launch attacks using BGP packets in multi-hop scenarios, protecting the BGP module of the device.
From the preceding information, we can see that both ebgp-max-hop and GTSM can affect the TTL value in the packets sent by an EBGP peer. Therefore, they cannot be used together, and only one of them can be used for the same EBGP peer. When GTSM is enabled on a Huawei device, the default TTL value in BGP packets sent by the device is 255.
In addition, the GTSM processes the TTL of the sent packets and verifies the TTL on the receiver side, which is different from the common BGP peer. Therefore, the BGP peers at both ends must be deployed in pairs.
2. BGP TTL Security Deployment and Interconnection with mainstream vendors
(1) BGP GTSM implementation on Huawei devices:
a. Configure the basic BGP GTSM functions.
When being configured in the BGP view, GTSM is also applicable to MP-BGP VPNv4 extensions because they use the same TCP connection.
The GTSM and EBGP-MAX-HOP functions both affect the TTL values of sent BGP messages and they conflict with each other. Thus, for a peer or a peer group, you can use only either of them.
Run system-view
The system view is displayed.
Run bgp as-number
The BGP view is displayed.
Run peer { group-name | ipv4-address } valid-ttl-hops [ hops ]
The BGP GTSM is configured.
The valid TTL range of detected packets is [255 - hops + 1, 255]. For example, for an EBGP direct route, the number of hops is 1, that is, the valid TTL value is 255. By default, the valid TTL range is [1, 255], that is, the value of hops is 255.
Note: When being configured in the BGP view, GTSM is also applicable to MP-BGP VPNv4 extensions because they use the same TCP connection.
The GTSM and EBGP-MAX-HOP functions both affect the TTL values of sent BGP messages and they conflict with each other. Thus, for a peer or a peer group, you can use only either of them.
A BGP router that is enabled with GTSM checks the TTL values in all BGP packets. As required by the actual networking, packets whose TTL values are not within the specified range are discarded. If GTSM is not configured on a BGP router, the received BGP packets are forwarded if the BGP peer configuration is matched. Otherwise, the received BGP packets are discarded. This prevents bogus BGP packets from consuming CPU resources.
b. Set the default action for packets that do not match the GTSM policy.
GTSM only checks the TTL values of packets that match the GTSM policy. Packets that do not match the GTSM policy can be allowed or dropped. If "drop" is set as the default GTSM action for packets, you need to configure TTL values for all the packets sent from valid peers in the GTSM policy. If TTL values are not configured for the packets sent from a peer, the device will discard the packets sent from the peer and cannot establish a connection to the peer. Therefore, GTSM enhances security but reduces the ease of use.
You can enable the log function to record packet drop for troubleshooting.
Perform the following configurations on the GTSM-enabled router:
Run system-view
The system view is displayed.
Run gtsm default-action { drop | pass }
The default action for packets that do not match the GTSM policy is configured.
Note:
If the default action is configured but no GTSM policy is configured, GTSM does not take effect.
This command is supported only on the Admin-VS and cannot be configured in other VSs. This command takes effect on all VSs.
(2) BGP GTSM implementation on vendor C devices:
a. configuration of the 12000 series devices of vendor C (IOS XR version, configured based on the group):
neighbor-group test-group
remote-as 100
ebgp-multihop 255
ttl-security
update-source Loopback0
address-family ipv4 unicast
b. Common device configuration (IOS version) of vendor C:
router bgp 10
no synchronization
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 ttl-security hops 2
neighbor 1.1.1.1 update-source Loopback0
no auto-summary
(3) BGP GTSM implementation on vendor J devices:
Method 1: Run the ttl-security scripts command to automatically generate the ttl-security configuration. The default value of multi-hop is 255.
system {
scripts {
commit {
allow-transients;
file ttl-security.slax;
}
}
}
interfaces {
lo0 {
unit 0 {
family inet {
filter {
input ttl-security;
}
}
}
}
}
protocols {
bgp {
group test {
apply-macro ttl-security;
multihop {
ttl 255;
}
neighbor 10.1.2.3;
neighbor 10.3.4.5;
neighbor 10.5.6.7;
}
}
}
firewall {
filter ttl-security {
term gtsm {
from {
source-address {
10.1.2.3/32;
10.3.4.5/32;
10.5.6.7/32;
}
protocol tcp;
ttl-except 254;
port 179;
}
then {
discard;
}
}
term else {
then {
Accept;
}
}
}
}
Method 2: Configure the multi-hop and ttl-security values separately. The two parameters are not associated. One is used to set the TTL value of outgoing BGP packets, and the other is used to perform TTL security check on incoming BGP packets.
That's all, I hope it is of help to you.
