RIP/RIPng
Security Policy
Rapid development of networks poses higher network security requirements. Routing protocol packets transmitted over networks may be illegally obtained, changed, or forged, and packet attacks may cause network interruptions. Therefore, packets need to be protected.
Protocol-specific security mechanism
RIP/RIPng supports the following security policies:
TTL/hop limit:
A source device can transmit RIP/RIPng packets to a device that is only a hop far from the source. When RIP/RIPng packets are sent on broadcast or multicast networks (except for unicast peers), RIP/RIPng sets the TTL/hop limit value to 1.
Whitelist
RIP/RIPng supports a whitelist in a CPCAR policy. Packets sent by a neighbor listed in a whitelist are accepted, but not discarded.
GTSM
RIP uses GTSM to protect devices from potential attacks by checking whether the TTL value in each IP packet header is within a pre-defined range. TTL specifies the maximum number of devices through which a packet can pass. The forwarding plane of a neighbor directly filters out the protocol packets whose TTL values exceed the TTL range, preventing the control plane from being attacked.
Authentication
RIP-2 supports authentication to prevent receiving bad routing data, error packets, and replay attacks.
RIPng does not define any authentication mechanism to prevent receiving bad routing data, error packets, or replay attacks. RIPng supports IPsec authentication for RIPng packets.
Route limit
RIP/RIPng supports the limit on the number of routes that can be added to the RIP/RIPng database for each RIP/RIPng process.
Handling policies for massive packets attacks and error packet attacks
RIP uses the interface security mechanism and whitelist to handle massive attacks.
Other policies
The system supports the CP defense policy (CAR) for each interface to define the bandwidth which new sources assign RIP packets.
Attack Methods
DoS attacks
To protect from DoS attacks, RIP uses the CP defense policy.
Devices can be subjected to DoS attacks by transmitting RIP protocol packets from random sources. These packets are processed by an I/O board and sent to a main control board on which they are dropped by RIP/RIPng. This results in wasted bandwidth and CPU resources, and can reduce system performance.
To prevent this type of unnecessary packet processing from unknown sources, a whitelist can be configured. RIP/RIPng creates a whitelist label for each known interface so that these labeled interfaces can exchange packets rapidly. This is necessary to ensure quick convergence on the network. If interfaces that send RIP/RIPng packets are not in the whitelist, these interfaces are allocated only limited default bandwidth.
Injection of massive routing information
The number of routes supported for RIP/RIPng processes will depend on available CPU and memory resources on a device. If the number of routes received is greater than the device capacity, CPU and memory usage increases, causing the device to become unstable. To prevent this device instability, RIP/RIPng supports a maximum number of routes.
Injection of bad routing information
RIP/RIPng will accept any packet from a valid packet source address that matches the configured network. RIP/RIPng carries direct route data in its RIP/RIPng packet, and therefore, it may be used to attack by inserting invalid or incorrect routing information in the RIP/RIPng packet. The incorrect information causes the generated routing database to be incorrect and leads to network failures.
If authentication is configured on the RIP interface on both sides, RIP only accepts packets if they are authenticated in order to prevent accepting routes from unauthenticated peers.
If IPsec is configured on both sides, RIP/RIPng will only accept packets that are authenticated in order to prevent accepting routes from unauthenticated peers.
Replay attacks
RIP supports sequence numbers in MD5 authenticated packets to prevent replay attacks.
Procedure
- Configure RIP authentication.
- Run any of the following commands:
- To configure simple authentication for RIP-2 packets, run the rip authentication-mode simple { plain plain-text | [ cipher ] password-key } command.
In simple authentication mode, the password in simple text mode is transmitted along with each authentication packet. Therefore, simple authentication is not recommended on networks requiring high security.
- To configure MD5 authentication for RIP-2 packets, run the rip authentication-mode md5 { nonstandard { { plain plain-text | [ cipher ] password-key } key-id | keychain keychain-name } | usual { plain plain-text | [ cipher ] password-key } } command.
In MD5 authentication mode, an MD5 password is used for packet encapsulation and decapsulation. MD5 authentication is more secure than simple authentication.
nonstandard supports nonstandard authentication packets.
usual supports Internet Engineering Task Force (IETF) standard authentication packets.
- To configure Hash Message Authentication Code for Secure Hash Algorithm 256 (HMAC-SHA256) authentication for RIP-2 packets, run the rip authentication-mode hmac-sha256 { plain plain-text | [ cipher ] password-key } key-id command.
When configuring an authentication password, select the ciphertext mode because the password is saved in the configuration file as a clear text if you select the clear text mode, which has a high risk. To ensure device security, change the password periodically.
- To configure simple authentication for RIP-2 packets, run the rip authentication-mode simple { plain plain-text | [ cipher ] password-key } command.
- Run any of the following commands:
- Configuring IPsec Authentication for a RIPng Process
- Configuring IPsec Authentication on a RIPng Interface
- Run ripng ipsec sa sa-name
IPsec authentication is enabled on the interface, and the name of an SA is specified.
The ripng ipsec sa command takes precedence over the ipsec sa command. If both commands are run in respective views and different SA names are specified, only the configuration of the ripng ipsec sa command takes effect.
- Run ripng ipsec sa sa-name
- Configure RIP/RIPng whitelist security.
No specific configuration is provided for RIP/RIPng.
Configuration and Maintenance Suggestions
RIP authentication support
In MD5 authentication mode, which Huawei implements in compliance with relevant standards, RIP packets will take "checksum" in authentication instead of direct password keys. Nonstandard authentication is based on relevant standards and supports the same packet format described in relevant standards. MD5 is supported only.
Configuring keychain authentication improves RIP connection security. You must configure keychain authentication on both peers of a link. Note that encryption algorithms and passwords configured for the keychain authentication on both peers must be the same; otherwise, the connection cannot be set up between RIP peers, and RIP messages cannot be transmitted.
To improve network security, HMAC-SHA256 authentication is recommended.
RIPng authentication support using IPsec
RIPng supports IPsec authentication. Before configuring IPsec authentication for RIPng, familiarize yourself with basic IPsec configurations.
RIP/RIPng interface security
No additional RIP/RIPng configuration is required.
RIP whitelist security support
RIP adds a neighbor to a whitelist when receiving the first response packet sent by the neighbor. RIP does not check whether a neighbor is trusted or not when adding it to the whitelist. Configure authentication on RIP-enabled interfaces so that trusted neighbors can be added to the whitelist.
RIP/RIPng routing restriction
A maximum number of routes supported can be set based on device usage scope, memory capacity, and supported CPCAR values.