What's New in this Release

With this new function, you can install multiple configuration files in a single action. A new “Install Multiple” action is added to the Action menus of the install panels in all technologies. Use this action to select multiple configuration files to be installed in a single action, so you don’t have to enter and act on a separate install panel for each file in a group to be installed. You can use this new action on any install panel that has more than one file listed on it. For example, you can use it for all files in a sysplex group or all Alternate Configurations for a TCP/IP stack profile.

To install multiple configuration files by using the “Install Multiple” action, you must pre-configure installation parameters for each file to be installed, which can be done either in a new “Configure Installation” action available on all install panels, or by having installed the file previously.

Multiple equivalent servers can be provisioned in a cluster within the sysplex and the TCP/IP stack will perform workload balancing among the servers in the cluster. This support uses the TCP/IP stack Sysplex Distributor capability. When the domain administrator creates a network resource pool that supports sysplex clustered instances, a primary distributing stack and zero or more backup distributing stacks are provisioned in the sysplex. The distributing stacks are provisioned according to the Workload Distribution Profile that is chosen by the network administrator. The servers that are provisioned in the cluster then become targets of the distributing TCP/IP stack. Network resource pools capable of supporting sysplex clustered instances will have a Workload Deployment Type of CLUSTER. The advantages of sysplex clustered instances include high availability and the workload optimization capabilities of WLM.

Before this APAR, the Cloud stack configuration data sets could be sequential data sets, PDS members, or PDSE members. As of this APAR, those existing data sets can still be used if left unchanged. However, if the existing Cloud stack configuration data sets are modified in the Cloud stack configuration or if any new Cloud stack configuration data sets are defined for new TCP/IP stacks, only PDSE members will be accepted. These Cloud stack configuration data sets are written to frequently during provisioning and de-provisioning. Sequential data sets and PDS members need to be periodically compacted to avoid becoming full. When these data sets become full, cloud provisioning or de-provisioning might unexpectedly fail. PDSE members do not have to be compacted and thus are the data set of choice for cloud provisioning.

You can use several new workflows to complete the first-time setup for cloud networking. These workflows help you create RACF profiles for cloud networking and granting the appropriate permissions to them. Security products other than RACF are not supported by these workflows. They also help you create a PDSE data set and members for up to four TCP/IP stacks that can be used for the cloud stack configuration data set members. The workflows can be found in the /usr/lpp/zosmf/workflow/plugins/izuca directory. The workflow named ezb_cloud_setup_wizard.xml is run from the z/OSMF workflows task. It utilizes another workflow, ezb_cloud_stack_setup.xml.

When configuring the include and dynamic update data sets for TCP/IP stacks, two new options are available to assist with allocating those data sets. You can continue to pre-allocate the data sets as in the past. In addition to using pre-allocated data sets, you can now use a z/OSMF workflow created from this panel to allocate a data set of the size of your choice, or you can use this panel to dynamically allocate a data set by using the default size of your installation. Dynamically allocated data sets and their members are dynamically de-allocated when no longer referenced by Cloud TCP/IP stacks.

The short name for the IBM Configuration Assistant for z/OS Communications Server has been changed from “Configuration Assistant” or “CA” to “Network Configuration Assistant” or “NCA”. This change is reflected in panels, helps, and z/OS Communications Server publications.

A new configuration object type, the Alternate Configuration, is added to the TCP/IP profile perspective. This new object enables you to create TCP/IP configuration for a z/OS image that can be used in multiple locations, with minimum changes required between locations. Examples of use cases for this function include disaster recovery and planned outages. This function assumes that an image will be running in one Alternate Configuration (or location) at a time, and the basic TCP/IP configuration for an image is the same in all locations where that image can be started, except that the values of TCP/IP stack symbols can vary by location.

Alternate Configuration objects in the Network Configuration Assistant enable you to manage different TCP/IP stack symbol values for each location. By setting symbol values on an Alternate Configuration basis, you can easily manage a TCP/IP configuration that can be used in multiple locations without repeating redundant configuration. Functions are also provided for managing installation of stack configuration files across multiple locations, and for tracking and viewing symbol values across stacks and Alternate Configurations.

See Alternate Configurations Tutorial for more information.

Servers can be provisioned to make them capable of being moved from one z/OS system to another system in the same sysplex if a planned or unplanned outage occurs. When the domain administrator creates a network resource pool which supports movable instances, each system in the network resource pool will be configured in a manner that allows servers provisioned on one of those systems to move to another system in the network resource pool. The sever retains its same IP address and port. Network resource pools capable of supporting movable instances will have a Workload Deployment Type of MOVABLE.

When you add a rule to the stack’s connectivity rule list for AT-TLS or IPSEC, you can specify the placement of the new rule or groups of rules before or after an existing rule.

