Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Configuring OSPF Authentication

Understanding IPsec Authentication for OSPF Packets on EX Series Switches

IP Security (IPsec) provides a secure way to authenticate senders and encrypt IP version 4 (IPv4) traffic between network devices. IPsec offers network administrators for Juniper Networks EX Series Ethernet Switches and their users the benefits of data confidentiality, data integrity, sender authentication, and anti-replay services.

IPsec is a framework for ensuring secure private communication over IP networks and is based on standards developed by the International Engineering Task Force (IETF). IPsec provides security services at the network layer of the Open Systems Interconnection (OSI) model by enabling a system to select required security protocols, determine the algorithms to use for the security services, and implement any cryptographic keys required to provide the requested services. You can use IPsec to protect one or more paths between a pair of hosts, between a pair of security gateways (such as switches), or between a security gateway and a host.

OSPF version 3 (OSPFv3), unlike OSPF version 2 (OSPFv2), does not have a built-in authentication method and relies on IPsec to provide this functionality. You can secure specific OSPFv3 interfaces and protect OSPFv3 virtual links.

Authentication Algorithms

Authentication is the process of verifying the identity of the sender. Authentication algorithms use a shared key to verify the authenticity of the IPsec devices. The Juniper Networks Junos operating system (Junos OS) uses the following authentication algorithms:

  • Message Digest 5 (MD5) uses a one-way hash function to convert a message of arbitrary length to a fixed-length message digest of 128 bits. Because of the conversion process, it is mathematically infeasible to calculate the original message by computing it backwards from the resulting message digest. Likewise, a change to a single character in the message will cause it to generate a very different message digest number.

    To verify that the message has not been tampered with, Junos OS compares the calculated message digest against a message digest that is decrypted with a shared key. Junos OS uses the MD5 hashed message authentication code (HMAC) variant that provides an additional level of hashing. MD5 can be used with an authentication header (AH) and Encapsulating Security Payload (ESP).

  • Secure Hash Algorithm 1 (SHA-1) uses a stronger algorithm than MD5. SHA-1 takes a message of less than 264 bits in length and produces a 160-bit message digest. The large message digest ensures that the data has not been changed and that it originates from the correct source. Junos OS uses the SHA-1 HMAC variant that provides an additional level of hashing. SHA-1 can be used with AH, ESP, and Internet Key Exchange (IKE).

Encryption Algorithms

Encryption encodes data into a secure format so that it cannot be deciphered by unauthorized users. As with authentication algorithms, a shared key is used with encryption algorithms to verify the authenticity of IPsec devices. Junos OS uses the following encryption algorithms:

  • Data Encryption Standard cipher-block chaining (DES-CBC) is a symmetric secret-key block algorithm. DES uses a key size of 64 bits, where 8 bits are used for error detection and the remaining 56 bits provide encryption. DES performs a series of simple logical operations on the shared key, including permutations and substitutions. CBC takes the first block of 64 bits of output from DES, combines this block with the second block, feeds this back into the DES algorithm, and repeats this process for all subsequent blocks.

  • Triple DES-CBC (3DES-CBC) is an encryption algorithm that is similar to DES-CBC but provides a much stronger encryption result because it uses three keys for 168-bit (3 x 56-bit) encryption. 3DES works by using the first key to encrypt the blocks, the second key to decrypt the blocks, and the third key to reencrypt the blocks.

IPsec Protocols

IPsec protocols determine the type of authentication and encryption applied to packets that are secured by the switch. Junos OS supports the following IPsec protocols:

  • AH—Defined in RFC 2402, AH provides connectionless integrity and data origin authentication for IPv4. It also provides protection against replays. AH authenticates as much of the IP header as possible, as well as the upper-level protocol data. However, some IP header fields might change in transit. Because the value of these fields might not be predictable by the sender, they cannot be protected by AH. In an IP header, AH can be identified with a value of 51 in the Protocol field of an IPv4 packet.

  • ESP—Defined in RFC 2406, ESP can provide encryption and limited traffic flow confidentiality or connectionless integrity, data origin authentication, and an anti-replay service. In an IP header, ESP can be identified with a value of 50 in the Protocol field of an IPv4 packet.

