- play_arrow Overview
- play_arrow Basic BGP Configurations
- play_arrow Configuring BGP Session Attributes
- play_arrow Configuring BGP Session Policies
- play_arrow Enabling Load Balancing for BGP
- play_arrow Configuring Graceful Restart for BGP
- play_arrow Configuring Multiprotocol for a BGP Session
- play_arrow Configuring BGP CLNS
- play_arrow Using Route Reflectors and Confederations for BGP Networks
- play_arrow Configuring BGP Route Flap Damping and Error Handling
- play_arrow Configuring BGP-Based VPN
- play_arrow Monitoring and Troubleshooting
- play_arrow Configuration Statements and Operational Commands
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.
See Also
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.
Requirements
Before you begin:
Configure the router interfaces.
Configure an interior gateway protocol (IGP).
Overview
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 thesecretstatement. 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 calledext.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.
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.
set protocols bgp group ext type external set protocols bgp group ext peer-as 65530 set protocols bgp group ext neighbor 172.16.2.1 set routing-options autonomous-system 65533 set protocols bgp group ext authentication-key-chain bgp-auth set protocols bgp group ext authentication-algorithm md5 set security authentication-key-chains key-chain bgp-auth tolerance 30 set security authentication-key-chains key-chain bgp-auth key 0 secret this-is-the-secret-password set security authentication-key-chains key-chain bgp-auth key 0 start-time 2011-6-23.20:19:33-0700 set security authentication-key-chains key-chain bgp-auth key 1 secret this-is-another-secret-password set security authentication-key-chains key-chain bgp-auth key 1 start-time 2012-6-23.20:19:33-0700
Procedure
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:
Configure the local autonomous system.
content_copy zoom_out_map[edit routing-options] user@R1# set autonomous-system 65533
Configure one or more BGP groups.
content_copy zoom_out_map[edit protocols bgp group ext] user@R1# set type external user@R1# set peer-as 65530 user@R1# set neighbor 172.16.2.1
Configure authentication with multiple keys.
content_copy zoom_out_map[edit security authentication-key-chains key-chain bgp-auth] user@R1# set key 0 secret this-is-the-secret-password user@R1# set key 0 start-time 2011-6-23.20:19:33-0700 user@R1# set key 1 secret this-is-another-secret-password user@R1# set key 1 start-time 2012-6-23.20:19:33-0700
The start time of each key must be unique within the keychain.
Apply the authentication keychain to BGP, and set the hashing algorithm.
content_copy zoom_out_map[edit protocols bgp group ext] user@R1# set authentication-key-chain bgp-auth user@R1# set authentication-algorithm md5
(Optional) Apply a clock-skew tolerance value in seconds.
content_copy zoom_out_map[edit security authentication-key-chains key-chain bgp-auth] user@R1# set tolerance 30
Results
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.
user@R1# show protocols
bgp {
group ext {
type external;
peer-as 65530;
neighbor 172.16.2.1;
authentication-key-chain bgp-auth;
authentication-algorithm md5;
}
}
user@R1# show routing-options autonomous-system 65533;
user@R1# show security
authentication-key-chains {
key-chain bgp-auth {
tolerance 30;
key 0 {
secret $ABC123$ABC123
start-time “2011-6-23.20:19:33 -0700”;
}
key 1 {
secret $ABC123$ABC123
start-time “2012-6-23.20:19:33 -0700”;
}
}
}
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.
Verification
Confirm that the configuration is working properly.
- Verifying Authentication for the Neighbor
- Verifying That Authorization Messages Are Sent
- Checking Authentication Errors
- Verifying the Operation of the Keychain
Verifying Authentication for the Neighbor
Purpose
Make sure that the AutheKeyChain option
appears in the output of the show bgp neighbor command.
Action
From operational mode, enter the show bgp neighbor command.
user@R1> show bgp neighbor
Peer: 172.16.2.1+179 AS 65530 Local: 172.16.2.2+1222 AS 65533
Type: External State: Established Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ direct-lo0 ]
Options: <Preference PeerAS Refresh>
Options: <AutheKeyChain>
Authentication key is configured
Authentication key chain: jni
Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 172.16.2.1 Local ID: 10.255.124.35 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 0
Local Interface: fe-0/0/1.0
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 2
Received prefixes: 2
Suppressed due to damping: 0
Advertised prefixes: 1
Last traffic (seconds): Received 2 Sent 2 Checked 2
Input messages: Total 21 Updates 2 Refreshes 0 Octets 477
Output messages: Total 22 Updates 1 Refreshes 0 Octets 471
Output Queue[0]: 0Verifying That Authorization Messages Are Sent
Purpose
Confirm that BGP has the enhanced authorization option.
Action
From operational mode, enter the monitor traffic interface fe-0/0/1 command.
user@R1> monitor traffic interface fe-0/0/1 verbose output suppressed, use <detail> or <extensive> for full protocol decode Listening on fe-0/0/1, capture size 96 bytes 13:08:00.618402 In arp who-has 172.16.2.66 tell 172.16.2.69 13:08:02.408249 Out IP 172.16.2.2.1122 > 172.16.2.1.646: P 1889289217:1889289235(18) ack 2215740969 win 58486 <nop,nop,timestamp 167557 1465469,nop,Enhanced Auth keyid 0 diglen 12 digest: fe3366001f45767165f17037>: 13:08:02.418396 In IP 172.16.2.1.646 > 172.16.2.2.1122: P 1:19(18) ack 18 win 57100 <nop,nop,timestamp 1466460 167557,nop,Enhanced Auth keyid 0 diglen 12 digest: a18c31eda1b14b2900921675>: 13:08:02.518146 Out IP 172.16.2.2.1122 > 172.16.2.1.646: . ack 19 win 58468 <nop,nop,timestamp 167568 1466460,nop,Enhanced Auth keyid 0 diglen 12 digest: c3b6422eb6bd3fd9cf79742b> 13:08:28.199557 Out IP 172.16.2.2.nerv > 172.16.2.1.bgp: P 286842489:286842508(19) ack 931203976 win 57200 <nop,Enhanced Auth keyid 0 diglen 12 digest: fc0e42900a73736bcc07c1a4>: BGP, length: 19 13:08:28.209661 In IP 172.16.2.1.bgp > 172.16.2.2.nerv: P 1:20(19) ack 19 win 56835 <nop,Enhanced Auth keyid 0 diglen 12 digest: 0fc8578c489fabce63aeb2c3>: BGP, length: 19 13:08:28.309525 Out IP 172.16.2.2.nerv > 172.16.2.1.bgp: . ack 20 win 57181 <nop,Enhanced Auth keyid 0 diglen 12 digest: ef03f282fb2ece0039491df8> 13:08:32.439708 Out IP 172.16.2.2.1122 > 172.16.2.1.646: P 54:72(18) ack 55 win 58432 <nop,nop,timestamp 170560 1468472,nop,Enhanced Auth keyid 0 diglen 12 digest: 76e0cf926f348b726c631944>: 13:08:32.449795 In IP 172.16.2.1.646 > 172.16.2.2.1122: P 55:73(18) ack 72 win 57046 <nop,nop,timestamp 1469463 170560,nop,Enhanced Auth keyid 0 diglen 12 digest: dae3eec390d18a114431f4d8>: 13:08:32.549726 Out IP 172.16.2.2.1122 > 172.16.2.1.646: . ack 73 win 58414 <nop,nop,timestamp 170571 1469463,nop,Enhanced Auth keyid 0 diglen 12 digest: 851df771aee2ea7a43a0c46c> 13:08:33.719880 In arp who-has 172.16.2.66 tell 172.16.2.69 ^C 35 packets received by filter 0 packets dropped by kernel
Checking Authentication Errors
Purpose
Check the number of packets dropped by TCP because of authentication errors.
Action
From operational mode, enter the show system statistics tcp | match auth command.
user@R1> show system statistics tcp | match auth
0 send packets dropped by TCP due to auth errors
58 rcv packets dropped by TCP due to auth errorsVerifying the Operation of the Keychain
Purpose
Check the number of packets dropped by TCP because of authentication errors.
Action
From operational mode, enter the show security keychain detail command.
user@R1> show security keychain detail
keychain Active-ID Next-ID Transition Tolerance
Send Receive Send Receive
bgp-auth 3 3 1 1 1d 23:58 30
Id 3, Algorithm hmac-md5, State send-receive, Option basic
Start-time Wed Aug 11 16:28:00 2010, Mode send-receive
Id 1, Algorithm hmac-md5, State inactive, Option basic
Start-time Fri Aug 20 11:30:57 2010, Mode send-receive
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.
