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

[Esko Dijk <[e-mail]>]

For RF bands with legal duty cycle regulations, sure any device using such band always has to comply with the duty cycle.
So we could say that's not our specific problem; it holds in general for any data sent by the device.

But I do see the point that for duty-cycled RF transmitters there's the added challenge in this case that forwarding "untrusted" data traffic eats up the hourly data limit that the device has. In that case a device may want to throttle depending on how much data it still has left for the coming hour. Or it may want to simply apply some preset limit (like 0.2% of channel capacity if the RF Tx duty cycle is 1% i.e. 20% of average hourly data budget).  That's up to the implementer. 

Esko

-----Original Message-----
From: Toerless Eckert <[e-mail]> 
Sent: Thursday, November 3, 2022 11:47
To: Michael Richardson <[e-mail]>
Cc: Esko Dijk <[e-mail]>; Anima WG <[e-mail]>
Subject: Re: [Anima] 2nd WGLC for draft-ietf-anima-constrained-join-proxy-12, ends September 20th 2022

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