PH23547: IKE INITIATOR IS REQUESTING NEW CREATION OF IKE_SA (IKEV2) OR PHASE1(IKE1) INSTEAD OF JUST A CHILD_SA(IKEV2) OR PHASE2(IKEV1)

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• The problem arises when multiple CHILD_SAs or PHASE2 security
  Associations are needed to protect traffic. For instance,
  FilterRules that are defined between the same IKE endpoints that
  are configured to have a VPN for TCP protocol and another VPN
  for UDP protocol. Normally, there would be a single IKE_SA or
  PHASE1 established that would have each of these specific
  Protocol VPNs/SAs anchored to it. This apar corrects an issue
  where the initiator LPAR for the 2nd protocol VPN is creating a
  brand new IKE_SA or PHASE1(ISAKMP) along with the specific
  CHILD_SA or PHASE2 SA. When this happens between two zOS IKE
  peers the first established SA that was protecting a specific
  protocol traffic is deleted when the new SA for the other
  protocol is created.  When the first VPN is deleted EZD0811I
  Decapsulation failed: with rsn=9 messages are seen on the
  responder side.
  The messages will stop when the initiator host re-establishes
  the first VPN for the specific protocol, but this causes the
  second VPN to be deleted, etc, etc.
  
  In configurations where Remote Identity in the KeyExchangeRule
  RemoteSecurityEndpoint is using a wildcarded X500dn. If the
  actual X500dn includes spaces,
  for example: OU=MY IKE CERTIFICATE but the remote x500dn
  wildcarded value does not include the spaces, then this issue
  will occur.
  
  ANALYSIS:
  IKED
  
  KNOWN IMPACT:
  brief loss of tunnels
  
  VERIFICATION STEPS:
  established tunnels being deleted and reestablished.
  Decapsulation failure messages with rsn=9
  

Local fix

• BYPASS/CIRCUMVENTION:
  In the policy, for the RemoteSecurityEndpoint, code the full
  X500DN (not a wildcarded value). If that is not possible, then
  ensure that the wildcarded DN includes the same first space as
  the full DN.
  For example, if the full DN is "CN=plex1.company.net,OU=Sales
  Dept,O=Company ABC,L=Research Triangle Park,ST=North
  Carolina,C=US",
  a wildcarded value of "*,OU=Sales Dept,O=Company ABC,L=Research
  Triangle Park,ST=North Carolina,C=US" could be used because the
  first space in both is the space between "Sales" and "Dept".
  
  
  RECOVERY ACTION:
  In the policy, for the RemoteSecurityEndpoint, code the full
  X500DN (not a wildcarded value). If that is not possible, then
  ensure that the wildcarded DN includes the same first space as
  the full DN.
  For example, if the full DN is "CN=plex1.company.net,OU=Sales
  Dept,O=Company ABC,L=Research Triangle Park,ST=North
  Carolina,C=US",
  a wildcarded value of "*,OU=Sales Dept,O=Company ABC,L=Research
  Triangle Park,ST=North Carolina,C=US" could be used because the
  first space in both is the space between "Sales" and "Dept".
  

Problem summary

• ****************************************************************
  * USERS AFFECTED:                                              *
  * All users of the IBM Communications Server for z/OS V2       *
  * Releases 2, 3, and 4: IPSEC                                  *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  * IKED fails to find an existing phase 1 SA when initiating    *
  * the creation of a second phase 2 SA between the same IKE     *
  * peers.                                                       *
  ****************************************************************
  * RECOMMENDATION:                                              *
  * Apply PTF                                                    *
  ****************************************************************
  When a second phase 2 SA is needed between 2 IKE peers, the IKED
  initiating the phase 2 negotiation searches for an existing
  phase 1 SA between the IKE peers. If an existing phase 1 SA
  exists, it should be used to protect the negotiation of the new
  phase 2 SA. The IKED initiator fails to find the existing phase
  1 SA and incorrectly initiates a new phase 1 SA. The negotiation
  of the new phase 1 and phase 2 SA is successful but results in
  the deletion of the original phase 1 and phase 2 SA.
  Decapsulation errors are seen for traffic protected by the
  original phase 2 SA. This traffic then drives creation of a new
  phase 2 SA which goes through the same cycle of negotiating a
  new phase 1 and phase 2 SA and deleting the previous phase 1 and
  phase 2 SA. The result is phase 1 and phase 2 SAs being
  negotiated and deleted continually.
  
  The failure to find the existing phase 1 SA was due to incorrect
  processing of X500DN remote identities when spaces were included
  in the DN. The processing was incorrectly removing the first
  space in the X500DN string.
  

Problem conclusion

• The code to search for an existing phase 1 SA has been
  corrected.
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

  UI68616 UI68617 UI68618

Modules/Macros

• EZAI2IND EZAIKFIN
  

Fix information

• Fixed component name

  TCP/IP MVS

• Fixed component ID

  5655HAL00

Applicable component levels

• R220 PSY UI68616

     UP20/05/02 P F005

• R240 PSY UI68618

     UP20/05/02 P F005

• R230 PSY UI68617

     UP20/05/02 P F005

Fix is available

• Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.