crc mode: what it is for and its limits

Why this matters in production

crc is the default in most deployments, so most clusters are running it whether or not anyone chose it. Being able to say precisely what it does protect — and what it leaves exposed — is what makes running it a decision rather than an accident.

What crc mode gives you

Every message carries a CRC32c checksum, verified on receipt. This detects:

• Bit errors that slipped past Ethernet’s own CRC
• Corruption introduced by faulty NICs, cables, or switch buffers
• Memory corruption in intermediate handling

That is genuinely valuable. Ethernet CRC covers a single link; a message crossing several switches passes through multiple store-and-forward stages where corruption can be introduced and re-CRC’d. An end-to-end checksum catches what per-link checks cannot.

What it does not give you

• No confidentiality. Anyone able to capture packets reads object data in plaintext.
• No cryptographic integrity. CRC32c is not keyed. An attacker who can modify packets recomputes the checksum and the modification is undetectable.
• No protection against replay.

cephx still authenticates the connection and signs the authentication exchange, so an attacker cannot trivially impersonate a client — but the data flowing afterwards is neither secret nor tamper-evident in a cryptographic sense.

Legitimate reasons to run crc

Client compatibility. Older kernel clients may not support secure mode, and a mixed list keeps them working.

CPU constraints. On hosts already saturated during recovery, encryption may not fit. This is a real engineering constraint, not laziness — but it should be measured rather than assumed.

A physically isolated network. A cluster network on dedicated switches inside a controlled facility has a different threat model from one sharing a fabric with general traffic. Encryption is still preferable; the risk from its absence is smaller.

Selective application

# encrypt internal traffic, accept either from clients
ceph config set global ms_cluster_mode secure
ceph config set global ms_service_mode 'secure crc'
ceph config set global ms_client_mode 'secure crc'

This is often the right intermediate state: replication and recovery traffic — the bulk of the data — is encrypted, while client compatibility is preserved.

Quiz

Production discipline

Describe crc mode accurately in security documentation — integrity checking, not encryption — because the distinction is precisely what an auditor tests. Where crc is retained for compatibility, record the reason and the clients responsible, so the constraint is revisited when those clients are upgraded rather than becoming permanent by default.

Cross-course references

• Kubernetes: unauthenticated-but-checksummed internal traffic carries the same residual risk
• Linux: checksums versus signatures is a distinction with the same practical consequences everywhere