AES-CCM and AES-GCM counters consist of 16 bytes. The first 4 bytes are derived from the TLS handshake and are referenced as salt. 8 bytes are transmitted in plain and are called a nonce. The last 4 bytes are incremented with each new ciphertext block in the TLS record. The nonces have to be unique for each record, otherwise an attacker can execute specific attacks. Typical TLS implementations tend to increment the nonce with every new TLS record. Since the nonce value provides enough entropy, it could also be used for tracking purposes and leak information.
I think this could also be of interest and could be mentioned in the privacy section. Similarly to issue https://github.com/ekr/dtls-conn-id/issues/2
AES-CCM and AES-GCM counters consist of 16 bytes. The first 4 bytes are derived from the TLS handshake and are referenced as salt. 8 bytes are transmitted in plain and are called a nonce. The last 4 bytes are incremented with each new ciphertext block in the TLS record. The nonces have to be unique for each record, otherwise an attacker can execute specific attacks. Typical TLS implementations tend to increment the nonce with every new TLS record. Since the nonce value provides enough entropy, it could also be used for tracking purposes and leak information.