Security Associations

An IPsec consideration is the type of security association (SA) that you wish to implement. An SA is a set of IPsec specifications that are negotiated between devices that are establishing an IPsec relationship. These specifications include preferences for the type of authentication, encryption, and IPsec protocol to be used when establishing the IPsec connection. An SA can be either unidirectional or bidirectional, depending on the choices made by the network administrator. An SA is uniquely identified by a Security Parameter Index (SPI), an IPv4 or IPv6 destination address, and a security protocol (AH or ESP) identifier.

IPsec Modes

Junos OS supports the following IPsec modes:

  • Tunnel mode is supported for both AH and ESP in Junos OS. In tunnel mode, the SA and associated protocols are applied to tunneled IPv4 or IPv6 packets. For a tunnel mode SA, an outer IP header specifies the IPsec processing destination and an inner IP header specifies the ultimate destination for the packet. The security protocol header appears after the outer IP header and before the inner IP header. In addition, there are slight differences for tunnel mode when you implement it with AH and ESP:

    • For AH, portions of the outer IP header are protected, as well as the entire tunneled IP packet.

    • For ESP, only the tunneled packet is protected, not the outer header.

    When one side of an SA is a security gateway (such as a switch), the SA must use tunnel mode. However, when traffic (for example, SNMP commands or BGP sessions) is destined for a switch, the system acts as a host. Transport mode is allowed in this case because the system does not act as a security gateway and does not send or receive transit traffic.

    Note:

    Tunnel mode is not supported for OSPF v3 control packet authentication.

  • Transport mode provides an SA between two hosts. In transport mode, the protocols provide protection primarily for upper-layer protocols. A transport mode security protocol header appears immediately after the IP header and any options and before any higher-layer protocols (for example, TCP or UDP). There are slight differences for transport mode when you implement it with AH and ESP:

    • For AH, selected portions of the IP header are protected, as well as selected portions of the extension headers and selected options within the IPv4 header.

    • For ESP, only the higher-layer protocols are protected, not the IP header or any extension headers preceding the ESP header.

Understanding OSPFv2 Authentication

All OSPFv2 protocol exchanges can be authenticated to guarantee that only trusted routing devices participate in the autonomous system’s routing. By default, OSPFv2 authentication is disabled.

Note:

OSPFv3 does not have a built-in authentication method and relies on IP Security (IPsec) to provide this functionality.

You can enable the following authentication types:

  • Simple authentication—Authenticates by using a plain-text password that is included in the transmitted packet. The receiving routing device uses an authentication key (password) to verify the packet.

  • MD5 authentication—Authenticates by using an encoded MD5 checksum that is included in the transmitted packet. The receiving routing device uses an authentication key (password) to verify the packet.

    You define an MD5 key for each interface. If MD5 is enabled on an interface, that interface accepts routing updates only if MD5 authentication succeeds. Otherwise, updates are rejected. The routing device only accepts OSPFv2 packets sent using the same key identifier (ID) that is defined for that interface.

  • IPsec authentication (beginning with Junos OS Release 8.3)—Authenticates OSPFv2 interfaces, the remote endpoint of a sham link, and the OSPFv2 virtual link by using manual security associations (SAs) to ensure that a packet’s contents are secure between the routing devices. You configure the actual IPsec authentication separately.

    Note:

    You can configure IPsec authentication together with either MD5 or simple authentication.

    The following restrictions apply to IPsec authentication for OSPFv2:

    • Dynamic Internet Key Exchange (IKE) SAs are not supported.

    • Only IPsec transport mode is supported. Tunnel mode is not supported.

    • Because only bidirectional manual SAs are supported, all OSPFv2 peers must be configured with the same IPsec SA. You configure a manual bidirectional SA at the [edit security ipsec] hierarchy level.

    • You must configure the same IPsec SA for all virtual links with the same remote endpoint address, for all neighbors on OSPF nonbroadcast multiaccess (NBMA) or point-to-multipoint links, and for every subnet that is part of a broadcast link.

    • OSPFv2 peer interfaces are not supported.

