AMQ9288E: Secure data transfer limit for channel ‘APP.SVRCONN’ exceeded.

Applicaiton is connecting to IBM MQ QMGR with GCM cipher and after some time we see below error on the logs

------04/11/2021 03:51:17 PM - Process(15964.184912222) User(mqm) Program(amqrmppa)
                    Host(************) Installation(Installation1)
                    VRMF(9.2.0.2) QMgr(***********.QM1)
                    Time(2022-04-11T07:51:17.549Z)
                    RemoteHost(10.xx.xx.xx)
                    ArithInsert1(445) ArithInsert2(4294967295)
                    CommentInsert1(APP.SVRCONN)
                    CommentInsert2(TLS_RSA_WITH_AES_256_GCM_SHA384)AMQ9288E: Secure data transfer limit for channel 'APP.SVRCONN' exceeded.EXPLANATION:
CipherSpec 'TLS_RSA_WITH_AES_256_GCM_SHA384' has reached a data transfer limit
of 4294967295 (the transfer limit is expressed in terms of TLS records for GCM
ciphers, or MB for all other ciphers). Session keys using this CipherSpec must
be used only to encrypt a limited quantity of data to reduce the risk of key
compromise.The channel 'APP.SVRCONN' terminated because it exceeded the allowed data
transfer limit for its CipherSpec.
ACTION:
This error can be avoided in one of the following ways:(a) Use secret key reset to ensure that the session key is reset before the
data transfer limit is exceeded.(b) Use a stronger CipherSpec which is not subject to a data transfer limit.
----- amqccisa.c : 10973 ------------------------------------------------------
04/11/2021 03:51:17 PM - Process(15964.184912222) User(mqm) Program(amqrmppa)
                    Host(************) Installation(Installation1)
                    VRMF(9.2.0.2) QMgr(***********.QM1)
                    Time(2022-04-11T07:51:17.549Z)
                    CommentInsert1(APP.SVRCONN)
                    CommentInsert2(15964)
                    CommentInsert3(10.xx.xx.xx)AMQ9999E: Channel 'APP.SVRCONN' to host '10.xx.xx.xx' ended abnormally.EXPLANATION:
The channel program running under process ID 15964 for channel 'APP.SVRCONN'
ended abnormally. The host name is '10.xx.xx.xx'; in some cases the host name
cannot be determined and so is shown as '????'.
ACTION:
Look at previous error messages for the channel program in the error logs to
determine the cause of the failure. Note that this message can be excluded
completely or suppressed by tuning the "ExcludeMessage" or "SuppressMessage"
attributes under the "QMErrorLog" stanza in qm.ini. Further information can be
found in the System Administration Guide.
----- amqrmrsa.c : 974 -------------------------------------------

Above error is because of the limit on the no of TLS records sent over the APP.SVRCONN Channel from appliciaton to QMGR for GCM Cipher and for non GCM ciphers it is the no of bites flowed . Once the limit is reached the cahnnel connection will be aborted and Client need to re-establish the connection .

To avoid such issues with GCM ciper following options are recomended .

1. Given version is 9.2.0.2 .GCM limit issue with channel abortion can be fixed by upgrading the MQ pathc with 9.2.0.5
2. set 4000000000 SSLRKEYC at qmgr level
3. Avoid using GCM cipher
4. When there are channel abotion immedialty applicaiton should be able to re-connect .Check with the applicaiton to makesure the re-connect logic is implemented

Some of the queires related to the above options hilighted below

Q1:what is the behaviour when we set 4000000000 SSLRKEYC at qmgr level ?

A1>>IBM MQ supports the resetting of secret keys on queue managers and clients. When setting 4000000000 SSLRKEYC at qmgr level.Secret keys are reset when 4000000000 encrypted bytes of data have flowed across the channel or If channel heartbeats are enabled, the secret key is reset before data is sent or received following a channel heartbeat.

You can find detail explanation from IBM doc

https://www.ibm.com/docs/en/ibm-mq/9.2?topic=messages-resetting-ssl-tls-secret-keys

Q2: if we set 4000000000 which is smaller then the reported error limit 4294967295 for  SSLRKEYC at qmgr . Does this avoid channel abortion? 

A2: yes

Q3: refresh security type(ssl) –> does this cause any issue with the existing message flow ?

A3: When you issue the REFRESH SECURITY TYPE(SSL) MQSC command, all running TLS channels are stopped and restarted. Sometimes TLS channels can take a long time to shut down and this means that the refresh operation takes some time to complete. 

Hope this helps !!!