Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


BGP Route Authentication

Understanding Router Authentication for BGP

The use of router and route authentication and route integrity greatly mitigates the risk of being attacked by a machine or router that has been configured to share incorrect routing information with another router. In this kind of attack, the attacked router can be tricked into creating a routing loop, or the attacked router’s routing table can be greatly increased thus impacting performance, or routing information can be redirected to a place in the network for the attacker to analyze it. Bogus route advertisements can be sent out on a segment. These updates can be accepted into the routing tables of neighbor routers unless an authentication mechanism is in place to verify the source of the routes.

Router and route authentication enables routers to share information only if they can verify that they are talking to a trusted source, based on a password (key). In this method, a hashed key is sent along with the route being sent to another router. The receiving router compares the sent key to its own configured key. If they are the same, it accepts the route. By using a hashing algorithm, the key is not sent over the wire in plain text. Instead, a hash is calculated using the configured key. The routing update is used as the input text, along with the key, into the hashing function. This hash is sent along with the route update to the receiving router. The receiving router compares the received hash with a hash it generates on the route update using the preshared key configured on it. If the two hashes are the same, the route is assumed to be from a trusted source. The key is known only to the sending and receiving routers.

To further strengthen security, you can configure a series of authentication keys (a keychain). Each key has a unique start time within the keychain. Keychain authentication allows you to change the password information periodically without bringing down peering sessions. This keychain authentication method is referred to as hitless because the keys roll over from one to the next without resetting any peering sessions or interrupting the routing protocol.

The sending peer uses the following rules to identify the active authentication key:

  • The start time is less than or equal to the current time (in other words, not in the future).

  • The start time is greater than that of all other keys in the chain whose start time is less than the current time (in other words, closest to the current time).

The receiving peer determines the key with which it authenticates based on the incoming key identifier.

The sending peer identifies the current authentication key based on a configured start time and then generates a hash value using the current key. The sending peer then inserts a TCP-enhanced authentication option object into the BGP update message. The object contains an object ID (assigned by IANA), the object length, the current key, and a hash value.

The receiving peer examines the incoming TCP-enhanced authentication option, looks up the received authentication key, and determines whether the key is acceptable based on the start time, the system time, and the tolerance parameter. If the key is accepted, the receiving peer calculates a hash and authenticates the update message.

Initial application of a keychain to a TCP session causes the session to reset. However, once the keychain is applied, the addition or removal of a password from the keychain does not cause the TCP session to reset. Also, the TCP session does not reset when the keychain changes from one authentication algorithm to another.

TCP Authentication

Typically, you configure TCP authentication at the following hierarchy levels:

  • [edit protocols bgp]

  • [edit protocols bgp group group-name]

  • [edit protocols bgp group group-name neighbor address]

TCP Authentication and Prefix Subnets

Junos devices support TCP authentication to BGP peers that are discovered through allowed prefix subnets configured in a BGP group.

To configure prefix-based authentication for TCP-AO or TCP MD5 for BGP sessions, you can configure the allow (all | prefix-list) statement at the following hierarchies:

  • [edit protocols bgp group group-name]

  • [edit protocols bgp group group-name dynamic-neighbor dyn-name]

For more information about TCP authentication, see TCP.

Example: Configuring Router Authentication for BGP

All BGP protocol exchanges can be authenticated to guarantee that only trusted routing devices participate in autonomous system (AS) routing updates. By default, authentication is disabled.


Before you begin:

  • Configure the router interfaces.

  • Configure an interior gateway protocol (IGP).


When you configure authentication, the algorithm creates an encoded checksum that is included in the transmitted packet. The receiving routing device uses an authentication key (password) to verify the packet’s checksum.

