Re: [Anima] 2nd WGLC for draft-ietf-anima-constrained-join-proxy-12, ends September 20th 2022

[Toerless Eckert <[e-mail]>]

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