.2.3BGP authentication
- There are two main types of common BGP attacks:
- Establish illegal BGP neighbor relationships, advertise illegal routing entries, and interfere with normal routing tables.
- A large number of illegal BGP packets are sent, and the router sends them to the CPU after receiving them, resulting in increased CPU utilization
- BGP authentication
BGP authentication includes MD5 authentication and Keychain authentication. Authenticating BGP peer relationships can prevent the establishment of illegal BGP neighbors.
- MD5 authentication
BGP uses TCP as the transport layer protocol. To improve the security of BGP, MD5 authentication can be performed when establishing a TCP connection. The MD5 authentication of BGP is only to set the MD5 authentication password for the TCP connection, and the authentication is completed by TCP.
- Keychain authentication
Both ends of the BGP peer must be configured with Keychain authentication for applications using TCP connections, and the configured Keychains must use the same encryption algorithm and password, so that TCP connections can be established normally and BGP messages can be exchanged.
【Technical points】The difference between MD5 and Keychain
- The MD5 algorithm is easy to configure, and a single password is generated after configuration, which requires human intervention to change the password.
- Keychain has a set of passwords, which can be automatically switched according to the configuration, but the configuration process is relatively complicated, and it is suitable for networks with relatively high security performance requirements.
- BGP MD5 authentication and BGP Keychain authentication are mutually exclusive.
- GTSM (Generalized TTL Security Mechanism, general TTL security protection mechanism)
The GTSM function of BGP detects whether the TTL (Time-to-Live) value in the IP packet header is within a preset specific range, and discards packets that do not meet the TTL value range, thus avoiding network attacks Or simulate "legitimate" BGP packets to attack the device.
When an attacker simulates legitimate BGP packets to attack R2 by continuously sending illegal packets, the TTL value must be less than 255. If R2 enables the GTSM function of BGP and sets the effective range of TTL of IBGP peer packets to [255,255], the system will check the TTL values of all BGP packets and discard attack packets with TTL values less than 255. Therefore, the problem of high CPU usage caused by network attack packets is avoided.
3.4.5 Security of BGP
2. Experimental topology
3. Experimental procedure
Experiment video guide:
- Configure IP address
Configuration of AR1
<Huawei>system-view
Enter system view, return user view with Ctrl+Z.
[Huawei]undo info-center enable
Info: Information center is disabled.
[Huawei]sysname AR1
[AR1]interface g0/0/0
[AR1-GigabitEthernet0/0/0]ip address 10.0.12.1 24
[AR1-GigabitEthernet0/0/0]quit
[AR1]interface g0/0/1
[AR1-GigabitEthernet0/0/1]ip address 10.0.13.1 24
[AR1-GigabitEthernet0/0/1]quit
[AR1]interface LoopBack 0
[AR1-LoopBack0]ip address 1.1.1.1 32
[AR1-LoopBack0]quit
Configuration of AR2
<Huawei>system-view
Enter system view, return user view with Ctrl+Z.
[Huawei]undo info-center enable
Info: Information center is disabled.
[Huawei]sysname AR2
[AR2]interface g0/0/1
[AR2-GigabitEthernet0/0/1]ip address 10.0.12.2 24
[AR2-GigabitEthernet0/0/1]quit
[AR2]interface g0/0/0
[AR2-GigabitEthernet0/0/0]ip address 10.0.23.2 24
[AR2-GigabitEthernet0/0/0]quit
[AR2]interface LoopBack 0
[AR2-LoopBack0]ip address 2.2.2.2 32
[AR2-LoopBack0]quit
Configuration of AR3
<Huawei>system-view
Enter system view, return user view with Ctrl+Z.
[Huawei]undo info-center enable
Info: Information center is disabled.
[Huawei]sysname AR3
[AR3]interface g0/0/0
[AR3-GigabitEthernet0/0/0]ip address 10.0.13.3 24
[AR3-GigabitEthernet0/0/0]quit
[AR3]interface g0/0/1
[AR3-GigabitEthernet0/0/1]ip address 10.0.23.3 24
[AR3-GigabitEthernet0/0/1]quit
[AR3]interface LoopBack 0
[AR3-LoopBack0]ip address 3.3.3.3 32
[AR3-LoopBack0]quit
- Configure OSPF
Configuration of AR1
[AR1]ospf router-id 1.1.1.1
[AR1-ospf-1]area 0
[AR1-ospf-1-area-0.0.0.0]network 10.0.12.0 0.0.0.255
[AR1-ospf-1-area-0.0.0.0]network 10.0.13.0 0.0.0.255
[AR1-ospf-1-area-0.0.0.0]network 1.1.1.1 0.0.0.0
[AR1-ospf-1-area-0.0.0.0]quit
Configuration of AR2
[AR2]ospf router-id 2.2.2.2
[AR2-ospf-1]area 0
[AR2-ospf-1-area-0.0.0.0]network 10.0.12.0 0.0.0.255
[AR2-ospf-1-area-0.0.0.0]network 10.0.23.0 0.0.0.255
[AR2-ospf-1-area-0.0.0.0]network 2.2.2.2 0.0.0.0
[AR2-ospf-1-area-0.0.0.0]quit
Configuration of AR3
[AR3]ospf router-id 3.3.3.3
[AR3-ospf-1]area 0
[AR3-ospf-1-area-0.0.0.0]network 10.0.13.0 0.0.0.255
[AR3-ospf-1-area-0.0.0.0]network 10.0.23.0 0.0.0.255
[AR3-ospf-1-area-0.0.0.0]network 3.3.3.3 0.0.0.0
[AR3-ospf-1-area-0.0.0.0]quit
- Configure BGP
Configuration of AR1
[AR1]bgp 101
[AR1-bgp]peer 2.2.2.2 as-number 101
[AR1-bgp]peer 2.2.2.2 connect-interface LoopBack 0
[AR1-bgp]peer 3.3.3.3 as-number 101
[AR1-bgp]peer 3.3.3.3 connect-interface LoopBack 0
[AR1-bgp]quit
Configuration of AR2
[AR2]bgp 101
[AR2-bgp]peer 1.1.1.1 as-number 101
[AR2-bgp]peer 1.1.1.1 connect-interface LoopBack 0
[AR2-bgp]peer 3.3.3.3 as-number 101
[AR2-bgp]peer 3.3.3.3 connect-interface LoopBack 0
[AR2-bgp]quit
Configuration of AR3
[AR3]bgp 101
[AR3-bgp]peer 1.1.1.1 as-number 101
[AR3-bgp]peer 2.2.2.2 as-number 101
[AR3-bgp]peer 1.1.1.1 connect-interface LoopBack 0
[AR3-bgp]peer 2.2.2.2 connect-interface LoopBack 0
[AR3-bgp]quit
4. Experimental debugging
- Configure MD5 authentication between AR1 and AR2
[AR1]bgp 101
[AR1-bgp]peer 2.2.2.2 password cipher 1234
[AR1-bgp]quit
[AR2]bgp 101
[AR2-bgp]peer 1.1.1.1 password cipher 1234
[AR2-bgp]quit
【Technical points】MD5 authentication
- Check the authentication information of the BGP peer on AR1.
[AR1]display bgp peer 2.2.2.2 verbose
BGP Peer is 2.2.2.2, remote AS 101
Type: IBGP link
BGP version 4, Remote router ID 10.0.23.2
Update-group ID: 1
BGP current state: Established, Up for 00h15m15s
BGP current event: RecvKeepalive
BGP last state: OpenConfirm
BGP Peer Up count: 1
Received total routes: 0
Received active routes total: 0
Advertised total routes: 0
Port: Local - 49215 Remote - 179
Configured: Connect-retry Time: 32 sec
Configured: Active Hold Time: 180 sec Keepalive Time:60 sec
Received : Active Hold Time: 180 sec
Negotiated: Active Hold Time: 180 sec Keepalive Time:60 sec
Peer optional capabilities:
Peer supports bgp multi-protocol extension
Peer supports bgp route refresh capability
Peer supports bgp 4-byte-as capability
Address family IPv4 Unicast: advertised and received
Received: Total 17 messages
Update messages 0
Open messages 1
KeepAlive messages 16
Notification messages 0
Refresh messages 0
Sent: Total 17 messages
Update messages 0
Open messages 1
KeepAlive messages 16
Notification messages 0
Refresh messages 0
Authentication type configured: MD5
Last keepalive received: 2023/01/30 15:30:24 UTC-08:00
Last keepalive sent : 2023/01/30 15:30:23 UTC-08:00
Minimum route advertisement interval is 15 seconds
Optional capabilities:
Route refresh capability has been enabled
4-byte-as capability has been enabled
Connect-interface has been configured
Peer Preferred Value: 0
Routing policy configured:
No routing policy is configured
From the above output, you can see that the authentication type is MD5.
- Configure key-chain authentication on AR1 and AR3
Step 1: Create a keychain
[AR1]keychain lw mode absolute // Create a keychain named lw, the mode is absolute time (it can also be periodic, such as every day)
[AR1-keychain]receive-tolerance 10 // Receive fault tolerance time is 10 minutes
[AR1-keychain]tcp-kind 182
[AR1-keychain]tcp-algorithm-id hmac-md5 50
[AR1-keychain]quit
【Technical Point 1】receive-tolerance
- Due to factors such as the network environment or unsynchronized time at both ends, there may be delays in the message sent by the key-id, that is, the receiving end receives the message sent by the sending end during the inactive period, which will cause the receiving end to be in an inactive state. However, the message is discarded, so that the transmission of the protocol message is interrupted. In order to solve this problem, the user can configure the receiving fault tolerance time, so that the receiving segment will continue to take effect for a specified time after the configured receiving time arrives, so that the receiving end can process all the messages sent by the sending end, and the protocol messages are guaranteed to be normal. deal with.
- Configuring the receiving fault tolerance time will increase the corresponding time at the start time and end time of the receiving time at the same time.
【Technical Point 2】receive-tolerance
- For authenticated interactions of TCP connection establishment, TCP uses the enhanced TCP authentication option. Currently, different vendors use different kind-value values to represent enhanced TCP authentication options. In order to realize the interaction between devices from different manufacturers, the user can choose to configure the kind-value to make the TCP types of the devices at both ends of the communication consistent.
- When configuring the kind-value value, the communication parties using Keychain authentication must be applications that use TCP to establish connections. Otherwise, the configured TCP authentication will not take effect.
- After the TCP type configurations of the communication parties are consistent, you also need to specify the ID corresponding to the same authentication algorithm as the communication parties.
Step 2: Configure the key in the keychain
Configuration of AR1
[AR1-keychain]key-id 1 //key1
[AR1-keychain-keyid-1]algorithm hmac-md5 // The algorithm is hmac-md5
[AR1-keychain-keyid-1]key-string cipher joinlabs1 // The password is joinlabs1
[AR1-keychain-keyid-1]send-time utc 12:00 2023-01-30 to 17:00 2023-01-30 // Send time
[AR1-keychain-keyid-1]receive-time utc 12:00 2023-01-30 to 17:00 2023-01-30 // receive time
[AR1-keychain-keyid-1]quit
[AR1-keychain]key-id 2
[AR1-keychain-keyid-2]algorithm hmac-md5
[AR1-keychain-keyid-2]key-string cipher joinlabs2
[AR1-keychain-keyid-2]send-time utc 17:01 2023-01-30 to 18:00 2023-01-30
[AR1-keychain-keyid-2]receive-time utc 17:01 2023-01-30 to 18:00 2023-01-30
[AR1-keychain-keyid-2]quit
Configuration of AR3
[AR3]keychain lw mode absolute
[AR3-keychain]receive-tolerance 10
[AR3-keychain]tcp-kind 182
[AR3-keychain]tcp-algorithm-id hmac-md5 50
[AR3-keychain]quit
[AR3]keychain lw
[AR3-keychain]key-id 1
[AR3-keychain-keyid-1]algorithm hmac-md5
[AR3-keychain-keyid-1]key-string cipher joinlabs1
[AR3-keychain-keyid-1]send-time utc 12:00 2023-01-30 to 17:00 2023-01-30
[AR3-keychain-keyid-1]receive-time utc 12:00 2023-01-30 to 17:00 2023-01-30
[AR3-keychain-keyid-1]quit
[AR3-keychain]key-id 2
[AR3-keychain-keyid-2]algorithm hmac-md5
[AR3-keychain-keyid-2]key-string cipher joinlabs2
[AR3-keychain-keyid-2]send-time utc 17:01 2023-01-30 to 18:00 2023-01-30
[AR3-keychain-keyid-2]receive-time utc 17:01 2023-01-30 to 18:00 2023-01-30
[AR3-keychain-keyid-2]quit
- Configure keychain authentication
[AR1]bgp 101
[AR1-bgp]peer 3.3.3.3 keychain lw
[AR1-bgp]quit
[AR3]bgp 101
[AR3-bgp]peer 1.1.1.1 keychain lw
[AR3-bgp]quit
- View the Key-id currently in Active state
<AR1>display keychain lw
Keychain Information:
---------------------
Keychain Name : lw
Timer Mode : Absolute
Receive Tolerance(min) : 10
TCP Kind : 182
TCP Algorithm IDs :
HMAC-MD5 : 50
HMAC-SHA1-12 : 2
HMAC-SHA1-20 : 6
MD5 : 3
SHA1: 4
Number of Key IDs : 2
Active Send Key ID : 2
Active Receive Key IDs : 01 02
Default send Key ID : Not configured
Key ID Information:
-------------------
Key ID : 1
Key string : %$%$Z4^:U0Tz^.Lup[UrVa`+$UBU%$%$ (cipher) .
Algorithm : HMAC-MD5
SEND TIMER :
Start time : 2023-01-30 12:00
End time : 2023-01-30 17:00
Status : Inactive
RECEIVE TIMER :
Start time : 2023-01-30 12:00
End time : 2023-01-30 17:00
Status : Active
Key ID : 2
Key string : %$%$H>04M1/+dUKY`5:znJ+/$Zh9%$%$ (cipher)
Algorithm : HMAC-MD5
SEND TIMER :
Start time : 2023-01-30 17:01
End time : 2023-01-30 18:00
Status : Active
RECEIVE TIMER :
Start time : 2023-01-30 17:01
End time : 2023-01-30 18:00
Status : Active
From the above output, you can see that key1 is inactive and key2 is active
- Check whether the authentication type configured on the BGP peer is Keychain
<AR1>display bgp peer 3.3.3.3 verbose
BGP Peer is 3.3.3.3, remote AS 101
Type: IBGP link
BGP version 4, Remote router ID 10.0.13.3
Update-group ID: 1
BGP current state: Established, Up for 02h06m29s
BGP current event: KATimerExpired
BGP last state: OpenConfirm
BGP Peer Up count: 1
Received total routes: 0
Received active routes total: 0
Advertised total routes: 0
Port: Local - 49215 Remote - 179
Configured: Connect-retry Time: 32 sec
Configured: Active Hold Time: 180 sec Keepalive Time:60 sec
Received : Active Hold Time: 180 sec
Negotiated: Active Hold Time: 180 sec Keepalive Time:60 sec
Peer optional capabilities:
Peer supports bgp multi-protocol extension
Peer supports bgp route refresh capability
Peer supports bgp 4-byte-as capability
Address family IPv4 Unicast: advertised and received
Received: Total 128 messages
Update messages 0
Open messages 1
KeepAlive messages 127
Notification messages 0
Refresh messages 0
Sent: Total 128 messages
Update messages 0
Open messages 1
KeepAlive messages 127
Notification messages 0
Refresh messages 0
Authentication type configured: Keychain(lw)
Last keepalive received: 2023/01/30 17:21:22 UTC-08:00
Last keepalive sent : 2023/01/30 17:21:23 UTC-08:00
Minimum route advertisement interval is 15 seconds
Optional capabilities:
Route refresh capability has been enabled
4-byte-as capability has been enabled
Connect-interface has been configured
Peer Preferred Value: 0
Routing policy configured:
No routing policy is configured
【Technical points】MD5 and KeyChain authentication
MD5 authentication can only set authentication password for TCP connection
In addition to setting authentication passwords for TCP connections, Keychain authentication can also authenticate BGP protocol packets.
BGP MD5 authentication and BGP Keychain authentication are mutually exclusive.
Thinking: After this period of time, will the BGP connection fail?
- Configure GTSM on AR2 and AR3
[AR2]bgp 101
[AR2-bgp]peer 3.3.3.3 valid-ttl-hops 1 // Enable GTSM between R1 and R2. Since the two routers are directly connected, the effective range of TTL to reach each other is [255, 255], so the value of valid-ttl-hops here is 1.
[AR2-bgp]quit
[AR3]bgp 101
[AR3-bgp]peer 2.2.2.2 valid-ttl-hops 1
[AR3-bgp]quit
[Technical points] peer 3.3.3.3 valid-ttl-hops 1
- When sending BGP packets to neighbor 3.3.3.3, the TTL is 255
- When receiving BGP packets from neighbor 3.3.3.3, the TTL of the packets is required to be greater than or equal to 255-1+1
- The effective range of the TTL value of the detected packet is [ 255–hops+1, 255 ]
For example, for an EBGP direct route, the value of hops is 1, that is, the effective TTL value is 255. By default, the value of parameter hops is 255, that is, the valid value range of TTL is [ 1, 255 ].