Because OSPF performs authentication at the area level, all routing devices within the area must have the same authentication and corresponding password (key) configured. For MD5 authentication to work, both the receiving and transmitting routing devices must have the same MD5 key. In addition, a simple password and MD5 key are mutually exclusive. You can configure only one simple password, but multiple MD5 keys.

As part of your security measures, you can change MD5 keys. You can do this by configuring multiple MD5 keys, each with a unique key ID, and setting the date and time to switch to the new key. Each unique MD5 key has a unique ID. The ID is used by the receiver of the OSPF packet to determine which key to use for authentication. The key ID, which is required for MD5 authentication, specifies the identifier associated with the MD5 key.

Starting in Junos OS Release 22.4R1, we support advertising OSPF MD5 authentication with multiple active keys to send packets with a maximum limit of two keys per interface. Having multiple keys active at any one time at the interface enables the smooth transition from one key to another for OSPF. You can delete old keys without any impact on the OSPF session.

Starting in Junos OS Release 23.3R1 and Junos OS Evolved Release 23.3R1, you can enable OSPFv2 HMAC-SHA1 authentication with keychain to authenticate packets reaching or originating from an OSPF interface. This ensures smooth transition from one key to another for OSPFv2 with enhanced security. You can enable OSPFv2 to send packets authenticated with only the latest MD5 key once all the neighbours switch to the latest configured key. Prior to this release, we support advertising authenticated OSPF packets always with multiple active MD5 keys with a maximum limit of two keys per interface.

HMAC-SHA1 authentication for OSPFv2 does not support:

  • Keychain with no active keys.

  • Migration from other existing authentication types to keychain with hitless session.

  • Migration from no authentication to keychain with hitless session.

  • Keyed MD5 as a part of Keychain configuration.

Note:
  • When multi-active MD5 optimization with delete-if-not-inuse configuration statement is enabled and once the authentication negotiation happens with its neighbors, from then on the device uses only active key for transmission for that negotiated neighbor. That is, we do not support rolling back to the old key.

    For example: R0 and R1 are configured with key-id 1 as delete-if-not-inuse and key-id 2. Later, if R1 is configured to remove key-id 2, then R0 does not rollback to using both keys (key-id 1 and key-id 2) for transmission.

  • Keychain activeness is based on the absolute time (wall clock) and the wall clock might go backward after commit. This type of error does not reflect at the time of commit. So it is important to have the system time synchronized on all the devices when keychain is active on a OSPF session.

Starting in Junos OS Evolved Release 24.2R1, you can enable OSPFv2 keychain module with HMAC-SHA2 (OSPFv2 HMAC-SHA2) authentication to authenticate packets reaching or originating from an OSPF interface. HMAC SHA2 algorithms include HMAC-SHA2-256, HMAC-SHA2-384, and HMAC-SHA2-512 as defined in RFC 5709. We support these algorithms along with HMAC-SHA2-224. This feature ensures smooth transition from one key to another for OSPFv2 with enhanced security. We also support HMAC-SHA1 and HMAC-SHA2 authentication for virtual and sham links.

HMAC-SHA2 authentication for OSPFv2 does not support:

  • Keychain with no active keys.

  • Migration from other existing authentication types to keychain with hitless session.

  • Migration from no authentication to keychain with hitless session.

Note:

  • SHA1 (without HMAC) algorithm under keychain configuration is not supported.

  • It is important to have the system time synchronized on all the devices when keychain is active on a OSPF session.

See Also

Understanding OSPFv3 Authentication

OSPFv3 does not have a built-in authentication method and relies on the IP Security (IPsec) suite to provide this functionality. IPsec provides such functionality as authentication of origin, data integrity, confidentiality, replay protection, and nonrepudiation of source. You can use IPsec to secure specific OSPFv3 interfaces and protect OSPFv3 virtual links.

Note:

You configure the actual IPsec authentication separately from your OSPFv3 configuration and then apply IPsec to the OSPFv3 interfaces or OSPFv3 virtual links.

