Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

    Example: Configuring BFD Authentication for RIP

    Understanding BFD Authentication for RIP

    BFD enables rapid detection of communication failures between adjacent systems. By default, authentication for BFD sessions is disabled. However, when running BFD over Network Layer protocols, the risk of service attacks can be significant. We strongly recommend using authentication if you are running BFD over multiple hops or through insecure tunnels. Beginning with Junos OS Release 9.6, Junos OS supports authentication for BFD sessions running over RIP. BFD authentication is only supported in the domestic image and is not available in the export image.

    You authenticate BFD sessions by specifying an authentication algorithm and keychain, and then associating that configuration information with a security authentication keychain using the keychain name.

    The following sections describe the supported authentication algorithms, security keychains, and the level of authentication that can be configured:

    BFD Authentication Algorithms

    Junos OS supports the following algorithms for BFD authentication:

    • simple-password—Plain-text password. One to 16 bytes of plain text are used to authenticate the BFD session. One or more passwords can be configured. This method is the least secure and should be used only when BFD sessions are not subject to packet interception.
    • keyed-md5—Keyed Message Digest 5 hash algorithm for sessions with transmit and receive intervals greater than 100 ms. To authenticate the BFD session, keyed MD5 uses one or more secret keys (generated by the algorithm) and a sequence number that is updated periodically. With this method, packets are accepted at the receiving end of the session if one of the keys matches and the sequence number is greater than or equal to the last sequence number received. Although more secure than a simple password, this method is vulnerable to replay attacks. Increasing the rate at which the sequence number is updated can reduce this risk.
    • meticulous-keyed-md5—Meticulous keyed Message Digest 5 hash algorithm. This method works in the same manner as keyed MD5, but the sequence number is updated with every packet. Although more secure than keyed MD5 and simple passwords, this method might take additional time to authenticate the session.
    • keyed-sha-1—Keyed Secure Hash Algorithm I for sessions with transmit and receive intervals greater than 100 ms. To authenticate the BFD session, keyed SHA uses one or more secret keys (generated by the algorithm) and a sequence number that is updated periodically. The key is not carried within the packets. With this method, packets are accepted at the receiving end of the session if one of the keys matches and the sequence number is greater than the last sequence number received.
    • meticulous-keyed-sha-1—Meticulous keyed Secure Hash Algorithm I. This method works in the same manner as keyed SHA, but the sequence number is updated with every packet. Although more secure than keyed SHA and simple passwords, this method might take additional time to authenticate the session.

    Note: Nonstop active routing is not supported with meticulous-keyed-md5 and meticulous-keyed-sha-1 authentication algorithms. BFD sessions using these algorithms might go down after a switchover.

    Security Authentication Keychains

    The security authentication keychain defines the authentication attributes used for authentication key updates. When the security authentication keychain is configured and associated with a protocol through the keychain name, authentication key updates can occur without interrupting routing and signaling protocols.

    The authentication keychain contains one or more keychains. Each keychain contains one or more keys. Each key holds the secret data and the time at which the key becomes valid. The algorithm and keychain must be configured on both ends of the BFD session, and they must match. Any mismatch in configuration prevents the BFD session from being created.

    BFD allows multiple clients per session, and each client can have its own keychain and algorithm defined. To avoid confusion, we recommend specifying only one security authentication keychain.

    Strict Versus Loose Authentication

    By default, strict authentication is enabled and authentication is checked at both ends of each BFD session. Optionally, to smooth migration from nonauthenticated sessions to authenticated sessions, you can configure loose checking. When loose checking is configured, packets are accepted without authentication being checked at each end of the session. This feature is intended for transitional periods only.

    Example: Configuring BFD Authentication for RIP

    This example shows how to configure Bidirectional Forwarding Detection (BFD) authentication for a RIP network.

    Requirements

    No special configuration beyond device initialization is required before configuring this example.

    The devices must be running Junos OS Release 9.6 or later.

    Overview

    Only three steps are needed to configure authentication on a BFD session:

    1. Specify the BFD authentication algorithm for the RIP protocol.
    2. Associate the authentication keychain with the RIP protocol.
    3. Configure the related security authentication keychain.

    Figure 1 shows the topology used in this example.

    Figure 1: RIP BFD Authentication Network Topology

    RIP BFD Authentication Network
