Using rd.coap.amsuess.com in plugtests

During plugtests (e. g. for OSCORE or EDHOC), participants often find themselves in separate networks, each with firewalls for incoming traffic. These commands can help them establish connections between each other:

Usage

The server operator executes:

$ pip install --user "aiocoap[all]"
The aiocoap installation instructions have details, including that you may want to do this in a virtual environment.
Start your actual server, on the default or a different port.
$ aiocoap-proxy --reverse --unconditional localhost --register coap+ws://rd.coap.amsuess.com --bind :1234 --register-proxy --register-as yourname.plugtest
If you run your server on a non-default port, adjust localhost accordingly. You can also select a non-local host if, for example, your implementation is running on an embedded device in a reachable location.

The --bind :1234 is there because the proxy is also reachable locally. That port will not be practically used, but currently aiocoap-proxy can not be started without binding.

The registration is conducted over CoAP-over-WebSockets and not regular CoAP. This helps around IPv4 address shortage and some shortcomings of the configured proxies as described on the service's main page. Users on IPv6 networks can alternatively choose CoAP-over-TCP (coap+tcp://…). CoAP-over-UDP usually does not make sense here: If that were publicly reachable, you wouldn't need this setup in the first place.

The server operator tells the client operator the host name (yourname.plugtest.proxy.rd.coap.amsuess.com), which can also be discovered by running aiocoap-client coap://rd.coap.amsuess.com/endpoint-lookup.

The client operator then directs their client to that host name.

Things that can go wrong

The client sends no Uri-Host option.

This typically manifests in the client seeing the RD itself rather than the advertised service. As the whole service uses name based virtual hosting, this is non-optional. Three solutions are available:

Just send that Uri-Host option. It's really not optional.
Introduce another reverse proxy on the client side that adds it. Ask me to add instructions here.
Switch from name based virtual hosting to port based virtual hosting. Possible in theory, but not implemented at this service (or in aiocoap – but both could be changed).

Registration happened over IPv4 and TCP.

This results in clients only receiving 4.04 not a server errors. Just switch over to CoAP-over-WebSockets or use IPv6 in the registration. An alternative would be for this service to run the IPv4 port multiplexing proxy and the RD in a single host.

Responses are empty.

If a request takes longer to process than a predefined time (aiocoap picks 100ms), a CoAP server (here: the proxy) sends an empty ACK and a separate response rather than a piggy-backed response. CoAP clients need to process either kind of response. As many simple servers always send piggy-backed responses, this setup might be the first situation in which client code encounters a separate response.

If a client library reports 0.00 responses, it implements CoAP incompletely. Tuning the RD proxy's EMPTY_ACK_DELAY can provide a temporary hot-fix, but really the client library should be fixed.

Role reversal does not work

If server and client are supposed to switch roles in the application that is being tested, the approach of using a reverse proxy is not applicable – things just won't work because the server only sees the RD as the origin address of any requests. Applications that rely on role reversal should either state that no proxies can be used with them (which in particular rules out this whole setup) or should provide a way for the client to indicate a response address, for which there is no general mechanism in CoAP. For example, the Resource Directory specification itself requires the client to set a base URI if it selects a proxy. (It is not explicit about, but practically requires that, reverse proxies explicitly support the application).