OSPFv3 uses the IP authentication header (AH) and the IP Encapsulating Security Payload (ESP) portions of the IPsec Protocol to authenticate routing information between peers. AH can provide connectionless integrity and data origin authentication. It also provides protection against replays. AH authenticates as much of the IP header as possible, as well as the upper-level protocol data. However, some IP header fields might change in transit. Because the value of these fields might not be predictable by the sender, they cannot be protected by AH. ESP can provide encryption and limited traffic flow confidentiality or connectionless integrity, data origin authentication, and an anti-replay service.

IPsec is based on security associations (SAs). An SA is a set of IPsec specifications that are negotiated between devices that are establishing an IPsec relationship. This simplex connection provides security services to the packets carried by the SA. These specifications include preferences for the type of authentication, encryption, and IPsec protocol to be used when establishing the IPsec connection. An SA is used to encrypt and authenticate a particular flow in one direction. Therefore, in normal bidirectional traffic, the flows are secured by a pair of SAs. An SA to be used with OSPFv3 must be configured manually and use transport mode. Static values must be configured on both ends of the SA.

Manual SAs require no negotiation between the peers. All values, including the keys, are static and specified in the configuration. Manual SAs statically define the security parameter index (SPI) values, algorithms, and keys to be used and require matching configurations on both end points (OSPFv3 peers). As a result, each peer must have the same configured options for communication to take place.

The actual choice of encryption and authentication algorithms is left to your IPsec administrator; however, we have the following recommendations:

  • Use ESP with NULL encryption to provide authentication to the OSPFv3 protocol headers only. With NULL encryption, you are choosing not to provide encryption on OSPFv3 headers. This can be useful for troubleshooting and debugging purposes. For more information about NULL encryption, see RFC 2410, The NULL Encryption Algorithm and Its Use With IPsec.

  • Use ESP with non-NULL encryption for full confidentiality. With non-NULL encryption, you are choosing to provide encryption. For more information about NULL encryption, see RFC 2410, The NULL Encryption Algorithm and Its Use With IPsec.

  • Use AH to provide authentication to the OSPFv3 protocol headers, portions of the IPv6 header, and portions of the extension headers.

The following restrictions apply to IPsec authentication for OSPFv3:

  • Dynamic Internet Key Exchange (IKE) security associations (SAs) are not supported.

  • Only IPsec transport mode is supported. In transport mode, only the payload (the data you transfer) of the IP packet is encrypted and/or authenticated. Tunnel mode is not supported.

  • Because only bidirectional manual SAs are supported, all OSPFv3 peers must be configured with the same IPsec SA. You configure a manual bidirectional SA at the [edit security ipsec] hierarchy level.

  • You must configure the same IPsec SA for all virtual links with the same remote endpoint address.

See Also

Example: Configuring Simple Authentication for OSPFv2 Exchanges

This example shows how to enable simple authentication for OSPFv2 exchanges.

Requirements

Before you begin:

Overview

Simple authentication uses a plain-text password that is included in the transmitted packet. The receiving routing device uses an authentication key (password) to verify the packet. Plain-text passwords are not encrypted and might be subject to packet interception. This method is the least secure and should only be used if network security is not your goal.

You can configure only one simple authentication key (password) on the routing device. The simple key can be from 1 through 8 characters and can include ASCII strings. If you include spaces, enclose all characters in quotation marks (“ “).

In this example, you specify OSPFv2 interface so-0/1/0 in area 0.0.0.0, set the authentication type to simple-password, and define the key as PssWd4.

Configuration

CLI Quick Configuration

To quickly configure simple authentication, copy the following command, removing any line breaks, and then paste the command into the CLI. You must configure all routing devices within the area with the same authentication and corresponding password.

Procedure

Step-by-Step Procedure

To enable simple authentication for OSPFv2 exchanges:

  1. Create an OSPF area.

  2. Specify the interface.

  3. Set the authentication type and the password.

  4. If you are done configuring the device, commit the configuration.

    Note:

    Repeat this entire configuration on all peer OSPFv2 routing devices in the area.

Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Note:

After you configure the password, you do not see the password itself. The output displays the encrypted form of the password you configured.

Verification

Confirm that the configuration is working properly.

Verifying the Configured Authentication Method

Purpose

Verify that the authentication method for sending and receiving OSPF protocol packets is configured. The Authentication Type field displays Password when configured for simple authentication.

Action

From operational mode, enter the show ospf interface and the show ospf overview commands.

Example: Configuring MD5 Authentication for OSPFv2 Exchanges

This example shows how to enable MD5 authentication for OSPFv2 exchanges.

Requirements

Before you begin:

Overview

MD5 authentication uses an encoded MD5 checksum that is included in the transmitted packet. The receiving routing device uses an authentication key (password) to verify the packet.

You define an MD5 key for each interface. If MD5 is enabled on an interface, that interface accepts routing updates only if MD5 authentication succeeds. Otherwise, updates are rejected. The routing device only accepts OSPFv2 packets sent using the same key identifier (ID) that is defined for that interface.

In this example, you create the backbone area (area 0.0.0.0), specify OSPFv2 interface so-0/2/0, set the authentication type to md5, and then define the authentication key ID as 5 and the password as PssWd8.

Topology

Configuration

CLI Quick Configuration

To quickly configure MD5 authentication, copy the following command and paste it into the CLI.

Procedure

Step-by-Step Procedure

To enable MD5 authentication for OSPFv2 exchanges:

  1. Create an OSPF area.

  2. Specify the interface.

  3. Configure MD5 authentication and set a key ID and an authentication password.

  4. If you are done configuring the device, commit the configuration.

    Note:

    Repeat this entire configuration on all peer OSPFv2 routing devices.

Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Note:

After you configure the password, you do not see the password itself. The output displays the encrypted form of the password you configured.

Verification

Confirm that the configuration is working properly.

Verifying the Configured Authentication Method

Purpose

Verify that the authentication method for sending and receiving OSPF protocol packets is configured. When configured for MD5 authentication, the Authentication Type field displays MD5, the Active key ID field displays the unique number you entered that identifies the MD5 key, and the Start time field displays the date as Start time 1970 Jan 01 00:00:00 PST. Do not be alarmed by this start time. This is the default start time that the routing device displays if the MD5 key is effective immediately.

Action

From operational mode, enter the show ospf interface and the show ospf overview commands.

Example: Configuring a Transition of MD5 Keys on an OSPFv2 Interface

This example shows how to configure a transition of MD5 keys on an OSPFv2 interface.

Requirements

Before you begin:

Overview

MD5 authentication uses an encoded MD5 checksum that is included in the transmitted packet. For MD5 authentication to work, both the receiving and transmitting routing devices must have the same MD5 key.

You define an MD5 key for each interface. If MD5 is enabled on an interface, that interface accepts routing updates only if MD5 authentication succeeds. Otherwise, updates are rejected. The routing device only accepts OSPFv2 packets sent using the same key identifier (ID) that is defined for that interface.

For increased security, you can configure multiple MD5 keys, each with a unique key ID, and set the date and time to switch to a new key. The receiver of the OSPF packet uses the ID to determine which key to use for authentication.

In this example, you configure new keys to take effect at 12:01 AM on the first day of the next three months on OSPFv2 interface fe-0/0/1 in the backbone area (area 0.0.0.0), and you configure the following MD5 authentication settings:

  • md5—Specifies the MD5 authentication key ID. The key ID can be set to any value between 0 and 255, with a default value of 0. The routing device only accepts OSPFv2 packets sent using the same key ID that is defined for that interface.

  • key—Specifies the MD5 key. Each key can be a value from 1 through 16 characters long. Characters can include ASCII strings. If you include spaces, enclose all characters in quotation marks (“ “).

  • start-time—Specifies the time to start using the MD5 key. This option enables you to configure a smooth transition mechanism for multiple keys. The start time is relevant for transmission but not for receiving OSPF packets.

Note:

You must set the same passwords and transition dates and times on all devices in the area so that OSPFv2 adjacencies remain active.

Topology

Configuration

CLI Quick Configuration

To quickly configure multiple MD5 keys on an OSPFv2 interface, copy the following commands, remove any line breaks, and then paste the commands into the CLI.

Procedure

Step-by-Step Procedure

To configure multiple MD5 keys on an OSPFv2 interface:

  1. Create an OSPF area.

  2. Specify the interface.

  3. Configure MD5 authentication and set an authentication password and key ID.

  4. Configure a new key to take effect at 12:01 AM on the first day of February, March, and April.

    You configure a new authentication password and key ID for each month.

    1. For the month of February, enter the following:

    2. For the month of March, enter the following:

    3. For the month of April, enter the following:

  5. If you are done configuring the device, commit the configuration.

    Note:

    Repeat this entire configuration on all peer OSPFv2 routing devices.

Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Note:

After you configure the password, you do not see the password itself. The output displays the encrypted form of the password you configured.

Verification

Confirm that the configuration is working properly.

Verifying the Configured Authentication Method

Purpose

Verify that the authentication method for sending and receiving OSPF protocol packets is configured. When configured for MD5 authentication with a transition of keys, the Auth type field displays MD5, the Active key ID field displays the unique number you entered that identifies the MD5 key, and the Start time field displays the time at which the routing device starts using an MD5 key to authenticate OSPF packets transmitted on the interface you configured.

Action

From operational mode, enter the show ospf interface and the show ospf overview commands.

Using IPsec to Secure OSPFv3 Networks (CLI Procedure)

OSPF version 3 (OSPFv3) does not have a built-in authentication method and relies on IP Security (IPsec) to provide this functionality. You can use IPsec to secure OSPFv3 interfaces on EX Series switches.

This topic includes:

Configuring Security Associations

When you configure a security association (SA), include your choices for authentication, encryption, direction, mode, protocol, and security parameter index (SPI).

To configure a security association:

  1. Specify a name for the security association:
  2. Specify the mode of the security association:
  3. Specify the type of security association:
  4. Specify the direction of the security association:
  5. Specify the value of the security parameter index:
  6. Specify the type of authentication to be used:
  7. Specify the encryption algorithm and key:

Securing OPSFv3 Networks

You can secure the OSPFv3 network by applying the SA to the OSPFv3 configuration.

To secure the OSPFv3 network:

Example: Configuring IPsec Authentication for an OSPF Interface

This example shows how to enable IP Security (IPsec) authentication for an OSPF interface.

Requirements

Before you begin:

Overview

You can use IPsec authentication for both OSPFv2 and OSPFv3. You configure the actual IPsec authentication separately and apply it to the applicable OSPF configuration.

OSPFv2

Beginning with Junos OS Release 8.3, you can use IPsec authentication to authenticate OSPFv2 interfaces, the remote endpoint of a sham link, and the OSPFv2 virtual link by using manual security associations (SAs) to ensure that a packet’s contents are secure between the routing devices.

Note:

You can configure IPsec authentication together with either MD5 or simple authentication.

To enable IPsec authentication, do one of the following:

  • For an OSPFv2 interface, include the ipsec-sa name statement for a specific interface:

  • For a remote sham link, include the ispec-sa name statement for the remote end point of the sham link:

    Note:

    If a Layer 3 VPN configuration has multiple sham links with the same remote endpoint IP address, you must configure the same IPsec security association for all the remote endpoints. You configure a Layer 3 VPN at the [edit routing-instances routing-instance-name instance-type] hierarchy level. For more information about Layer 3 VPNs, see the Junos OS VPNs Library for Routing Devices.

  • For a virtual link, include the ipsec-sa name statement for a specific virtual link:

OSPFv3

OSPFv3 does not have a built-in authentication method and relies on IPsec to provide this functionality. You use IPsec authentication to secure OSPFv3 interfaces and protect OSPFv3 virtual links by using manual SAs to ensure that a packet’s contents are secure between the routing devices.

To apply authentication, do one of the following:

  • For an OSPFv3 interface, include the ipsec-sa name statement for a specific interface:

  • For a virtual link, include the ipsec-sa name statement for a specific virtual link:

Tasks to Complete for Both OSPFv2 and OSPFv3

In this example, you perform the following tasks:

  1. Configure IPsec authentication. To do this, define a manual SA named sa1 and specify the processing direction, the protocol used to protect IP traffic, the security parameter index (SPI), and the authentication algorithm and key.

    1. Configure the following option at the [edit security ipsec security-association sa-name mode] hierarchy level:

      transport—Specifies transport mode. This mode protects traffic when the communication endpoint and the cryptographic endpoint are the same. The data portion of the IP packet is encrypted, but the IP header is not.

    2. Configure the following option at the [edit security ipsec security-association sa-name manual direction] hierarchy level:

      bidirectional—Defines the direction of IPsec processing. By specifying bidrectional, the same algorithms, keys, and security paramater index (SPI) values you configure are used in both directions.

    3. Configure the following options at the [edit security ipsec security-association sa-name manual direction bidirectional] hierarchy level:

      protocol—Defines the IPsec protocol used by the manual SA to protect IP traffic. You can specify either the authentication header (AH) or the Encapsulating Security Payload (ESP). If you specify AH, which you do in this example, you cannot configure encryption.

      spi—Configures the SPI for the manual SA. An SPI is an arbitrary value that uniquely identifies which SA to use at the receiving host. The sending host uses the SPI to identify and select which SA to use to secure every packet. The receiving host uses the SPI to identify and select the encryption algorithm and key used to decrypt packets. In this example, you specify 256.

      authentication—Configures the authentication algorithm and key. The algorithm option specifies the hash algorithm that authenticates packet data. In this example, you specify hmac-md5-96, which produces a 128-bit digest. The key option indicates the type of authentication key. In this example, you specify ascii-text-key, which is 16 ASCII characters for the hmac-md5-96 algorithm.

  2. Enable IPsec authentication on OSPF interface so-0/2/0.0 in the backbone area (area 0.0.0.0) by including the name of the manual SA sa1 that you configured at the [edit security ipsec] hierarchy level.

Topology

Configuration

Configuring Security Associations

CLI Quick Configuration

To quickly configure a manual SA to be used for IPsec authentication on an OSPF interface, copy the following commands, remove any line breaks, and then paste the commands into the CLI.

Step-by-Step Procedure

To configure a manual SA to be used on an OSPF interface:

  1. Specify a name for the SA.

  2. Specify the mode of the SA.

  3. Configure the direction of the manual SA.

  4. Configure the IPsec protocol to use.

  5. Configure the value of the SPI.

  6. Configure the authentication algorithm and key.

  7. If you are done configuring the device, commit the configuration.

    Note:

    Repeat this entire configuration on all peer OSPF routing devices.

Results

Confirm your configuration by entering the show security ipsec command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Note:

After you configure the password, you do not see the password itself. The output displays the encrypted form of the password you configured.

Enabling IPsec Authentication for an OSPF Interface

CLI Quick Configuration

To quickly apply a manual SA used for IPsec authentication to an OSPF interface, copy the following command and paste it into the CLI.

Step-by-Step Procedure

To enable IPsec authentication for an OSPF interface:

  1. Create an OSPF area.

    Note:

    To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.

  2. Specify the interface.

  3. Apply the IPsec manual SA.

  4. If you are done configuring the device, commit the configuration.

    Note:

    Repeat this entire configuration on all peer OSPF routing devices.

Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

To confirm your OSPFv3 configuration, enter the show protocols ospf3 command.

Verification

Confirm that the configuration is working properly.

Verifying the IPsec Security Association Settings

Purpose

Verify the configured IPsec security association settings. Verify the following information:

  • The Security association field displays the name of the configured security association.

  • The SPI field displays the value you configured.

  • The Mode field displays transport mode.

  • The Type field displays manual as the type of security association.

Action

From operational mode, enter the show ipsec security-associations command.

Verifying the IPsec Security Association on the OSPF Interface

Purpose

Verify that the IPsec security association that you configured has been applied to the OSPF interface. Confirm that the IPSec SA name field displays the name of the configured IPsec security association.

Action

From operational mode, enter the show ospf interface detail command for OSPFv2, and enter the show ospf3 interface detail command for OSPFv3.

See Also

Related Documentation

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.

Release
Description
22.4R1