Topology

    CLI Quick Configuration shows the configuration for all of the devices in Figure 1. The section Step-by-Step Procedure describes the steps on Device R1.

    Configuration

    CLI Quick Configuration

    To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

    Device R1

    set interfaces fe-1/2/0 unit 1 family inet address 10.0.0.1/30set protocols bfd traceoptions file bfd-traceset protocols bfd traceoptions flag allset protocols rip group rip-group export advertise-routes-through-ripset protocols rip group rip-group neighbor fe-1/2/0.1set protocols rip group rip-group bfd-liveness-detection minimum-interval 600set protocols rip group rip-group bfd-liveness-detection authentication key-chain bfd-ripset protocols rip group rip-group bfd-liveness-detection authentication algorithm keyed-md5set protocols rip group rip-group bfd-liveness-detection authentication loose-checkset policy-options policy-statement advertise-routes-through-rip term 1 from protocol directset policy-options policy-statement advertise-routes-through-rip term 1 from protocol ripset policy-options policy-statement advertise-routes-through-rip term 1 then acceptset security authentication-key-chains key-chain bfd-rip key 53 secret $ABC123$ABC123set security authentication-key-chains key-chain bfd-rip key 53 start-time "2012-2-16.12:00:00 -0800"

    Device R2

    set interfaces fe-1/2/0 unit 2 family inet address 10.0.0.2/30set interfaces fe-1/2/1 unit 5 family inet address 10.0.0.5/30set protocols rip group rip-group export advertise-routes-through-ripset protocols rip group rip-group neighbor fe-1/2/0.2set protocols rip group rip-group neighbor fe-1/2/1.5set protocols rip group rip-group bfd-liveness-detection minimum-interval 600set protocols rip group rip-group bfd-liveness-detection authentication key-chain bfd-ripset protocols rip group rip-group bfd-liveness-detection authentication algorithm keyed-md5set protocols rip group rip-group bfd-liveness-detection authentication loose-checkset policy-options policy-statement advertise-routes-through-rip term 1 from protocol directset policy-options policy-statement advertise-routes-through-rip term 1 from protocol ripset policy-options policy-statement advertise-routes-through-rip term 1 then acceptset security authentication-key-chains key-chain bfd-rip key 53 secret $ABC123$ABC123set security authentication-key-chains key-chain bfd-rip key 53 start-time "2012-2-16.12:00:00 -0800"

    Device R3

    set interfaces fe-1/2/0 unit 6 family inet address 10.0.0.6/30set protocols rip group rip-group export advertise-routes-through-ripset protocols rip group rip-group neighbor fe-1/2/0.6set protocols rip group rip-group bfd-liveness-detection minimum-interval 600set protocols rip group rip-group bfd-liveness-detection authentication key-chain bfd-ripset protocols rip group rip-group bfd-liveness-detection authentication algorithm keyed-md5set protocols rip group rip-group bfd-liveness-detection authentication loose-checkset policy-options policy-statement advertise-routes-through-rip term 1 from protocol directset policy-options policy-statement advertise-routes-through-rip term 1 from protocol ripset policy-options policy-statement advertise-routes-through-rip term 1 then acceptset security authentication-key-chains key-chain bfd-rip key 53 secret $ABC123$ABC123set security authentication-key-chains key-chain bfd-rip key 53 start-time "2012-2-16.12:00:00 -0800"

    Step-by-Step Procedure

    The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

    To configure a BFD authentication:

    1. Configure the network interfaces.
      [edit interfaces]user@R1# set fe-1/2/0 unit 1 family inet address 10.0.0.1/30
    2. Create the RIP group and add the interface.

      To configure RIP in Junos OS, you must configure a group that contains the interfaces on which RIP is enabled. You do not need to enable RIP on the loopback interface.

      [edit protocols rip group rip-group]user@R1# set neighbor fe-1/2/0.1
    3. Create the routing policy to advertise both direct and RIP-learned routes.
      [edit policy-options policy-statement advertise-routes-through-rip term 1]user@R1# set from protocol directuser@R1# set from protocol ripuser@R1# set then accept
    4. Apply the routing policy.

      In Junos OS, you can only apply RIP export policies at the group level.

      [edit protocols rip group rip-group]user@R1# set export advertise-routes-through-rip
    5. Enable BFD.
      [edit protocols rip group rip-group]user@R1# set bfd-liveness-detection minimum-interval 600
    6. Specify the algorithm (keyed-md5, keyed-sha-1, meticulous-keyed-md5, meticulous-keyed-sha-1, or simple-password) to use.

      Note: Nonstop active routing is not supported with meticulous-keyed-md5 and meticulous-keyed-sha-1 authentication algorithms. BFD sessions using these algorithms might go down after a switchover.

      [edit protocols rip group rip-group]user@R1# set bfd-liveness-detection authentication algorithm keyed-md5
    7. Specify the keychain to be used to associate BFD sessions on RIP with the unique security authentication keychain attributes.

      The keychain you specify must match a keychain name configured at the [edit security authentication key-chains] hierarchy level.

      The algorithm and keychain must be configured on both ends of the BFD session, and they must match. Any mismatch in configuration prevents the BFD session from being created.

      [edit protocols rip group rip-group]user@R1# set bfd-liveness-detection authentication key-chain bfd-rip
    8. (Optional) Specify loose authentication checking if you are transitioning from nonauthenticated sessions to authenticated sessions.
      [edit protocols rip group rip-group]user@R1# set bfd-liveness-detection authentication loose-check
    9. Specify the unique security authentication information for BFD sessions:
      • The matching keychain name as specified in Step 7.
      • At least one key, a unique integer between 0 and 63. Creating multiple keys allows multiple clients to use the BFD session.
      • The secret data used to allow access to the session.
      • The time at which the authentication key becomes active, in the format yyyy-mm-dd.hh:mm:ss.
      [edit security authentication-key-chains key-chain bfd-rip]user@R1# set key 53 secret $ABC123$ABC123user@R1# set key 53 start-time "2012-2-16.12:00:00 -0800"
    10. Configure tracing operations to track BFD authentication.
      [edit protocols bfd traceoptions]user@R1# set file bfd-traceuser@R1# set flag all

    Results

    From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show policy-options, and show security commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

    user@R1# show interfaces
    fe-1/2/0 {unit 1 {family inet {address 10.0.0.1/30;}}}
    user@R1# show protocols
    bfd {traceoptions {file bfd-trace;flag all;}}
    rip {group rip-group {export advertise-routes-through-rip;bfd-liveness-detection {minimum-interval 600;}neighbor fe-1/2/0.1;}}
    user@R1# show policy-options
    policy-statement advertise-routes-through-rip {term 1 {from protocol [ direct rip ];then accept;}}
    user@R1# show security
    authentication-key-chains {key-chain bfd-rip {key 53 {secret $ABC123$ABC123start-time "2012-2-16.12:00:00 -0800";}}}

    If you are done configuring the device, enter commit from configuration mode.

    Verification

    Confirm that the configuration is working properly.

    Verifying That the BFD Sessions Are Authenticated

    Purpose

    Make sure that the BFD sessions are authenticated.

    Action

    From operational mode, enter the show bfd session detail command.

    user@R1> show bfd session detail
                                                      Detect   Transmit
    Address                  State     Interface      Time     Interval  Multiplier
    10.0.0.2                 Up        fe-1/2/0.1     1.800     0.600        3   
     Client RIP, TX interval 0.600, RX interval 0.600, Authenticate 
     Session up time 01:39:34
     Local diagnostic None, remote diagnostic None
     Remote state Up, version 1
     Logical system 6, routing table index 53
    
    1 sessions, 1 clients
    Cumulative transmit rate 1.7 pps, cumulative receive rate 1.7 pps
    

    Meaning

    Authenticate is displayed to indicate that BFD authentication is configured.

    Viewing Extensive Information About the BFD Authentication

    Purpose

    View the keychain name, the authentication algorithm and mode for each client in the session, and the BFD authentication configuration status.

    Action

    From operational mode, enter the show bfd session extensive command.

    user@R1> show bfd session extensive
                                                      Detect   Transmit
    Address                  State     Interface      Time     Interval  Multiplier
    10.0.0.2                 Up        fe-1/2/0.1     1.800     0.600        3   
     Client RIP, TX interval 0.600, RX interval 0.600, Authenticate 
            keychain bfd-rip, algo keyed-md5, mode loose
     Session up time 01:46:29
     Local diagnostic None, remote diagnostic None
     Remote state Up, version 1
     Logical system 6, routing table index 53
     Min async interval 0.600, min slow interval 1.000
     Adaptive async TX interval 0.600, RX interval 0.600
     Local min TX interval 0.600, minimum RX interval 0.600, multiplier 3
     Remote min TX interval 0.600, min RX interval 0.600, multiplier 3
     Local discriminator 225, remote discriminator 226
     Echo mode disabled/inactive
     Authentication enabled/active, keychain bfd-rip, algo keyed-md5, mode loose
      Session ID: 0x300501
    
    1 sessions, 1 clients
    Cumulative transmit rate 1.7 pps, cumulative receive rate 1.7 pps

    Meaning

    The output shows the keychain name, the authentication algorithm and mode for the client in the session, and the BFD authentication configuration status.

    Checking the BFD Trace File

    Purpose

    Use tracing operations to verify that BFD packets are being exchanged.

    Action

    From operational mode, enter the show log command.

    user@R1> show log bfd-trace
    Feb 16 10:26:32 PPM Trace: BFD periodic xmit to 10.0.0.2 (IFL 124, rtbl 53, single-hop port)
    Feb 16 10:26:32 Received Downstream TraceMsg (24) len 86:
    Feb 16 10:26:32    IfIndex (3) len 4: 0
    Feb 16 10:26:32    Protocol (1) len 1: BFD
    Feb 16 10:26:32    Data (9) len 61: (hex) 42 46 44 20 70 61 63 6b 65 74 20 66 72 6f 6d 20 31 30 2e
    Feb 16 10:26:32 PPM Trace: BFD packet from 10.0.0.1 (IFL 73, rtbl 56, ttl 255) absorbed
    Feb 16 10:26:32 Received Downstream TraceMsg (24) len 60:
    Feb 16 10:26:32    IfIndex (3) len 4: 0
    Feb 16 10:26:32    Protocol (1) len 1: BFD
    Feb 16 10:26:32    Data (9) len 35: (hex) 42 46 44 20 70 65 72 69 6f 64 69 63 20 78 6d 69 74 20 6f
    ...

    Meaning

    The output shows the normal functioning of BFD.

    Modified: 2016-09-06