Some components around a CoAP setup are useful for applications but not (at least not typically) deployed on a constrained system. A CoAP-HTTP cross proxy can be a useful thing in trying out CoAP from a constrained device toward an HTTP service, and a Resource Directory can be useful in discovering a device (especially if it provides inbound proxying, which can be configured in RIOT’s provided RD endpoint implementation).
All these services can (and often should) be run by the operator, but in some setups that requires having a public address available (which, unfortunately, can currently not be taken for granted on the Internet), or is just an additional step standing between a user and a running demo.
I’d like to collect considerations for, and generally work toward, some services that we can easily provide for use with RIOT example applications.
Earlier discussion today brought up some concerns that this would need to address, plus some on my own list not discussed before:
Rate limiting, especially toward outside services for which this could be used as an attack vector (even though a single server is a very weak botnet). Especially, it’d need to implement CoAP’s amplification mitigation correctly.
GDPR compliance: We’d need ToS that declare this as for experimentation only, and forbid use with any kind of personal data.
Logging: We could probably not log, although if this is declared as being “for public experimentation”, we might reserve the right to (or even publicly log just to disintencivise any use that is contrary to ToS)
External reliance: Externals must not depend on this, this needs to stay best-effort-no-strings-for-us. It may help to have random downtimes just to force actual users off it.
Any examples that would “phone home” to this need to be very explicitly declared, and probably have it opt-in through a configuration option (even though the README might recommend turning this on before elaborating on how to provide an equivalent own service).
Things I’d like to see running:
Resource Directory, with reverse proxying
Proxy services, both to other CoAP protocols and to HTTP
SUIT server containing nightly builds of RIOT examples (just because we can )
maybe a pubsub broker
possibly an ACE server (but that’d need more development, and I don’t quite see how “log in with your RIOT account and find online devices of your RIOT friends” would be implemented)
I’m already running a similar service (RD, proxy w/o HTTP, some demo resources) on https://coap.amsuess.com/; as that is not under community control I’m reluctant to even put it into examples, let alone off-by-default or even on-by-default default values.
I think I can drive this (even though on a very open time scale); question is, are there more than the above-mentioned concerns to be considered?
I suggest that rather than try to deal with the problems after they occur, I suggest we acceptlist connections. The user should connect from a browser to some resource to authorize their IP address.
For IPv4, with ubiquitous NAT44, authorising for “my IP” should be pretty easy.
For IPv6, authorizing for my /64 would like well. Allowing people to slide the /prefix part a few bits to the left should be allowed. (i.e. I have 192.0.0.1 as my desktop, but I could ask for 192.0.0.0/24 to have access)
If you like, login with forum.riot-os.org, but also could just be validate email address to get token.
I’m not a big fan of IP based access control, especially when there is no source address validation (and once we add that, we’ve already done the work for amplification mitigation).
Or do you mean this to be about destinations reachable in outbound traffic (which would be only the client end of the proxy)?
main question is how much complexity you want to add to the users. anything that requires registration of ip addresses adds complexity. and, additionally, given ip address churn, i easily imagine that less experienced may struggle with such complexity. … so, i would rather go for a simple rating limiting and fix small RD entries.
[SUIT]
SUIT server containing nightly builds of RIOT examples (just because we can )
not sure. it may give the impression that remote (secure) firmware update is available.
To re-emphasize, this would be primarily about outgoing traffic, which the RD part doesn’t produce. The small remaining part would be about protecting our services themselves, and as long as the implementations are solid, the worst an attacker can do is placing spam in the RD (so what) and filling up our Internet connection (against which there is generally little mitigation unless you hide behind Someone Big).
[SUIT]
This gets a bit OT (because what I was envisioning would have clearly been demo level like the rest of this), but is that something that’d be even realistic to provide? It’d need at least
a solution to per-application cross-version storage (for otherwise the firmware update requires reenrollment),
trust in our SUIT implementation, and
organizationally managed release keys (including the processes to limit on which builds they can be used).
That’s a nice project, but none I see us having the capacity to run in the near future.
This gets a bit OT (because what I was envisioning would have clearly been demo level like the rest
of this), but is that something that’d be even realistic to provide?
i don’t think so, which is the reason why i would not deploy any SUIT,
to prevent any misunderstanding.
But wouldn’t that be a good integration test / demo?
Clearly we wouldn’t let arbitrary users upload firmware updates, but if e.g. examples/suit_update would
default to APP_VER = 1
fetch the firmware image for the board from our CoAP server
that would
teach us how to run a simple firmware update service
provide a good example on how to possibly set up a firmware update service to users
I’d say the chances of someone pwning the update server and replacing the demo firmware with something malicious are rather slim, and even then there is not that much harm that can be done on a sensor node with a short lived example application.
)
)