Delivery authentication

Distinguish the two controls

Delivery authentication has two controls. First, a challenge proves receipt at the configured IP and port. Afterward, the firewall allowlist admits traffic from the fixed service source, ${SOURCE_IP}.

No API key travels with the data. UDP datagrams lack HTTP headers, and authentication never asks the receiving process to establish an outbound service connection. Bind the configured socket instead of waiting for a login handshake.

shredstream.sh uses ${SOURCE_IP} for every datagram. Proof material and subsequent shreds share this origin. Permit it before you request proof. Most activation failures occur when this rule is missing.

Prepare the receive path

1. Bind a UDP socket to the configured destination port.
2. Add an inbound UDP rule for ${SOURCE_IP} to the destination port.
3. Add the same rule to the cloud firewall when one exists.
4. If NAT intervenes, create a fixed mapping for this UDP port.
5. Start a capture that selects ${SOURCE_IP} plus the configured destination port.

In this capture command, replace 9000 with your configured port:

sudo tcpdump -n -A -s 0 -c 1 'src host 203.23.178.228 and udp dst port 9000'

The command waits for one matching datagram and exits. The -A option displays printable payload bytes, which lets you read the challenge. Do not use -A for sustained stream capture because binary payload output is not useful and can slow inspection.

Complete proof of control

1. In the dashboard, open the destination being authenticated.
2. Match its displayed IP address to the receiver.
3. Match its displayed UDP port to the bound socket.
4. Issue a verification challenge.
5. Receive the datagram whose first bytes are ${CHALLENGE_PREFIX}.
6. Locate its destination ID.
7. Locate the token associated with that ID.
8. Put this token into the proof field.
9. Submit before ${CHALLENGE_TTL_SECONDS} seconds pass.

Every proof request yields exactly one datagram. The payload starts with the literal ${CHALLENGE_PREFIX}. The prefix is followed first by the destination ID, then by its token. Their delimiter, token length, alphabet, and complete encoding have no published definition. Capture and display the actual value rather than constructing or predicting it.

Proof remains acceptable for ${CHALLENGE_TTL_SECONDS} seconds. Use the value tied to both the current destination and current request. If the packet disappears or time runs out, issue a fresh request. UDP never makes the original challenge repeat automatically.

Apply the continuing allowlist

Keep the ${SOURCE_IP} rule after verification. Successful proof does not supersede the firewall. Since live traffic has the same source, removing this rule halts delivery despite a verified destination state.

The continuing rule matches IPv4 source ${SOURCE_IP}, UDP, and your registered destination port. Leave its source-port field unrestricted because no value is published. TCP cannot substitute for UDP delivery.

Install the rule wherever traffic is enforced. Admission by a cloud security group does not prevent a later host-firewall drop. Likewise, a host rule cannot rescue traffic rejected by an upstream ACL. Authentication requires inspection at each layer.

For ongoing delivery, the documented authentication mechanism is a source-IP allowlist. It identifies traffic through its network origin and narrows exposure to one address. No product definition covers per-packet cryptographic proof, an embedded shared secret, encryption, or customer-selected sources.

Re-verify after an address change

An IP or port edit invalidates proof for the former pair. Prepare the replacement socket and firewall path before asking for a new challenge. Three address changes are allowed on each destination per day.

1. Bind the new destination port.
2. Allow ${SOURCE_IP} to that port.
3. Update any NAT mapping that sits in the path.
4. Save the new address in the dashboard.
5. Request the challenge for the new address.
6. Submit the new token within ${CHALLENGE_TTL_SECONDS} seconds.

The previous token cannot prove control of this replacement pair. The contract is silent about serving old and new addresses together. Treat the saved address as the intended target, then confirm arrival at its receiver before retiring old controls.

Handle tokens as short-lived values

Copy the token only into the dashboard's verification field. Keep it out of source code, durable configuration, issue trackers, and support messages. Beyond the ${CHALLENGE_TTL_SECONDS} second window, token reuse has no defined semantics. Treat each value as belonging only to its request.

If a token appears in logs, protect them under your security policy. Neither a mandatory retention period nor a built-in redaction feature is documented.

Diagnose authentication failures in order

First, confirm whether tcpdump sees a datagram from ${SOURCE_IP}. Second, confirm whether the application receives the same packet. Third, confirm that the payload begins with ${CHALLENGE_PREFIX}. Fourth, submit the token before the window closes. This order separates routing, local delivery, payload recognition, and dashboard acceptance.

A stream packet is binary and does not begin with the challenge prefix as part of the documented service contract. Do not attempt to authenticate each stream packet by searching for the verification prefix. Filter its source address and process the raw payload according to the packet and shred references.