No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

ME60 V800R010C10SPC500 Configuration Guide - IP Routing 01

This is ME60 V800R010C10SPC500 Configuration Guide - IP Routing
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Improving RIP Network Security

Improving RIP Network Security

For the RIP network that requires high security requirements, you can configure RIP authentication and GTSM.

Usage Scenario

The TCP/IP protocol suite has inherent defects and flawed implementation. Increasing network attacks pose grave threats to TCP/IP networks. Especially attacks on network devices will cause network crashes. Therefore, RIP improves network security through the following functions:
  • RIP authentication: RIP checks the authentication mode and password in each packet to protect the local device against potential attacks.
  • Check on the source IP address of each packet: RIP interfaces receive packets only from the same network to protect the local device from potential attacks from other networks.
  • RIP GTSM: Generalized TTL Security Mechanism (GTSM) protects the local router by checking whether the time to live (TTL) value in the IP packet header is in a pre-defined range.

Pre-configuration Tasks

Before improving RIP network security, complete the following tasks:

Configuration Procedure

Perform one or more of the following configurations as required.

Configuring the Authentication Mode for RIP-2 Packets

RIP-2 supports protocol packet authentication and provides three authentication modes: simple text authentication, Message Digest 5 (MD5) authentication and HMAC-MD5 authentication, which enhances security. By default, authentication is not configured for RIP. Configuring authentication is recommended to ensure system security.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run interface interface-type interface-number

    The interface view is displayed.

  3. Perform the following operations as required:

    • Run rip authentication-mode simple { plain plain-text | [ cipher ] password-key }

      Simple authentication is configured for RIP-2 packets.

      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.

    • Run rip authentication-mode md5 { nonstandard { { plain plain-text | [ cipher ] password-key } key-id | keychain keychain-name } | usual { plain plain-text | [ cipher ] password-key } }

      Message Digest 5 (MD5) authentication is configured for RIP-2 packets.

      In MD5 authentication mode, the 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.

    • Run rip authentication-mode hmac-sha256 { plain plain-text | [ cipher ] password-key } key-id

      Hash Message Authentication Code for Secure Hash Algorithm 256 (HMAC-SHA256) authentication is configured for RIP-2 packets.

    When configuring an authentication password, select the ciphertext mode because the password is saved in configuration files in simple text if you select simple text mode, which has a high risk. To ensure device security, change the password periodically.

  4. Run commit

    The configuration is committed.

Result

The following section describes the changes in RIP neighbor relationships and data traffic volumes during the upgrade from RIP-1 to RIP-2 with authentication.

Scenario 1: Figure 7-5 shows a P2P topology, and an upgrade from RIP-1 to RIP-2 with authentication is performed on Device A and Device B that use the default configuration.
Figure 7-5 RIP neighbor relationship over a P2P link
With the default configuration, packet sending and receiving on one end of the P2P link are the same as those on the other end.
Interface 1 on Device A: (Default version or RIP-1-compatible version)
Send: Version 1
Receive: Version 1 and Version 2 broadcast and multicast

