A collection of online CoAP tools
At various names under *.coap.amsuess.com, CoAP services are run for the purpose of protocol experimentation. They are unsuitable for production use (as they may change or fail any time without prior notice), and unsuitable for any personal or confidential data (as all traffic may be logged in the course of experimentation).
If you are unfamiliar with the terms and technologies used here, go to coap.space for an introduction and further links.
Services
- proxy.coap.amsuess.com
- Generic forward proxy capable crossing CoAP transports. Can reach out using the coap, coap+tcp and coaps+tcp protocols.
- Most other services are only bound to IPv6 addresses, but advertise this address as their IPv4 address for users of the legacy internet protocol; for the services here, it also provides reverse proxying. Thus, requests sent to any other service using that protocol need to carry the Uri-Host option.
- It should be noted that the proxy implementation is not especially mature. If you run into trouble when using a server through the proxy, it may be prudent to suspect proxying errors first.
- rd.coap.amsuess.com
- An open Resource Directory implementation.
- This is a generic Resource Directory that currently implements no security policies whatsoever.
- Notably, it implements the on version of the reverse proxying extension proposed in core-resource-directory-extensions. This allows servers behind NAT or other restrictive firewalling to offer their services through the resource directory. When requested, any advertised relative URI references are based on coap://<endpoint>{.<sector>}.proxy.rd.amsuess.com/. As they are reverse proxied, requests there always need the Uri-Host option..
- Please note that the inbound reverse proxy for IPv4 is not yet set up properly – this means that registrations via that will need explicit base values (or broken forwarding when proxying to the registrant is requested). CoAP-over-WS is not be affected by this, as it goes to IPv6 on the HTTP and not the CoAP proxy.
- A typical usage pattern during plug tests is reverse-proxying arbitrary services through the RD.
- demo.coap.amsuess.com
- A CoAP server offering the "typical" services of providing the time, offering poetry larger than a single package, and taking unbelievably long to serve a single static resource.
Servers are aliased to v6. and v4. prefixes, both to ease experimentation and internal configuration. All servers are accessible using coap, coap+tcp and coaps+tcp (the latter using Let's Encrypt for certificates); the demo server is not yet available with TLS.
EDHOC
There is an experimental setup of EDHOC running on the demo server (currently only on CoAP-over-UDP). It acts as a responder and expects message 3 to be sent through OSCORE-EDHOC.
The server can only do cipher suite 2 (P-256 etc.), method 3 (static-static). It presents its CCS credential by value, and accepts any CCSs by value, and the CCS from Section 3.5 of RFC9529 by its key ID h'2b' or by value.
The credential the server presents is this KCCS:
{2: "demo.coap.amsuess.com", 8: {1: {1: 2, 2: h'00', -1: 1, -2: h'b9cc746df6641d55044478b29df019ef22b4d2e96ffcf8de85434e5d0f27c33c', -3: h'e14e87330d093b469b121c3d0e4d9452cb90036a6e209f21f37d35d2a05c426c'}}}
A user can verify whether they are authenticated as the trace client, any credential-by-value or using plain CoAP by querying the /whoami resource: it will report :trace3initiator, :anybody or "no claims authenticated", respectively.
Source and issues
Most of what is running here is generic functionality and tools provided by the aiocoap library.
Where possible, please report any cases of the services not behaving according to the respective specifications to the underlying implementation's issue tracker, or contact the operator below.
Contact
If you need more information about this service, or need to contact the operator for other reasons, send a mail to Christian Amsüss.