When you are adding an IPSEC connectivity rule to a stack, you can select a group of reusable rules to be added in one action.

You can select a group of IPSEC connectivity rules and in one action delete, disable, enable, or make specific all the rules in the selected group.

You can select a group of AT-TLS connectivity rules and in one action delete, disable, or enable all the rules in the specific group.

From the list of IPSEC reusable rules, you can select a rule and then select a group of stacks to receive that rule in one action.

IPSEC, AT-TLS, and Policy-based Routing address groups can contain other address groups.

As shown in Figure 1, the maximum level of address group nesting supported is 2.

Figure 1. Nesting Level Illustration

You can now import existing TCP/IP configuration into a V2R2 TCP/IP stack for the TCP/IP profile technology. First you must use the VARY TCPIP,,EXPORTPROF operator command to export an existing TCP/IP configuration data set into a format readable by the Network Configuration Assistant. You can then read that formatted configuration into a stack in the TCP/IP technology, and start working with your TCP/IP profile configuration in the Network Configuration Assistant.

z/OS Communications Server APAR PI63449 is required to support the EXPORTPROF command.

System symbols are created in reusable configuration and their values are resolved on a stack basis. When you import an existing TCP/IP configuration, system symbols in the fields listed above in reusable configuration will be preserved and resolved on a stack basis.

IPSEC interface name symbols continue to work as before.

The Network Configuration Assistant opening panel now enables you to begin by creating a new backing store, rather than requiring you to open an existing backing store before creating a new one.

The Welcome screen has changed to allow you to Manage z/OS Cloud configuration or to open a backing store to work with more traditional Configuration Assistant technologies.

You can only manage cloud networking from Network Configuration Assistant if you are using other z/OSMF features to manage z/OS Cloud. One or more z/OS Cloud and cloud domains must first be defined by the Cloud Landlord using the Resource Management task in the Cloud Provisioning category before the z/OS Cloud features of Network Configuration Assistant can be used to manage z/OS Cloud networking. Once one or more z/OS Cloud and cloud domains are created and after you choose to manage z/OS Cloud from the Network Configuration Assistant welcome screen, all subsequent screens are specific to z/OS Cloud network management. See Getting Started Tutorial - Cloud for more information. To use non-z/OS Cloud features of Configuration Assistant, you must return to the Home screen (Welcome panel) and open a backing store.

A new System Group level has been introduced on the Systems tab in support of configuration that pertains to a Sysplex. All system images must be contained within a group. The Default group is predefined and is used to contain system images that do not require Sysplex level configuration. All system images will be in the Default group the first time an existing backing store is opened. The system images and stacks can be copied from the Default group to new Sysplex groups that you define. You can find it useful to create Sysplex groups to provide a more accurate depiction of your environment. TCP/IP profile support is the only technology that currently supports Sysplex level configuration. The System Group level is available on the Systems tab of all technologies.

The Network Configuration Assistant introduces the TCP/IP Profile technology to support configuring and installing the TCP/IP profile. With the introduction of the TCP/IP profile support, there was a need to represent Sysplex level definitions that are related to dynamic and distributed VIPAs. The Sysplex definitions are defined at the Sysplex group level and include the dynamic and distributed VIPA definitions, in addition to the dynamic XCF definition that is a configuration requirement for distributed VIPA support.

The configuration process performs real-time error checking that eliminates errors that previously went undetected until run time. Configuration options have been preselected or prefilled to conform to best practices values where they deviate from default configuration values.

Reusable configuration elements have been introduced for the TCP/IP profile support. A reusable configuration element consists of a set of profile definitions that can be included in one or more stacks. This simplifies the configuration process when multiple stacks share a set of common definitions. Configuration elements such as an interface will require different IP addresses to be assigned on each stack where the reusable configuration is included. Stack symbols are used to assign these stack-specific values to configuration elements defined in a reusable configuration. Reusable configuration does not support Sysplex level definitions.

The TCP/IP Profile default IP filter rules define the default IP filter policy. The default IP filter policy is used before the initial loading of IP security policy into the stack from the Policy Agent. It is also used when the IP security policy has been suspended by the z/OS UNIX ipsec command (that is, when the ipsec -f default command is used). The IP filters are defined by using traffic descriptors that are shared with the IPSec technology.

The TCP/IP Profile stack symbols that are defined to resolve Reusable Configuration definitions included in a stack can be referenced by IPSec technology rules.

The LDAP, HTTP and OCSP options can be configured at the image and security level. The certificate validation is enabled at the security level by selecting to use the image level options or by specifying specific options explicit to the security level.

The Import Policy Data function provides the ability to import existing policy definitions from Policy Agent into the Network Configuration Assistant. The purpose of import was to provide a transition from flat file configuration to using the Network Configuration Assistant to manage the policy definitions. The Policy import function will be discontinued in a future release. It is recommended you transition to the Network Configuration Assistant for any policy configuration that is currently managed by using flat files.