Interface 2 on Device B: (Default version or RIP-1-compatible version)
Send: Version 1
Receive: Version 1 and Version 2 broadcast and multicast
  • Step 1: Configure authentication on interface 1 of Device A.

    Interface 1 on Device A: (Default version or RIP-1-compatible version)
    Send: Version 1
    Receive: Version 1 and Version 2 broadcast and multicast with authentication
    
    Device B: (Default version or RIP-1-compatible version)
    Send: Version 1
    Receive: Version 1 and Version 2 broadcast and multicast

    Authentication applies to RIP-2 packets, not to RIP-1 packets; however, the packets exchanged between Device A and Device B are RIP-1 packets. Therefore, the RIP neighbor relationships and data traffic volumes remain unchanged after this step is performed.

  • Step 2: Configure the same authentication mode on interface 2 of Device B.
    Interface 1 on Device A: (Default version or RIP-1-compatible version)
    Send: Version 1
    Receive: Version 1 and Version 2 broadcast and multicast with authentication
    
    Interface 2 on Device B: (Default version or RIP-1-compatible version)
    Send: Version 1
    Receive: Version 1 and Version 2 broadcast and multicast with authentication

    Authentication applies to RIP-2 packets, not to RIP-1 packets; however, the packets exchanged between Device A and Device B are still RIP-1 packets. Therefore, the RIP neighbor relationships and data traffic volumes remain unchanged after this step is performed.

  • Step 3: Configure RIP-2 in broadcast mode on interface 1 of Device A.
    Interface 1 on Device A: (RIP-2 in broadcast mode)
    Send: Version 2 broadcast with authentication 
    Receive: Version 1 and Version 2 broadcast and multicast with authentication
    
    Interface 2 on Device B: (Default version or RIP-1-compatible version)
    Send: Version 1
    Receive: Version 1 and Version 2 broadcast and multicast with authentication

    Device A broadcasts RIP-2 packets with authentication to Device B. Because the same authentication mode is configured on Device B, Device B accepts these packets. Device B sends RIP-1 packets without authentication to Device A. Although RIP-2 in broadcast mode with authentication is configured on Device A, Device A also accepts RIP-1 packets.

    Therefore, the RIP neighbor relationships and data traffic volumes remain unchanged after this step is performed.
  • Step 4: Configure RIP-2 in broadcast mode on interface 2 of Device B.
    Interface 1 on Device A: (RIP-2 in broadcast mode)
    Send: Version 2 broadcast with authentication  
    Receive: Version 1 and Version 2 broadcast and multicast with authentication
    
    Interface 2 on Device B: (RIP-2 in broadcast mode)
    Send: Version 2 broadcast with authentication  
    Receive: Version 1 and Version 2 broadcast and multicast with authentication

    Device A and Device B broadcast RIP-2 packets with authentication. Because the same authentication mode is configured on Device A and Device B, they accept the broadcast RIP-2 packets with authentication. Therefore, the RIP neighbor relationships and data traffic volumes remain unchanged after this step is performed.

  • Step 5: Configure RIP-2 on interface 1 of Device A.
    Interface 1 on Device A: (RIP-2 in broadcast mode)
    Send: Version 2 multicast with authentication 
    Receive: Version 2 broadcast and multicast with authentication
    
    Interface 2 on Device B:
    Send: Version 2 broadcast with authentication 
    Receive: Version 1 and Version 2 broadcast and multicast with authentication

    Device A and Device B multicast RIP-2 packets with authentication. Because authentication is configured on Device B, Device B accepts the packets from Device A. Device B broadcasts RIP-2 packets with authentication to Device A, and Device A accepts these packets. Therefore, the RIP neighbor relationships and data traffic volumes remain unchanged after this step is performed.

  • Step 6: Configure RIP-2 on interface 2 of Device B.
    Interface 1 on Device A: (RIP-2)
    Send: Version 2 multicast with authentication
    Receive: Version 2 broadcast and multicast with authentication
    
    Interface 2 on Device B: (RIP-2)
    Send: Version 2 multicast with authentication
    Receive: Version 2 broadcast and multicast with authentication

    Device A and Device B multicast RIP-2 packets with authentication. Because the same authentication mode is configured on Device A and Device B, they accept the multicast RIP-2 packets with authentication from each other. Therefore, the RIP neighbor relationships and data traffic volumes remain unchanged after this step is performed.

Scenario 2: Figure 7-6 shows a broadcast topology, and an upgrade from RIP-1 (or RIP-1-compatible version) to RIP-2 is performed on devices.
Figure 7-6 RIP neighbor relationship over a broadcast link
Interface 2 on Device B: (Default version or RIP-1-compatible version)
Send: Version 1
Receive: Version 1 and version 2 broadcast and multicast 

Interface 1 on Device A: (RIP-1)
Send: Version 1
Receive: Version 1

Interface 3 on Device C: (RIP-1)
Send: Version 1
Receive: Version 1
NOTE:

All devices in the networking use interface-level RIP configuration.

  • Step 1: Configure authentication on Device A.

    Interface 2 on Device B: (Default version or RIP-1-compatible version)
    Send: Version 1
    Receive: Version 1 and version 2 broadcast and multicast 
    
    Interface 1 on Device A: (RIP-1)
    Send: Version 1
    Receive: Version 1
    
    Interface 3 on Device C: (RIP-1)
    Send: Version 1
    Receive: Version 1

    Authentication applies to RIP-2 packets, not to RIP-1 packets. Therefore, the authentication on a RIP-1 interface does not affect RIP-1 packets.

  • Step 2: Configure authentication on Device C.
    Interface 2 on Device B: (Default version or RIP-1-compatible version)
    Send: Version 1
    Receive: Version 1 and version 2 broadcast and multicast 
    
    Interface 1 on Device A: (RIP-1)
    Send: Version 1
    Receive: Version 1
    
    Interface 3 on Device C: (RIP-1)
    Send: Version 1
    Receive: Version 1

    Authentication applies to RIP-2 packets, not to RIP-1 packets. Therefore, the authentication on a RIP-1 interface does not affect RIP-1 packets.

  • Step 3: Configure authentication on Device B.
    Interface 2 on Device B: (Default version or RIP-1-compatible version)
    Send: Version 1
    Receive: Version 1 and version 2 broadcast and multicast with authentication
    
    Interface 1 on Device A: (RIP-1)
    Send: Version 1
    Receive: Version 1
    
    Interface 3 on Device C: (RIP-1)
    Send: Version 1
    Receive: Version 1

    Authentication applies to RIP-2 packets, not to RIP-1 packets. Therefore, the authentication on an interface that runs RIP of the default version (RIP-1) does not affect RIP-1 packets. If RIP-2 packets are received, they are accepted only after they are authenticated. No RIP-2 packets are sent in this scenario. Therefore, the RIP neighbor relationships and data traffic volumes remain unchanged after this step is performed.

  • Step 4: Run the undo rip version command on Device A.
    Interface 2 on Device B: (Default version or RIP-1-compatible version)
    Send: Version 1
    Receive: Version 1 and version 2 broadcast and multicast with authentication
    
    Interface 1 on Device A: (Default version or RIP-1-compatible version)
    Send: Version 1
    Receive: Version 1 and version 2 broadcast and multicast with authentication
    
    Interface 3 on Device C: (RIP-1)
    Send: Version 1
    Receive: Version 1

    If the undo rip version 1 command is run on the interface of Device B, the interface uses RIP of the default version (RIP-1) or RIP-1-compatible version. All the devices exchange RIP-1 packets in this scenario. Therefore, the RIP neighbor relationships and data traffic volumes remain unchanged after this step is performed.

  • Step 5: Run the undo rip version command on Device C.
    Interface 2 on Device B: (Default version or RIP-1-compatible version)
    Send: Version 1
    Receive: Version 1 and version 2 broadcast and multicast with authentication
    
    Interface 1 on Device A: (Default version or RIP-1-compatible version)
    Send: Version 1
    Receive: Version 1 and version 2 broadcast and multicast with authentication
    
    Interface 3 on Device C: (Default version or RIP-1-compatible version)
    Send: Version 1
    Receive: Version 1 and version 2 broadcast and multicast with authentication

    If the undo rip version 1 command is run on the interface of Device C, the interface uses RIP of the default version (RIP-1) or RIP-1-compatible version. All the devices exchange RIP-1 packets in this scenario. Therefore, the RIP neighbor relationships and data traffic volumes remain unchanged after this step is performed.

  • Step 6: Configure RIP-2 in broadcast mode on Device A.
    Interface 2 on Device B: (Default version or RIP-1-compatible version)
    Send: Version 1
    Receive: Version 1 and version 2 broadcast and multicast with authentication
    
    Interface 1 on Device A: (RIP-2 in broadcast mode)
    Send: Version 2 broadcast with authentication  
    Receive: Version 1 and version 2 broadcast and multicast with authentication
    
    Interface 3 on Device C: (Default version or RIP-1-compatible version)
    Send: Version 1
    Receive: Version 1 and version 2 broadcast and multicast with authentication

    If the rip version 2 broadcast command is run on the interface of Device A, the interface broadcasts RIP-2 packets with authentication. Because authentication is configured on other interfaces, all these interfaces accept the RIP-2 packets from Device A and respond with RIP-1 packets. Device A accepts these RIP-1 packets. Therefore, the RIP neighbor relationships and data traffic volumes remain unchanged after this step is performed.

  • Step 7: Configure RIP-2 in broadcast mode on Device C.
    Interface 2 on Device B: (Default version or RIP-1-compatible version)
    Send: Version 1
    Receive: Version 1 and version 2 broadcast and multicast with authentication
    
    Interface 1 on Device A: (RIP-2 in broadcast mode)
    Send: Version 2 broadcast with authentication  
    Receive: Version 1 and version 2 broadcast and multicast with authentication
    
    Interface 3 on Device C: (RIP-2 in broadcast mode)
    Send: Version 2 broadcast with authentication  
    Receive: Version 1 and version 2 broadcast and multicast with authentication

    If the rip version 2 broadcast command is run on the interface of Device C, the interface broadcasts RIP-2 packets with authentication. Because authentication is configured on other interfaces, all these interfaces accept the RIP-2 packets from Device C. Device B still broadcasts RIP-1 packets. Upon receipt of these packets, Device A and Device C accept them. Therefore, the RIP neighbor relationships and data traffic volumes remain unchanged after this step is performed.

  • Step 8: Configure RIP-2 in broadcast mode on Device B.
    Interface 2 on Device B: (RIP-2 in broadcast mode)
    Send: Version 2 broadcast with authentication  
    Receive: Version 1 and version 2 broadcast and multicast with authentication
    
    Interface 1 on Device A: (RIP-2 in broadcast mode)
    Send: Version 2 broadcast with authentication  
    Receive: Version 1 and version 2 broadcast and multicast with authentication
    
    Interface 3 on Device C: (RIP-2 in broadcast mode)
    Send: Version 2 broadcast with authentication  
    Receive: Version 1 and version 2 broadcast and multicast with authentication

    If the rip version 2 broadcast command is run on the interface of Device B, the interface broadcasts RIP-2 packets with authentication. Because authentication is configured on other interfaces, all these interfaces accept the RIP-2 packets from Device B and also broadcast RIP-2 packets with authentication. All the interfaces accept packets from each other. Therefore, the RIP neighbor relationships and data traffic volumes remain unchanged after this step is performed.

  • Step 9: Configure RIP-2 on Device A.
    Interface 2 on Device B: (RIP-2 in broadcast mode)
    Send: Version 2 broadcast with authentication  
    Receive: Version 1 and version 2 broadcast and multicast with authentication
    
    Interface 1 on Device A: (RIP-2)
    Send: Version 2 multicast with authentication 
    Receive: Version 2 broadcast and multicast with authentication
    
    Interface 3 on Device C: (RIP-2 in broadcast mode)
    Send: Version 2 broadcast with authentication  
    Receive: Version 1 and version 2 broadcast and multicast with authentication

    If the rip version 2 command is run on the interface of Device A, the interface multicasts RIP-2 packets with authentication. Because authentication is configured on other interfaces, all these interfaces accept the RIP-2 packets from Device A and broadcast RIP-2 packets with authentication. All the interfaces accept packets from each other. Therefore, the RIP neighbor relationships and data traffic volumes remain unchanged after this step is performed.

  • Step 10: Configure RIP-2 on Device C.
    Interface 2 on Device B: (RIP-2 in broadcast mode)
    Send: Version 2 broadcast with authentication  
    Receive: Version 1 and version 2 broadcast and multicast with authentication
    
    Interface 1 on Device A: (RIP-2)
    Send: Version 2 multicast with authentication 
    Receive: Version 2 broadcast and multicast with authentication
    
    Interface 3 on Device C: (RIP-2)
    Send: Version 2 multicast with authentication 
    Receive: Version 2 broadcast and multicast with authentication

    If the rip version 2 command is run on the interface of Device C, the interface multicasts RIP-2 packets with authentication. Because authentication is configured on other interfaces, all these interfaces accept the RIP-2 packets from Device C. Device B broadcasts RIP-2 packets with authentication, and Device A multicasts RIP-2 packets with authentication. All the interfaces accept packets from each other. Therefore, the RIP neighbor relationships and data traffic volumes remain unchanged after this step is performed.

  • Step 11: Configure RIP-2 on Device B.
    Interface 2 on Device B: (RIP-2)
    Send: Version 2 multicast with authentication 
    Receive: Version 2 broadcast and multicast with authentication
    
    Interface 1 on Device A: (RIP-2)
    Send: Version 2 multicast with authentication 
    Receive: Version 2 broadcast and multicast with authentication
    
    Interface 3 on Device C: (RIP-2)
    Send: Version 2 multicast with authentication 
    Receive: Version 2 broadcast and multicast with authentication

    If the rip version 2 command is run on the interface of Device B, the interface multicasts RIP-2 packets with authentication. Because authentication is configured on other interfaces, all these interfaces accept the RIP-2 packets from Device B and multicast RIP-2 packets with authentication. All the interfaces accept packets from each other. Therefore, the RIP neighbor relationships and data traffic volumes remain unchanged after this step is performed.

