Some applications create two connections between the client and server programs. These applications typically have a single primary connection that is bound to a well-known port on the server side. After exchanging some information, a second connection is established. This second connection often uses dynamically assigned ports on both ends. Examples of this behavior include the stderr connection in the rsh, rexec, and rlogin family of applications, as well as the firewall-friendly FTP data connection. It is often not possible to define a set of policy rule conditions to correctly map these secondary connections on the client side or when the server forks a new process, with a dynamic job name, for each connected client.
In other cases, this second connection is established after the server has changed to a client-supplied identity. Mapping this second connection to AT-TLS policy as a new and independent connection would force the use of a different System SSL environment. The client-supplied identity would need to have access to the certificate private keys. Normal FTP data connections are an example of this behavior.
AT-TLS provides an alternate method of mapping policy for these secondary connections. This alternate method causes the secondary connection to share the System SSL environment and security environment of the associated primary connection.
To activate the alternate policy mapping method, define a policy rule using conditions that will map the primary connection. In this policy, specify the SecondaryMap parameter with a value of ON. When this policy is mapped to a primary connection, an entry is made in an internal table. Future connections do a normal policy lookup, and then look in the internal table for an entry with the same process ID and pair of IP addresses. If a matching entry is found and the new connection has no mapped policy, or has a mapped policy with a lower priority than the matching entry, the new connection is marked as a secondary connection and uses the same policy and user ID as the primary connection.
You should use this alternate policy mapping method only for client applications and server applications that have a single primary connection. Careful consideration should be given before using it for non-forking server applications that accept multiple primary connections, such as MVRSHD (TCP/IP's combined rsh and rexec server for the TSO environment). The alternative method of policy mapping always associates secondary connections with the most recent primary connection mapped by this process. When the process establishes multiple primary connections, the alternate mapping method is not able to reliably associate secondary connections with the correct primary connection. You should not use this alternate policy mapping method when the primary connections can map to different policies based on client IP address or multiple server listening port numbers. You should use normal policy mapping with a job name condition for the secondary connections of non-forking servers.