Delivery authentication

Distinguish the two controls

Delivery uses two related controls. The one-time verification challenge proves that you can receive a datagram at the configured IP and port. The continuing firewall allowlist admits delivery traffic from the fixed service source, ${SOURCE_IP}.

There is no API key in the data path. UDP datagrams do not carry HTTP headers, and your receiver does not connect to a service endpoint. Do not wait for a login handshake on the receiver. Bind the configured socket and receive pushed datagrams.

Every datagram from shredstream.sh originates from ${SOURCE_IP}. The verification challenge and the shred stream use the same source IP. Permit this exact address before requesting the challenge. Forgetting the rule is the most common activation failure.

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. Add a static UDP port mapping when NAT is present.
5. Start a packet capture filtered to ${SOURCE_IP} and the destination port.

Use this capture command after replacing 9000 with the configured port:

sudo tcpdump -n -A -s 0 -c 1 'src host 64.130.40.90 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. Open the destination in the dashboard.
2. Confirm the displayed IP address.
3. Confirm the displayed UDP port.
4. Request a verification challenge.
5. Read the datagram beginning with ${CHALLENGE_PREFIX}.
6. Identify the destination ID in that datagram.
7. Identify the token in that datagram.
8. Paste the token into the dashboard.
9. Submit the token within ${CHALLENGE_TTL_SECONDS} seconds.

The service sends one datagram for each challenge request. Its payload begins with the literal string ${CHALLENGE_PREFIX}, followed by a destination ID and a token. The delimiter, token length, token alphabet, and complete payload encoding are not currently specified. Capture and display the received value instead of constructing or predicting it.

The challenge window lasts ${CHALLENGE_TTL_SECONDS} seconds. Use the token associated with the current destination and current request. Request a resend when the packet is dropped or the window expires. UDP does not cause the first challenge to be retransmitted automatically.

Apply the continuing allowlist

Keep the ${SOURCE_IP} rule after verification. Verification is not a replacement for the firewall rule. The live stream uses the same source address, so removing the rule stops delivery even while the destination remains verified.

Match three fields at the firewall: IPv4 source ${SOURCE_IP}, protocol UDP, and the registered destination port. Do not match a source UDP port because it is not currently specified. Do not permit TCP as a substitute because the delivery protocol is UDP.

Apply the rule at every enforcement point. A cloud security group can admit a packet that the host firewall later drops. A host rule can admit a packet that an upstream network ACL has already dropped. Inspect each layer rather than assuming one allow rule controls the whole path.

Source-IP allowlisting is the documented delivery authentication mechanism. It identifies traffic by network source and limits exposure to one address. The product does not specify per-packet cryptographic authentication, a shared secret inside the datagram, encryption, or a customer-configured source list.

Re-verify after an address change

Changing the destination IP or destination port requires a new challenge. Prepare the new socket and firewall path first. A destination permits three address changes per day.

1. Bind the new destination port.
2. Allow ${SOURCE_IP} to that port.
3. Update the NAT mapping when NAT is present.
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 does not prove control of the new pair. Parallel delivery during an address change is not currently specified. Treat the saved address as the intended delivery target and confirm packets at the new receiver before retiring old network controls.

Handle tokens as short-lived values

Copy the token only into the dashboard field used for verification. Do not place it in source code, long-term configuration, issue trackers, or support messages. The product does not specify token reuse semantics beyond the ${CHALLENGE_TTL_SECONDS} second challenge window, so treat each token as bound to its request.

If a token appears in logs, control those logs according to your own security policy. A required retention period and token-redaction feature are not currently specified.

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.