This example includes the following statements for configuring and applying the keychain:

  • key—A keychain can have multiple keys. Each key within a keychain must be identified by a unique integer value. The range of valid identifier values is from 0 through 63.

    The key can be up to 126 characters long. Characters can include any ASCII strings. If you include spaces, enclose all characters in quotation marks (“ ”).

  • tolerance—(Optional) For each keychain, you can configure a clock-skew tolerance value in seconds. The clock-skew tolerance is applicable to the receiver accepting keys for BGP updates. The configurable range is 0 through 999,999,999 seconds. During the tolerance period, either the current or previous password is acceptable.

  • key-chain—For each keychain, you must specify a name. This example defines one keychain: bgp-auth. You can have multiple keychains on a routing device. For example, you can have a keychain for BGP, a keychain for OSPF, and a keychain for LDP.

  • secret—For each key in the keychain, you must set a secret password. This password can be entered in either encrypted or plain text format in the secret statement. It is always displayed in encrypted format.

  • start-time—Each key must specify a start time in UTC format. Control gets passed from one key to the next. When a configured start time arrives (based on the routing device’s clock), the key with that start time becomes active. Start times are specified in the local time zone for a routing device and must be unique within the keychain.

  • authentication-key-chain—Enables you to apply a keychain at the global BGP level for all peers, for a group, or for a neighbor. This example applies the keychain to the peers defined in the external BGP (EBGP) group called ext.

  • authentication-algorithm—For each keychain, you can specify a hashing algorithm. The algorithm can be AES-128, MD5, or SHA-1.

    You associate a keychain and an authentication algorithm with a BGP neighboring session.

This example configures a keychain named bgp-auth. Key 0 will be sent and accepted starting at 2011-6-23.20:19:33 -0700, and will stop being sent and accepted when the next key in the keychain (key 1) becomes active. Key 1 becomes active one year later at 2012-6-23.20:19:33 -0700, and will not stop being sent and accepted unless another key is configured with a start time that is later than the start time of key 1. A clock-skew tolerance of 30 seconds applies to the receiver accepting the keys. During the tolerance period, either the current or previous key is acceptable. The keys are shared-secret passwords. This means that the neighbors receiving the authenticated routing updates must have the same authentication keychain configuration, including the same keys (passwords). So Router R0 and Router R1 must have the same authentication-key-chain configuration if they are configured as peers. This example shows the configuration on only one of the routing devices.

Topology Diagram

Figure 1 shows the topology used in this example.

Figure 1: Authentication for BGPAuthentication for BGP


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.


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 Junos OS CLI User Guide.

To configure Router R1 to accept route filters from Device CE1 and perform outbound route filtering using the received filters:

  1. Configure the local autonomous system.

  2. Configure one or more BGP groups.

  3. Configure authentication with multiple keys.

    The start time of each key must be unique within the keychain.

  4. Apply the authentication keychain to BGP, and set the hashing algorithm.

  5. (Optional) Apply a clock-skew tolerance value in seconds.


From configuration mode, confirm your configuration by entering the show protocols, 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.

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

Repeat the procedure for every BGP-enabled device in the network, using the appropriate interface names and addresses for each BGP-enabled device.


Confirm that the configuration is working properly.

Verifying Authentication for the Neighbor


Make sure that the AutheKeyChain option appears in the output of the show bgp neighbor command.


From operational mode, enter the show bgp neighbor command.

Verifying That Authorization Messages Are Sent


Confirm that BGP has the enhanced authorization option.


From operational mode, enter the monitor traffic interface fe-0/0/1 command.

Checking Authentication Errors


Check the number of packets dropped by TCP because of authentication errors.


From operational mode, enter the show system statistics tcp | match auth command.

Verifying the Operation of the Keychain


Check the number of packets dropped by TCP because of authentication errors.


From operational mode, enter the show security keychain detail command.

Release History Table
Starting in Junos OS Evolved Release 22.4R1, you can configure TCP-AO or TCP MD5 authentication with an IP subnet to include the entire range of addresses under that subnet.
Starting in Junos OS Evolved Release 22.4R1, TCP authentication is VRF aware.
Starting in Junos OS Release 19.1R1, Junos OS extends support for TCP authentication to BGP peers that are discovered through allowed prefix subnets configured in a BGP group.