Relay Reference

Relay Reference

Relay responsibilities

In our reading, the core responsibilities of a relay are to:

  • forward HTTP requests and responses
  • without including headers or other identifying information
  • without having any visibility into request contents

Spelled out in full in the RFC 9458, the section on relay responsibilities states that relays:

  • MUST follow the forwarding rules in Section 7.6 of the HTTP standard RFC9110
  • SHOULD NOT forward unknown fields
  • MUST NOT include client-identifying information
  • MAY apply differential treatment to Clients that engage in abusive behavior
  • SHOULD only add delays with the consent of Clients

Specified behavior

Following the request format and response format message formats described in RFC 9458 and draft-ietf-ohai-chunked-ohttp-04, our relays will forward only certain requests and responses.

Content type

Requests must include a Content-Type header with the value message/ohttp-req or message/ohttp-chunked-req. Responses must include a Content-Type header with the value message/ohttp-res or message/ohttp-chunked-res.

Other headers

  • Content-Length will be forwarded if it is provided by the client.
  • Incremental will be set to the value ?1 for chunked requests and responses.
  • All other headers will be dropped.

Request and response bodies

Request and response bodies will be forwarded unchanged; the relay assumes that bodies are binary blobs containing encrypted binary HTTP requests. That said, relays will happily forward plaintext bodies if necessary for troubleshooting or debugging, as long as the Content-Type header is set correctly.

Domain name

relay.oblivious.network

All production relay traffic is routed through the domain relay.oblivious.network.

In Section 6.2.3, the OHTTP RFC suggests that traffic analysis is easier and easier as the portion of traffic shared by a single relay gets smaller. On Oblivious Network, we defend against this kind of analysis by having all relays use the domain name relay.oblivious.network.

This reduces the amount of information given away by each request, since the domain name will not imply any particular backend address. Your specific relay will be located at a particular path, such as relay.oblivious.network/limber-cliff-34. The path (and all other HTTP request headers) will be encrypted, and cannot be used to gain information about client requests.

Dev mode domain

The domain dev-relay.oblivious.network is used for “dev mode” relays, which are designed to accomodate preview deployments. In dev mode, each path segment after the relay name is mapped to a subdomain of the configured gateway address.

For example, let’s say you have a relay named limber-cliff-34, pointed at mydomain.com, and each pull request is deployed to a domain like pr-1234.dev.mydomain.com. You could reach that deployment at dev-relay.oblivious.network/limber-cliff-34/dev/pr-1234.

Here is a thorough list of examples, showing how relays will map URLs to domains:

  • relay.oblivious.network/limber-cliff-34 → mydomain.com/gateway
  • relay.oblivious.network/limber-cliff-34/pr-123 → mydomain.com/gateway
  • dev-relay.oblivious.network/limber-cliff-34 → mydomain.com/gateway
  • dev-relay.oblivious.network/limber-cliff-34/pr-123 → pr-123.mydomain.com/gateway
  • dev-relay.oblivious.network/limber-cliff-34/aws/pr-123 → pr-123.aws.mydomain.com/gateway

Roadmap

Planned features for Oblivious Network relays include:

  • Mutual TLS authentication for requests from our Relays to your Gateways
  • PrivacyPass Private Access Token authentication for client requests to our Relays

Reach out to us at support@oblivious.network if you have a request that’s not already on the list!

FAQ