Scenario 3: RIP-2 or RIP-2 in broadcast mode is enabled on all devices.

In this scenario, if RIP authentication is configured on all devices, packets may be discarded in the following cases because authentication configuration synchronization cannot be ensured during authentication:
  1. RIP packets with authentication information are received by interfaces without authentication configuration.

  2. RIP packets without authentication information are received by interfaces with authentication configuration.

After all the configurations are performed, RIP packets are authenticated and accepted by all interfaces with authentication configuration. When the default timer is used, RIP considers a route invalid only if it does not receive any Update packet within six update intervals. Therefore, if all the configurations are completed within the six update intervals, no traffic is interrupted.

Configuring the Check on the Source Address in RIP Packets on the Broadcast Network

By default, RIP checks the source addresses of received packets, and the local RIP interface receives only the packets from the same network.

Context

RIP interfaces check the source address in received RIP packets. If the source address of the received RIP packet is from a network segment different from that of the local interface IP address, the local interface discards this RIP packet. This improves the network security.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run rip [ process-id ]

    A RIP process is created, and the RIP view is displayed.

  3. Run verify-source

    The source address check is configured for RIP packets on the broadcast network.

  4. Run commit

    The configuration is committed.

Configuring GTSM for RIP

Generalized TTL Security Mechanism (GTSM) defends against attacks by checking the TTL value.