Import Policy Data has not been enhanced to support the new AT-TLS configuration options for certificate revocation checking. It is recommended that you move to the Network Configuration Assistant for managing your AT-TLS policies before configure these new options.

You can use the V2R2 Configuration Assistant to configure V2R2, V2R1, and V1R13 level z/OS systems. For each z/OS image configured, you indicate the z/OS release level. The Network Configuration Assistant will ensure that valid configuration is produced for the system level. For example, in V2R2 there are new AT-TLS certificate revocation settings for HTTP and OCSP. If you configure these new settings for a z/OS image that is marked as V2R1, the Network Configuration Assistant will ignore these new settings during the installation process.

The Network Configuration Assistant introduces the Cloud technology to support the definition of Cloud policy. Cloud policy is defined through the use of network resource pools which identify network resources available for dynamic provisioning by a network resource provisioner. Available resources include IP addresses which are defined by IP address allocation ranges, ports which are defined by port allocations ranges and SNA application names which are defined by SNA application name ranges. Optional DNS information may be defined to support the automatic registration of a host name with a name server when an IP address is dynamically allocated. Cloud policy is scoped to the local sysplex in which the Network Configuration Assistant z/OSMF plug-in is running.

Configuration Assistant was rewritten to better integrated with z/OSMF.

• Configuration Assistant now uses common z/OSMF panel widgets resulting in a common look and feel with z/OSMF panels.
• Configuration Assistant now requires less z/OS CPU usage.
• Configuration Assistant initially launches to a home page rather than immediately opening the last used backing store. From the home page, you select which backing store to open.
• Removal of the main technology perspective. Users now go directly to the last technology they configured.
• Removal of the Network Configuration Assistant navigation tree. Users now select from a group of tabs to access z/OS image, TCP/IP stacks and reusable objects.
• Application setup tasks has moved to the z/OSMF workflow plugin.

New AT-TLS support has been added for the following RFCs:

• Renegotiation options (RFC 5746)

  Secure Socket Layer (SSL) and Transport Layer Security (TLS) renegotiations are vulnerable to an attack in which the attacker forms a TLS connection with the target server, injects content of his choice, and then splices in a new TLS connection from a client. The server treats the client's initial TLS handshake as a renegotiation and thus believes that the initial data transmitted by the attacker is from the same entity as the subsequent client data. This specification defines a TLS extension to cryptographically tie renegotiations to the TLS connections they are being performed over, thus preventing this attack.

• Elliptic Curve Cryptography (RFC 4492 and RFC 5480)

  This support provides new algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies:

  • The use of Elliptic Curve Diffie-Hellman (ECDH) key agreement in a TLS handshake
  • The use of Elliptic Curve Digital Signature Algorithm (ECDSA) as a new authentication mechanism
  • The use of ECC with the Subject Public Key Information field in certificates.
• TLSv1.2 (RFC 5246)
• AES GCM Cipher Suites (RFC 5288)

  This involves the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as a TLS authenticated encryption operation, and defines TLS cipher suites that use AES-GCM with RSA, DSA, and Diffie-Hellman-based key exchange mechanisms.

• Suite B Profile (RFC 5430)

  The United States government has published guidelines for "NSA Suite B Cryptography", which defines cryptographic algorithm policy for national security applications. This support is now provided in AT-TLS. with Suite B.

• ECC and AES GCM with SHA-256/384 (RFC 5289)

  This defines 16 new cipher suites. All use Elliptic Curve Cryptography for key exchange and digital signature. Eight of the cipher suites use AES in Cipher Block Chaining (CBC) mode with an Hashed Message Authentication Code (HMAC)-based Message Authentication Code (MAC) with SHA-256 or SHA-384. The other eight use the new authenticated encryption modes defined in TLS 1.2 with AES in Galois Counter Mode (GCM) with SHA-256 or SHA-384.

You can use the V2R1 Configuration Assistant to configure V2R1, V1R13 and V1R12 level z/OS systems. For each z/OS image configured, you indicate the z/OS release level. The Network Configuration Assistant will ensure that valid configuration is produced for the correct level system. For example, in V1R13 there are new IDS attack protection types. If you attempt to configure these new protection types for a z/OS image marked as V1R12, the Network Configuration Assistant will ignore these new attack types since they are not available on V1R12. The Network Configuration Assistant will provide appropriate warnings to ensure you are aware of any settings that would be ignored.

You can limit the number of filter-match syslogd messages generated for each defensive filer. This can be enabled in the DMD configuration settings with a default log limit value. This default value will be used to limit the number of messages logged unless this value is overridden by the loglimit parameter when the filter is added or updated.

IPv6 addresses are now supported in PBR rules, address groups, and route tables.