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 Static Routes

    Understanding BFD Authentication for Static Route Security

    Bidirectional Forwarding Detection (BFD) enables rapid detection of communication failures between adjacent systems. By default, authentication for BFD sessions is disabled. However, when you run BFD over Network Layer protocols, the risk of service attacks can be significant.

    Note: 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 IPv4 and IPv6 static routes. BFD authentication is not supported on MPLS OAM sessions. BFD authentication is only supported in the Canada and United States version of the Junos OS image and is not available in the export version.

    Note: EX3300 supports BFD over static routes only.

    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 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 (NSR) 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 Securing Static Routes

    This example shows how to configure Bidirectional Forwarding Detection (BFD) authentication for static routes.

    Requirements

    Junos OS Release 9.6 or later (Canda and United States version).

    BFD authentication is only supported in the Canada and United States version of the Junos OS image and is not available in the export version.

    Overview

    You can configure authentication for BFD sessions running over IPv4 and IPv6 static routes. Routing instances and logical systems are also supported.

    The following steps are needed to configure authentication on a BFD session:

    1. Specify the BFD authentication algorithm for the static route.
    2. Associate the authentication keychain with the static route.
    3. Configure the related security authentication keychain. This must be configured on the main router.

    Tip: We recommend that you specify loose authentication checking if you are transitioning from nonauthenticated sessions to authenticated sessions.

    [edit]user@host> set routing-options static route ipv4 bfd-liveness-detection authentication loose-check

    Figure 1 shows the sample network.

    Figure 1: Customer Routes Connected to a Service Provider

    Customer Routes Connected
to a Service Provider

    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, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

    Device B

    set interfaces ge-1/2/0 unit 0 description B->Dset interfaces ge-1/2/0 unit 0 family inet address 172.16.1.1/24set interfaces lo0 unit 57 family inet address 10.0.0.1/32set interfaces lo0 unit 57 family inet address 10.0.0.2/32set routing-options static route 192.168.47.0/24 next-hop 172.16.1.2set routing-options static route 192.168.47.0/24 bfd-liveness-detection minimum-interval 1000set routing-options static route 192.168.47.0/24 bfd-liveness-detection description Site-xxx set routing-options static route 192.168.47.0/24 bfd-liveness-detection authentication key-chain bfd-kc4set routing-options static route 192.168.47.0/24 bfd-liveness-detection authentication algorithm keyed-sha-1set security authentication-key-chains key-chain bfd-kc4 key 5 secret "$ABC123$ABC123$ABC123" set security authentication-key-chains key-chain bfd-kc4 key 5 start-time "2011-1-1.12:00:00 -0800"

    Device D

    set interfaces ge-1/2/0 unit 1 description D->Bset interfaces ge-1/2/0 unit 1 family inet address 172.16.1.2/24set interfaces lo0 unit 2 family inet address 192.168.47.5/32set interfaces lo0 unit 2 family inet address 192.168.47.6/32set routing-options static route 0.0.0.0/0 next-hop 172.16.1.1set routing-options static route 0.0.0.0/0 bfd-liveness-detection minimum-interval 1000set routing-options static route 0.0.0.0/0 bfd-liveness-detection authentication key-chain bfd-kc4set routing-options static route 0.0.0.0/0 bfd-liveness-detection authentication algorithm keyed-sha-1set security authentication-key-chains key-chain bfd-kc4 key 5 secret "$ABC123$ABC123$ABC123" set security authentication-key-chains key-chain bfd-kc4 key 5 start-time "2011-1-1.12:00:00 -0800"

    Step-by-Step Procedure

    The following example requires that you 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 BFD for static routes:

    1. On Device B, configure the interfaces.
      [edit interfaces]user@B# set ge-1/2/0 unit 0 description B->Duser@B# set ge-1/2/0 unit 0 family inet address 172.16.1.1/24
      user@B# set lo0 unit 57 family inet address 10.0.0.1/32user@B# set lo0 unit 57 family inet address 10.0.0.2/32
    2. On Device B, create a static route and set the next-hop address.
      [edit routing-options]user@B# set static route 192.168.47.0/24 next-hop 172.16.1.2
    3. On Device B, configure BFD for the static route.
      [edit routing-options]user@B# set static route 192.168.47.0/24 bfd-liveness-detection minimum-interval 1000set routing-options static route 192.168.47.0/24 bfd-liveness-detection description Site-xxx
    4. On Device B, specify the algorithm (keyed-md5, keyed-sha-1, meticulous-keyed-md5, meticulous-keyed-sha-1, or simple-password) to use for BFD authentication on the static route.
      [edit routing-options]user@B# set static route 192.168.47.0/24 bfd-liveness-detection authentication algorithm keyed-sha-1

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

    5. On Device B, specify the keychain to be used to associate BFD sessions on the specified route with the unique security authentication keychain attributes.

      This should match the keychain name configured at the [edit security authentication key-chains] hierarchy level.

      [edit routing-options]user@B# set static route 192.168.47.0/24 bfd-liveness-detection authentication key-chain bfd-kc4
    6. On Device B, specify the unique security authentication information for BFD sessions:
      • The matching keychain name as specified in Step 5.
      • 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-kc4]user@B# set key 5 secret "$ABC123$ABC123$ABC123" user@B# set key 5 start-time "2011-1-1.12:00:00 -0800"
    7. If you are done configuring Device B, commit the configuration.
      [edit]user@B# commit
    8. Repeat the configuration on Device D.

      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.

    Results

    Confirm your configuration by issuing the show interfaces, show routing-options, and show security commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

    Device B

    user@B# show interfaces
    ge-1/2/0 {unit 0 {description B->D;family inet {address 172.16.1.1/24;}}}
    lo0 {unit 57 {family inet {address 10.0.0.1/32;address 10.0.0.2/32;}}}
    user@B# show routing-options
    static {route 192.168.47.0/24 {next-hop 172.16.1.2;bfd-liveness-detection {description Site- xxx;minimum-interval 1000;authentication {key-chain bfd-kc4;algorithm keyed-sha-1;}}}}
    user@B# show security
    authentication-key-chains {key-chain bfd-kc4 {key 5 {secret "$ABC123$ABC123$ABC123"; ## SECRET-DATAstart-time "2011-1-1.12:00:00 -0800";}}}

    Verification

    Confirm that the configuration is working properly.

    Verifying That BFD Sessions Are Up

    Purpose

    Verify that the BFD sessions are up.

    Action

    From operational mode, enter the show bfd session command.

    user@B> show bfd session
                                                      Detect   Transmit
    Address                  State     Interface      Time     Interval  Multiplier
    172.16.1.2               Up        ge-1/2/0.0     3.000     1.000        3   
    
    1 sessions, 1 clients
    Cumulative transmit rate 1.0 pps, cumulative receive rate 1.0 pps

    Meaning

    The command output shows that the BFD session is up.

    Viewing Details About the BFD Session

    Purpose

    View details about the BFD sessions and make sure that authentication is configured.

    Action

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

    user@B> show bfd session detail
                                                      Detect   Transmit
    Address                  State     Interface      Time     Interval  Multiplier
    172.16.1.2               Up        ge-1/2/0.0     3.000     1.000        3   
     Client Static, TX interval 1.000, RX interval 1.000, Authenticate 
     Session up time 00:53:58
     Local diagnostic NbrSignal, remote diagnostic None
     Remote state Up, version 1
     Logical system 9, routing table index 22
    
    1 sessions, 1 clients
    Cumulative transmit rate 1.0 pps, cumulative receive rate 1.0 pps

    Meaning

    In the command output, Authenticate is displayed to indicate that BFD authentication is configured.

    Viewing Extensive BFD Session Information

    Purpose

    View more detailed information about the BFD sessions.

    Action

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

    user@B> show bfd session extensive
    Address                  State     Interface      Time     Interval  Multiplier
    172.16.1.2               Up        ge-1/2/0.0     3.000     1.000        3   
     Client Static, description Site-xxx, TX interval 1.000, RX interval 1.000, Authenticate 
            keychain bfd-kc4, algo keyed-sha-1, mode strict
     Session up time 01:39:45
     Local diagnostic NbrSignal, remote diagnostic None
     Remote state Up, version 1
     Logical system 9, routing table index 22
     Min async interval 1.000, min slow interval 1.000
     Adaptive async TX interval 1.000, RX interval 1.000
     Local min TX interval 1.000, minimum RX interval 1.000, multiplier 3
     Remote min TX interval 1.000, min RX interval 1.000, multiplier 3
     Local discriminator 3, remote discriminator 4
     Echo mode disabled/inactive
     Authentication enabled/active, keychain bfd-kc4, algo keyed-sha-1, mode strict
    
    1 sessions, 1 clients
    Cumulative transmit rate 1.0 pps, cumulative receive rate 1.0 pps
    

    Meaning

    In the command output, Authenticate is displayed to indicate that BFD authentication is configured. The output for the extensive command provides the keychain name, the authentication algorithm, and the mode for each client in the session.

    Note: The description Site- <xxx> is supported only on the SRX Series devices.

    If each client has more than one description field, then it displays "and more" along with the first description field.

    Modified: 2016-07-05