Context

During network attacks, attackers may simulate RIP packets and continuously send them to a router. If the packets 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 control plane results in high CPU usage. Generalized TTL Security Mechanism (GTSM) defends against attacks by checking whether the time to live (TTL) value in each IP packet header is within a pre-defined range.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run rip valid-ttl-hops valid-ttl-hops-value [ vpn-instance vpn-instance-name ]

    GTSM is configured for RIP.

    NOTE:

    The valid TTL range of the detected packets is [ 255 -valid-ttl-hops-value + 1, 255 ].

  3. Run commit

    The configuration is committed.

  4. 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.

    You can enable the log function to record packet drop for troubleshooting.

    Perform the following configurations on the GTSM-enabled ME device:

    1. Run system-view

      The system view is displayed.

    2. 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.

    3. Run commit

      The configuration is committed.

Verifying the Configuration of RIP Network Security

After improving the security of a RIP network, verify information about RIP interfaces and the running status of RIP.

Prerequisites

Configurations have been made to improve security of a RIP network.

Procedure

  • Run the display rip process-id interface [ interface-type interface-number ] [ verbose ] command to check information about RIP interfaces.
  • Run the display rip process-id command to check the running status and configuration of the RIP process.

Example

Run the display rip process-id interface verbose command to view the authentication mode configured for RIP packets.

<HUAWEI> display rip 1 interface verbose
GigabitEthernet1/0/0 (1.1.1.2)
  State    : UP              MTU: 0
  Metricin : 0
  Metricout: 1
  Input    : Disabled        Output: Disabled                  
  Protocol : RIPv2 Multicast                                   
  Send     : RIPv2 Multicast Packets                           
  Receive  : RIPv2 Multicast Packets                           
  Poison-reverse                : Enabled                      
  Split-Horizon                 : Enabled                      
  Authentication type           : Md5 Non Standard       
  Replay Protection             : Disabled
  Max Packet Length             : 500                          

Run the display rip command. If the displayed Verify-source field is Enabled, the source address check has been configured.

<HUAWEI> display rip
  Public VPN-instance
    RIP process : 1
       RIP version   : 2
       Preference    : 100
       Checkzero     : Enabled
       Default-cost  : 0
       Summary       : Always
       Host-route    : Enabled
       Maximum number of balanced paths : 32
       Update time   : 100 sec     Age time             : 120 sec
       Suppress time : 140 sec      Garbage-collect time : 160 sec
       Graceful restart  : Disabled
       BFD               : Enabled
       Transmit-Interval : 100 ms
       Receive-Interval  : 100 ms
       Detect-Multiplier : 4
       Silent-interfaces : None
       Default-route : Disabled
       Verify-source : Enabled
       Networks : 
       10.0.0.0       
       Configured peers             : None
       Number of routes in database : 3
       Number of interfaces enabled : 1
       Number of VRRP interfaces    : 0
       Triggered updates sent       : 5
       Number of route changes      : 4
       Number of replies to queries : 1
  Total count for 1 process :
       Number of routes in database : 3
       Number of interfaces enabled : 1
       Number of VRRP interfaces    : 0
       Number of routes sendable in a periodic update : 1
       Number of routes sent in last periodic update : 0
Translation
Download
Updated: 2019-01-04

Document ID: EDOC1100059437

Views: 20934

Downloads: 15

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next