On Thu, Nov 03, 2022 at 10:33:47AM +0000, Michael Richardson wrote: > > 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?
Pretty sure this would be regulations (aka: civil penalties if you misbehave, enfroced by whatever the regulatory agency in the country is. I could try to look it up for Germany, where i saw this in the products i am using). > Your 868 system might be unable to complete onboarding, or maybe it will take > an hour. I have to admit i do not even managed to figure out the nominal bitrate best case for he 969 Mhz system ;-) But also the ZWave "Interview" (the system i am using in the USA) is taking several minutes. I can't say this is a good user experience, so i am all for finding best compromise - but challenging. > > 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. Sure. "Status: Forced to idle - Call 1-800-SORR-YFCC" ;-) > > 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...) Indeed. Building BRSKI for the future we also have to be worried about designing against obsolete constraints of the past... But i guess LORAWAN would be here to say for long enough for us to worry, right ?! > > 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. Sure. I just wold love to see us not loosing the insight we're getting here... wiki / github - where would you think we could best collect them better than here in email ? Cheers Toerless _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima