IKE Key Management Protocol Overview
IKE is a key management protocol that creates dynamic SAs; it negotiates SAs for IPsec. An IKE configuration defines the algorithms and keys used to establish a secure connection with a peer security gateway.
IKE does the following:
Negotiates and manages IKE and IPsec parameters
Authenticates secure key exchange
Provides mutual peer authentication by means of shared secrets (not passwords) and public keys
Provides identity protection (in main mode)
IKE occurs over two phases. In the first phase, it negotiates security attributes and establishes shared secrets to form the bidirectional IKE SA. In the second phase, inbound and outbound IPsec SAs are established. The IKE SA secures the exchanges in the second phase. IKE also generates keying material, provides Perfect Forward Secrecy, and exchanges identities.
Starting in Junos OS Release 14.2, when you perform an SNMP walk of the jnxIkeTunnelEntry
object in the jnxIkeTunnelTable table, the Request failed: OID not increasing error message might be generated. This problem occurs only when
simultaneous Internet Key Exchange security associations (IKE SAs) are created, which occurs
when both ends of the SA initiate IKE SA negotiations at the same time. When an SNMP MIB
walk is performed to display IKE SAs, the snmpwalk tool expects the object identifiers (OIDs)
to be in increasing order. However, in the case of simultaneous IKE SAs, the OIDs in the
SNMP table might not be in increasing order. This behavior occurs because the tunnel IDs,
which are part of the OIDs, are allocated based on the initiator of the IKE SA, which can
be on either side of the IKE tunnel.
The following is an example of an SNMP MIB walk that is performed on IKE simultaneous SAs:
jnxIkeTunLocalRole."ipsec_ss_cust554".ipv4."192.0.2.41".47885 = INTEGER: responder(2) >>> This is Initiator SA jnxIkeTunLocalRole."ipsec_ss_cust554".ipv4."192.0.2.41".47392 = INTEGER: initiator(1) >>> This is Responder's SA
The OID comparison fails when the SNMP walk is tunnel ID (47885 and 47392). It cannot be ensured when an SNMP walk is performed that the tunnel IDs are in increasing order because tunnels might be initiated from either side.
To work around this problem, the SNMP MIB walk contains an option, -Cc, to disable check for increasing OIDs. The following is an example of the MIB walk performed on the jnxIkeTunnelEntry table with the -Cc option:
snmpwalk -Os -Cc -c public -v 1 vira jnxIkeTunnelEntry
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.
Request failed: OID not increasing error message might be generated.