Toerless Eckert <[email protected]> wrote: > On Wed, Oct 12, 2022 at 07:49:06AM +0000, Esko Dijk wrote: >> For the stateless proxy, it is hard to determine a good rate limit number. 1% is not good because it would slow down the joining process of a genuine Pledge to a crawl. Some strategies that could work better:
> What is the typical lowest-bitrate that you are worried about,
> and what is the total amount of data of an enrolment process ?
Onboarding with a certificate takes around ~3kbytes of data, particularly DTLS
overhead.
> How would you deal with proxies that are on frequencies where the duty
cycle
> is limited by law. For example devices on my 868 home automation network
needs to maintain
> a 1%/hour duty cycle.
"by law" or by regulation or by protocol?
Your 868 system might be unable to complete onboarding, or maybe it will take
an hour.
> The problem to me seems that under those regulations, badly behaving nodes
> can force proxy and registrar into exhausting their regulatory limit as
> well unless either proxy and/or registar do something against that.
Yes, that's true, and why we want to be able to switch onboarding on/off.
> It almost feels as if radio networks where there are strict duty-cycle
> limits are requring per-pledge state on the proxy if the proxy wants to
> defend itself against the attacking pledge exhausting the proxies own
> duty-cycle. Unless the proxy function itself stricly operates
> independent of pledge on a cycle that is below the overal permitted
> duty-cycle for the proxy.
Yes, if one has ram and power, a stateful proxy can do a better job of
defending the network against attacks. A mains-powered PLC gateway between
power and 802.15.4 could/should do exactly that.
(Mind: I saw PLC systems that do Gb/s at networkX two weeks ago...)
> Proxy operations as described in this document are not necessarily
sufficient
> to protect proxy and/or registrar against misbehaving pledges that attack
> proxy/registar with too much data, especially when using (radio) networks
> with regulatory limitations on the volume permitted per sender (such as
> 1% duty-cycle per hour limitatios).
Yes. But, let's not boil the ocean.
It's a PS. We need to finish it so that we can deploy it so that we can
learn. Perfect is the enemy of good enough.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
