z/OS Communications Server: IP Messages Volume 2 (EZB, EZD)
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


EZD1797I

z/OS Communications Server: IP Messages Volume 2 (EZB, EZD)
SC27-3655-01

EZD1797I
Traffic specification requires NON_FIRST_FRAGMENTS_ALSO but IKEv2 peer did not send it

Explanation

When an IP packet that has upper-layer transport selectors (TCP port, UDP port, ICMP type and code, or MIPv6 type) is fragmented, only the first fragment contains the transport selectors. The remaining fragments are known as non-first fragments. There are potential security risks when you filter these non-first fragments because the port, type or code values are unknown. Because of these risks, RFC 5996 Internet Key Exchange (IKEv2) Protocol requires IKEv2 peers to use the NON_FIRST_FRAGMENTS_ALSO notify payload to negotiate support for non-first fragments. This negotiation determines whether non-first fragments are allowed to be carried on the IPSec Security Association (SA). They are allowed if the SA meets the following criteria:
  • The SA is using tunnel mode rather than transport mode.
  • The SA applies to TCP, UDP, ICMP, ICMPv6, or MIPv6 traffic and has a port, type or code, specification other than ALL.
  • The SA endpoints support stateful fragment checking, or the z/OS® end of the SA carries only local traffic. Local traffic is filtered before it is fragmented, so it is not a security risk.

z/OS Communications Server does not implement stateful fragment checking, so it does not require the NON_FIRST_FRAGMENTS_ALSO notify payload for SAs that are carrying routed traffic. However, z/OS Communications Server does require the NON_FIRST_FRAGMENTS_ALSO notify payload for SAs that are carrying local traffic because it sends local non-first fragments over the same SA as the first fragments. If the peer does not include this notify payload, it cannot receive the non-first fragments that the z/OS might send over this SA. z/OS will fail the SA negotiation and generate this message, because the peer is not prepared to receive all possible traffic that z/OS Communications Server might send over the SA.

System action

The SA negotiation fails. The IKE daemon processing continues.

Operator response

None.

System programmer response

Consult the syslog output to identify other messages that indicate which policy rules relate to the error.

To prevent this failure, perform one of the following actions:
  • Configure the remote security endpoint to enable stateful fragment checking.
  • Configure the SA at both security endpoints to use transport mode rather than tunnel mode.
  • Configure the SA at both security endpoints to cover all ports, types, or codes rather than to cover specific ports, types, or codes. To ensure that the SA covers all ports, types, or codes, configure both the IP filter rule and the granularity settings at both security endpoints. The IP filter rule must specify all ports, types, or codes. The on-demand granularity settings for port, type, and code must be set to use the values defined in the IP filter rule rather than the on-demand packet. For z/OS Communications Server, the IP filter rule selectors are configured on the IpService statement and granularity settings are configured on the IpLocalStartAction statement See the information about the IpService statement and the IpLocalStartAction statement in z/OS Communications Server: IP Configuration Reference.

User response

Not applicable.

Problem determination

None.

Source

z/OS Communications Server TCP/IP: IKE daemon

Module

IKEv2TSRequest.cpp, IKEv2TSResponse.cpp

Routing code

11

Descriptor code

7

Automation

This message is output to syslog.

Example

EZD1797I Traffic specification requires NON_FIRST_FRAGMENTS_ALSO but IKEv2 peer  did not send it

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014