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
