Subject: [Lake] LoRaWAN use case; Re: WGLC for draft-ietf-lake-reqs-01

From: <[email-masked]>
Date: Wed, 1 Apr 2020 08:47:28 +0000

Hello Göran, Eric, all,

I've read draft-ietf-lake-reqs-02 and the ensuing discussions.
I can contribute to the description of the LoRaWAN constraints.

@Göran, I'm sorry to say that your text does not fairly depict the duty cycle limitation of Sub-GHz systems in Europe.
It is not true that after you have transmitted for 1 second, you have to wait for 99 seconds before your next transmission (to oblige the 1% duty cycle limit).
I highly recommend reading this paper [1].
Not only does it have very clear depictions of Sub-GHz sub-bands and their duty-cycle limitations, but it also contains pointers to the authoritative documents, and discussions on how systems like Sigfox and LoRaWAN comply with the regulations. It even has considerations on the impact of duty-cycle limitations for meshed networks using CoAP.

In a nutshell, the duty-cycle is evaluated on a 1-hour sliding window. It is legal to burst out transmissions to a total of 36 seconds air time on a 1%-duty-cyle sub-band, and then pause for the rest of the hour.

As a telco operating commercial LoRaWAN networks in Europe, here are my observations:
It's perfectly ok to have a technician stand one or two minutes next to the IoT device he/she has just provisioned, in order to make sure everything is up and running.
It's not ok to have the technician stand an hour next to the device, just because the provisioning protocol surpassed the 36 seconds air-time credit given in the first hour.
Hence the challenge to this Working Group (fairly decent worst case):
Can you make some useful/secure key exchange happen within 36 seconds of air-time at LoRaWAN SF12 data rate, taking into account 2 repetitions per packet (I.e. 3 transmissions)?
Or better yet, in only half or a third of that, because you want to give some air-time to the lower layer MAC frames and to the application itself.
Best regards,

Dominique

[1] Saelens, Martijn & Hoebeke, Jeroen & Shahid, Adnan & De Poorter, Eli. (2019). Impact of EU duty cycle and transmission power limitations for sub-GHz LPWAN SRDs: an overview and future challenges. EURASIP Journal on Wireless Communications and Networking. 2019. 10.1186/s13638-019-1502-5. https://jwcn-eurasipjournals.springeropen.com/articles/10.1186/s13638-019-1502-5

De : Lake <[email-masked]<mailto:[email-masked]>> on behalf of Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Date : Tuesday 31 March 2020 02:57
À : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Objet : Re: [Lake] WGLC for draft-ietf-lake-reqs-01

> >    LoRaWAN has a variable MTU depending on the Spreading Factor (SF).
> >    The higher the spreading factor, the higher distances can be achieved
> >    and/or better reception.  If the coverage and distance allows it,
> >    with SF7 - corresponding to higher data rates - the maximum payload
> >    is 222 bytes.  For a SF12 - and low data rates - the maximum payload
> >    is 51 bytes on data link layer.
> >
> >    The benchmark used here is Data Rates 0-2 corresponding to a packet
> >    size of 51 bytes [LoRaWAN].  The use of larger frame size depend on
> >    good radio conditions which are not always present.  Some libraries/
> >    providers only support 51-bytes packet size.
> >    providers only support 51-bytes packet size.
> >
> > I'm not sure what I am supposed to do with this: it seems like we have
> > packet sizes that range from 51 to 222. I think what this is saying is
> > that I am supposed to assume 51-byte packets, but even that is
> > unclear.
>
>
>
> GS: This text was formed out of the SecDispatch discussion. Section
> 2.10.0 and other parts of the text highlights the need for
> benchmarks. Section 2.10.1.1 indicates that the benchmark for LoRaWAN
> is a packet size of 51 bytes at link layer. The benchmarks are now
> compiled in 2.10.4, hope it is more clear now.

Not really, no. What I am looking for is something that clearly
states:

   (1) the cost at various sizes (packets, flights, etc.)
   (2) what is expected/known to be achievable with a given technology

This is not giving me that, which seems to be what's needed here.

> GS: 2.10.2 speaks about the duty cycle of 1%:
>
>    “A duty cycle of 1% implies that the time to complete a
>
>    fragmentation of the payload increases by at least 10,000%. This
>
>    limitation determines how long time the device will have to wait for
>
>    next use, which encourages the reduction of the message size as much
>
>    as possible.”
>
> For each packet, wait 100 times the transmission time for next
> packet. This excludes potential retransmissions due to lost messages
> or errors etc.

OK, so what's the curve of handshake latency cost for protocols with
various message sizes? That's (in part) what I'm asking for.

> GS: The specified LoRaWAN packet size is at link layer. If fragmention
> with Blockwise, this results in multiple CoAP messages + increase of
> total CoAP header overhead.

Right, so I'm looking for this document to tell me that.

> > The answers in this document are frankly pretty unsatisfactory. For
> > instance, it says:
> >
> >    Considering the duty cycle of LoRaWAN and associated unavailable
> >    times, the round trips and number of LoRaWAN packets needs to be
> >    reduced as much as possible.
> >
> >  What I would expect to see is something to the effect of: "this is
> > the incremental cost in {power, bandwidth, time to complete} of an
> > additional packet and therefore we should be able to keep to <X
> > packets",
>
> GS: This, together with the benchmarks, was requested in
> Secdispatch. That lead to the spreadsheets and comparison between TLS
> handshake and EDHOC e.g. Time-on-Air, presented in the virtual interim
> in March 2019 and in the BoF at IETF 105.. The spreadsheets are still
> tavailable:
>
> https://github.com/EricssonResearch/EDHOC/tree/master/docs
>
> https://github.com/EricssonResearch/EDHOC/blob/master/docs/LoRaWAN_ToA.xlsx<https://github.com/EricssonResearch/EDHOC/blob/master/docs/LoRaWAN_ToA..xlsx>

Yeah, these spreadsheets aren't quite what I want because they are
focused on DTLS vs. EDHOC rather than on what happens with various
protocol sizes. The idea here is to get the relevant curve, so for
instance, "time to handshake completion by size of Message 1
controlling for Message 2" or where the cliffs are, or something, so
that we know what we are designing for.

> > but really the only thing we get is in 2.10.4, which says:
> >
> >    Considering that an AKE protocol complying with these
> >    requirements is expected to have at least 3 messages, the optimal AKE
> >    has 3 messages and each message fits into as few frames as possible,
> >    ideally 1 frame per message.
> >
> > The problem here is that we *know* we are going to have to accept
> > some level of messages that span multiple radio units and so
> > getting a sense of where the real boundaries are is critical,
> > but this document frankly isn't much of a help.
>
> GS: For the certificate case we do need messages that span multiple
> radio units, but not necessarily for PSK or RPK. And those are the
> most relevant cases for constrained IoT. In LoRaAlliance, for example,
> there is work on an RPK-based authentication scheme. We added new text
> in 2.10..4 about this limitation of certificate based authentication.

Well, with RPK and signatures you will still be over three packets
because the server's first message contains both (1) a DH share
and (2) a signature, for a combined minimum of 96 bytes. So, as far
as I can tell, we have this problem. And it's also not clear (at least
to me) if there is incremental cost within the packet cliffs. Is
the answer "no"?

> > SPECIFIC COMMENTS:
> > Abstract:
> >    authenticated key exchange protocol for OSCORE.  This draft is in a
> >    working group last call (WGLC) in the LAKE working group.  Post-WGLC,
> >    the requirements will be considered sufficiently stable for the
> >    working group to proceed with its work.  It is not currently planned
> >    to publish this draft as an RFC.
> >
> > You'll want to change this, obviously.
>
> GS: Some verbs needs to change to past tense, if that is what you mean?

Well, I would have removed this text entirely.

> > S 2.1.
> >    COSE provides the crypto primitives for OSCORE.  The AKE shall
> >    specify how COSE can be reused for identification of credentials and
> >    algorithms of OSCORE and the AKE, as extension point for new schemes,
> >    and to avoid duplicated maintenance of crypto library.
> >
> > This is the first of a number of places where this document tries
> > to pre-make design decisions. The requirement here is lightwightness,
> > not COSE. In general, this document should not be making any
> > such decisions; I've tried to call them out but may have missed
> > some.

> GS: See response to Richard.

Yeah, I don't think "strongly recommended" is appropriate either. This
is not properly the business of the requirements doc.

> >    Moreover, the AKE must support transport over CoAP.  Since the AKE
> >    messages most commonly will be encapsulated in CoAP, the AKE must not
> >    duplicate functionality provided by CoAP, or at least not duplicate
> >    functionality in such a way that it adds extra costs in terms of code
> >    size, code maintenance, etc.  It is therefore assumed that the AKE is
> >
> > This too is too strong. If it required .001% more of something, that might
> > be a totally reasonable tradeoff for some other feature.
>
>
>
> GS:  Added “non-negligible”:  “… it adds non-negligible extra costs … ”

I would say "should attempt to minimize".

> > S 2.2.
> >    To further minimize the bandwidth consumption it is required to
> >    support transporting certificates and raw public keys by reference
> >    rather than by value.  Considering the wide variety of deployments,
> >    the AKE must support different schemes for transporting and
> >    identifying credentials, including those identified in Section 2 of
> >    [I-D.ietf-cose-x509].
> >
> > Really? so we need to support both x509bag and x509chain? Why?
>
> GS: One point with using COSE is that it specifies schemes relevant
> for constrained IoT, like x5u, x5t and provides an extension point for
> new smart schemes in this setting. Do we need both x5bag and x5chain?
> We do want to support x5chain for simpler processing, but I’ve heard
> of people using either (but not both). We omitted x5bag pending input
> from the WG.

So I don't think the way to phrase this is by reference to COSE but
by reference to the requirements, which seem to be:

- Certs by URL
- Certs by hash
- Certs explicitly [Incidentally, TLS experience was we specified
  what's effectively x5chain but everyone wanted x5bag because
  of cross-signatures]

> >    Assuming that both signature public keys and static DH public keys
> >    are in use, then also the case of mixed credentials need to be
> >    supported with one endpoint using a static DH public key and the
> >    other using a signature public key.  The AKE shall support the
> >    initiator signaling which public key credential mix to be used in the
> >    protocol such that the responder knows and can verify that the
> >    intended variant was executed.
> >
> > I don't understand what this means. The initiator doesn't know what
> > the responder can use and so can offer but can't dictate it.
>
> GS: In constrained deployments the initiator could very well know
> e.g. because only one is supported. We rephrased this.
>
> ”The AKE shall support negotiation of public key credential mix and
> that both can verify the variant that was executed..”

Thanks.

> > S 2.3.
> >    The AKE must provide mutual authentication during the protocol run.
> >
> > So unilateral authentication is completely out of scope? Why?
>
> GS: See response to Richard’s mail.

I am surprised to hear that,but OK.

> >    authenticated the other's credential.  In particular, both endpoints
> >    must agree on a fresh session identifier, and the roles and
> >    credentials of both endpoints..
> >
> > What are the properties of this identifier? I don't see it described.
> > Is this a CK-style session identifier?
>
>
> GS: Yes, as far as I understand. Karthik provided this input for formal verification purposes.

OK, so I think this needs to be a lot clearer, given that you
also use "connection identifier".

> >     *  The AKE shall protect against identity misbinding attacks
> >       [Misbinding].  Note that the identity may be directly related to a
> >       public key such as for example the public key itself, a hash of
> >       the public key, or data unrelated to a key.
> >
> > I don't understand what this means, but it seems like having names
> > that are public keys is a potential cause of misbinding attacks.
>
> GS: This is a placeholder for the analysis needed to take into account
> different ways of identifying the subject.

Well, I don't really think that placeholders have a place in requirements
documents. In any case, it's very different to have the key pointed
at by reference and have the endpoint identified by the key, and they
have differentbinding properties.

> >    Moreover, it shall be possible for the receiving endpoint to detect a
> >    replayed AKE message.
> >
> > What does this mean? I don't know how to detect replay of the initial
> > message without maintaining infinite state or an extra round trip
> > (or catching it later in the protocol run) do you.
>
> GS: Rephrased based on proposal by Chris.

Will take a lool.

> >    Furthermore, the endpoints shall be able to verify that the identity
> >    of the other endpoint is an acceptable identity that it is intended
> >    to authenticate to.  (This requirement extends beyond the AKE in that
> >
> > What does this text mean?
>
> GS: This was requested by people working on formal verification. The
> requirement means that the AKE shall have a step verifying the
> endpoint being authenticated. In TLS web setting when connecting to
> example.com<http://example.com> it needs to verify that the certificate is issued for this
> domain. In 3GPP when connecting to a visited network it needs to
> verify that there is a roaming agreement. A more restricted setting
> could be a pre-provisioned public key of the manufacturer used to
> verify information about which network to join. Can we formulate this
> better?

Not sure. Can you give me an example of something that is an AKE that
doesn't otherwise have this property?

> > S 2.4.
> >    Perfect Forward Secrecy may alternatively be achieved with a nonce
> >    exchange followed by appropriately derived new session keys provided
> >    that state can be kept in the form of a session counter.  Note that
> >    OSCORE specifies a method for session key update involving a nonce
> >    exchange (see Appendix B in [RFC8613]).
> >
> > As noted in my comments on SAAG, the whole FS landscape is pretty
> > complicated, and this doesn't do that great a job of capturing it. For
> > instance, where do session tickets fit in?
>
> GS: I put in this text in as placeholder for Karthik’s mails about
> alternatives for forward secrecy, and added text about hash-based
> ratcheting after Chris’s recent comment. The draft does not pretend to
> give any deeper insights on this topic. The function of this paragraph
> is merely as placeholder for input provided to the requirements
> discussion, so those inputs do not get lost in mail archive, and so
> that we can return to that when we evaluate the solution against the
> requirements. We can add text about session tickets here, but may just
> as well wait with that to the solution discussion where probably this
> entire discussion better belong.

I believe that this document should be self-contained, so I'm not that
enthusiastic about placeholders.

> >    *  The AKE shall support negotiation of COSE algorithms
> >       [IANA-COSE-Algorithms] to be used in the AKE and in OSCORE.  A
> >       successful negotiation shall result in the most preferred
> >       algorithms of one of the parties which are supported by the other.
> >
> > This is overly specific, and I don't see why it's a requirement. The
> > way you want to phrase this is that it resists downgrade.
>
> GS: One reason why we may want to require more than “resisting
> downgrade” is that a protocol that always results in the least
> preferred common algorithm would comply with that requirement, and
> that obviously is not desirable.

I'd be interested in understanding how you propose to define
this property. For instance consider a protocol like TLS where
one end sends their list and the other end picks, that doesn't
guarantee highest preferred algorithm. It seems like the
definition people have come to is about integrity of negotiation
not about "best preferred" https://eprint.iacr.org/2016/072.pdf.

> >    The AKE negotiation must provide strong integrity guarantees against
> >    active attackers.  At the end of the AKE protocol, both endpoints
> >    must agree on both the crypto algorithms that were proposed and those
> >    that were chosen.  In particular, the protocol must protect against
> >    downgrade attacks.
> >
> > Would be good to quantify "strong". I suggest >= 128 bits.
>
> GS: This is another topic we discussed in connection with the BoF at
> IETF 105 and decided at the time not to do. Another reason for leaving
> this out is that it is not always clear what 128 bits mean. Curve25519
> may be characterized as < 128 bits. MACs shorter than 128 bits may be
> acceptable, this needs to be verified in the concrete protocol. The
> purpose of this work is to provide an AKE that works in very
> constrained settings. If too strong integrity requirement leads to a
> protocol that no one uses because of low performance then nothing is
> gained.

Hmm... I don't really remember that discussion, but I don't agree with
that outcome, and the purpose of a WGLC is to discuss this kind of
question. On the technical merits the 25519 thing is easy to handle by
either just saying 127 bits or just saying that we consider 25519 to
be about 128 bits. As for the MAC, the requirement I am talking about
is the strength of the protocol, not the size of the MAC, and I
think we should specify that.

> > S 2.6.
> >    In case of a PSK identifier, this may be protected against passive
> >    attackers, for example with a key derived from a Diffie-Hellman
> >    shared secret at the earliest in flight 3.  As a consequence, in
> >    order to authenticate the responder within the AKE, at least four
> >    protocol flights are needed in case of symmetric key authentication
> >    with identity protection.  Considering the need to keep the number of
> >    round-trips at a minimum (see Section 2.10.4), unless there are other
> >    good reasons for having more than 3 flights, it is not required to
> >    protect the PSK identifier, and it may thus be sent in the first
> >    flight.
> >
> > This kind of buries the lede. I would just say it's not a requirement.
>
> GS: This text came out of a mail discussion about what kind of
> identity protection is needed for PSK. If we remove the motivation
> the next reviewer will ask why. We kept one sentence as placeholder
> for that discussion.

OK.

> >    The AKE should avoid mechanisms where an initiator takes a guess at
> >    the policy, and when it receives a negative response, must guess,
> >    based upon what it has tried, what to do next.
> >
> > I don't agree with this at all, and I'm not sure why this is
> > here. There are good reasons to do this. In fact, it's the main way to
> > get a three message protocol with confidentiality for the server's
> > first flight.
>
>
> GS: This text was suggested by Michael. Just noting a potential
> difference in what you say: Michael’s text speaks about initiator
> guessing twice. In your example that is not the case, right?

Right.. Thanks for pointing that out.

-Ekr

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Göran Selander <[email-masked]>
Date: Wed, 1 Apr 2020 11:24:45 +0000

Hi Dominique,

Thanks for joining the discussion! I haven’t read the paper yet but have some questions:

  *   Does this procedure for complying with the duty cycle apply to normal traffic as well as the network join/on-boarding phase? We noted in a previous mail thread that the rules were more strict for normal traffic than for on-boarding.
  *   What does ”taking into account 2 repetitions per packet (I.e. 3 transmissions)” mean? That air-time for the protocol messages needs to be divided by 3?
  *   Does ”Or better yet, in only half or a third of that” mean another factor 2 or 3? (This sounds reasonable, just checking.)
  *   Since protocol messages are going in both directions, does 36 seconds account for the sum of total air-time for messages going in both directions, independently (within reasonable bounds) of delay between messages?

Thanks
Göran

From: "[email-masked]" <[email-masked]>
Date: Wednesday, 1 April 2020 at 10:49
To: Eric Rescorla <[email-masked]>, Göran Selander <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: LoRaWAN use case; Re: [Lake] WGLC for draft-ietf-lake-reqs-01

Hello Göran, Eric, all,

Dominique

- Certs by URL
- Certs by hash

Thanks.

Will take a lool.

OK.

-Ekr

Thank you.

---

From: <[email-masked]>
Date: Wed, 1 Apr 2020 13:31:58 +0000

Hello Göran,

Happy to contribute!
Some replies inlined.
Best regards,

Dominique

De : Lake <[email-masked]<mailto:[email-masked]>> on behalf of Göran Selander <goran.selander=[email-masked]<mailto:goran.selander=[email-masked]>>
Date : Wednesday 1 April 2020 13:24
À : Dominique Barthel <[email-masked]<mailto:[email-masked]>>, Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Cc : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Objet : Re: [Lake] LoRaWAN use case; Re: WGLC for draft-ietf-lake-reqs-01

Hi Dominique,

[DB] can you please point me at this thread?
[DB] indeed, EN 320200-1 section 5.4.2 has language that the duty-cycle limit applies to steady state operation, not startup etc.
"The representative period shall be the most active one in normal use of the device. As a guide "Normal use" is considered as representing the behaviour of the device during transmission of 99 % of transmissions generated during its operational lifetime.
Procedures such as setup, commissioning and maintenance are not considered part of normal operation."
The problem is that if you buy a LoRaWAN module from an OEM and write your upper layer stack on top of it, there is no way to call the LoRaWAN stack API with a flag "don't count this frame towards the duty-cycle allowance". I guess this flag would be totally abused. So the situation I see today is that the stack will refuse to send your AKE packet with the error message "out-of-duty-cycle, sorry, come back later", because the module manufacturer is the one who got the certification and is responsible for proper behaviour.
I agree that there might be hope for a better future, but for easier adoption I suggest we try to fit the enveloppe that I described.

  *

[DB] because this is meant to be a worst case, I'm pretending it takes 3 attempts for a radio frame to make it through. So yes, the air-time per successful messages is 3 times less.

  *

[DB] indeed, I meant another factor of 2 to 3.  Let see what we can do with this factor, and maybe discuss later if we can relax this a bit.

  *

[DB] the 36 seconds is the cumulated amount allowed for one transmitter (e.g., an IoT device, or a "base-station" known as Radio Gateway in LoRaWAN's parlance) over the last 3600 seconds, at any time. So, not quite independent of delay between messages.
[DB] the 36 seconds I proposed are only for uplink communication (from device to base station).
[DB] The downlink duty-cycle limits are harder to estimate, because: (1) the RGW duty-cycle is shared between downlink communications to all devices, (2) the downlink communication by a RGW can take place either on the same frequency by the uplink it's responding to (with typically 1% duty-cycle), or on a dedicated frequency that has 10% duty-cycle, (3) if a RGW has run out of duty-cycle, the Network Server will chose another RGW to sent the downlink, if device is in coverage of multiple RGW.
[DB] I would suggest to ignore the downlink duty-cycle issue altogether, it's a serious network problem but totally out of control of a single device. Let's just put as a requirement that the volume of data on the  downlink shall be similar to that of the uplink. If we are talking kBytes of downlink, then we need to revisit the question. The downlink is such a scarce resource that some operators have a pay-per-use policy, typically a few cents per downlink message (with a payload in the 50-250 bytes range).

  *

Thanks
Göran

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 1 April 2020 at 10:49
To: Eric Rescorla <[email-masked]<mailto:[email-masked]>>, Göran Selander <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: LoRaWAN use case; Re: [Lake] WGLC for draft-ietf-lake-reqs-01

Hello Göran, Eric, all,

Dominique

- Certs by URL
- Certs by hash

Thanks.

Will take a lool.

OK.

-Ekr

Thank you.

---

From: Göran Selander <[email-masked]>
Date: Wed, 1 Apr 2020 14:41:50 +0000

Hi Dominique,

Thanks! A few more comments inline.

From: Lake <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Wednesday, 1 April 2020 at 15:34
To: Göran Selander <goran.selander=[email-masked]>, Eric Rescorla <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Lake] LoRaWAN use case; Re: WGLC for draft-ietf-lake-reqs-01

Hello Göran,

Happy to contribute!
Some replies inlined.
Best regards,

Dominique

Hi Dominique,

-          Does this procedure for complying with the duty cycle apply to normal traffic as well as the network join/on-boarding phase? We noted in a previous mail thread that the rules were more strict for normal traffic than for on-boarding.
[DB] can you please point me at this thread?

[GS] I’ll try to find it, this was over a year ago.

[GS] This makes sense if there is no other robust solution to distinguish between them.

-

-          What does ”taking into account 2 repetitions per packet (I.e. 3 transmissions)” mean? That air-time for the protocol messages needs to be divided by 3?
[DB] because this is meant to be a worst case, I'm pretending it takes 3 attempts for a radio frame to make it through. So yes, the air-time per successful messages is 3 times less.

-

-          Does ”Or better yet, in only half or a third of that” mean another factor 2 or 3? (This sounds reasonable, just checking.)
[DB] indeed, I meant another factor of 2 to 3.  Let see what we can do with this factor, and maybe discuss later if we can relax this a bit.

-

-          Since protocol messages are going in both directions, does 36 seconds account for the sum of total air-time for messages going in both directions, independently (within reasonable bounds) of delay between messages?

[GS] Another question: the 1-2 minutes waiting time for the technician, is this per device? If there are dozens of devices deployed simultaneously could they interfere with each other so that the waiting time does not increase linearly?

Thanks
Göran

Hello Göran, Eric, all,

Dominique

> https://github.com/EricssonResearch/EDHOC/tree/master/docs<https://protect2.fireeye.com/v1/url?k=50dac494-0c50e65b-50da840f-0cc47ad93ea4-3960fa3fbf9bcace&q=1&e=bcff050e-f064-47b0-bef0-68edfc8b1ac2&u=https%3A%2F%2Fgithub.com%2FEricssonResearch%2FEDHOC%2Ftree%2Fmaster%2Fdocs>
>
> https://github.com/EricssonResearch/EDHOC/blob/master/docs/LoRaWAN_ToA.xlsx<https://protect2.fireeye.com/v1/url?k=9c8699f1-c00cbb3e-9c86d96a-0cc47ad93ea4-683c68ed31cdfad5&q=1&e=bcff050e-f064-47b0-bef0-68edfc8b1ac2&u=https%3A%2F%2Fgithub.com%2FEricssonResearch%2FEDHOC%2Fblob%2Fmaster%2Fdocs%2FLoRaWAN_ToA..xlsx>

- Certs by URL
- Certs by hash

Thanks.

Will take a lool.

not about "best preferred" https://eprint.iacr.org/2016/072.pdf<https://protect2.fireeye.com/v1/url?k=55ffe4af-0975c660-55ffa434-0cc47ad93ea4-29c54eea46b01a68&q=1&e=bcff050e-f064-47b0-bef0-68edfc8b1ac2&u=https%3A%2F%2Feprint.iacr.org%2F2016%2F072.pdf>.

OK.

-Ekr

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Wed, 1 Apr 2020 15:18:46 +0000

Hello Göran,

One response at the bottom.
Besides, I was pointed at the mail thread you alluded to, don't search for it anymore.

Dominique

De : Lake <[email-masked]<mailto:[email-masked]>> on behalf of Göran Selander <goran.selander=[email-masked]<mailto:goran.selander=[email-masked]>>
Date : Wednesday 1 April 2020 16:41
À : Dominique Barthel <[email-masked]<mailto:[email-masked]>>, Göran Selander <goran.selander=[email-masked]<mailto:goran.selander=[email-masked]>>, Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Cc : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Objet : Re: [Lake] LoRaWAN use case; Re: WGLC for draft-ietf-lake-reqs-01

Hi Dominique,

From: Lake <[email-masked]<mailto:[email-masked]>> on behalf of "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 1 April 2020 at 15:34
To: Göran Selander <goran.selander=[email-masked]<mailto:goran.selander=[email-masked]>>, Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lake] LoRaWAN use case; Re: WGLC for draft-ietf-lake-reqs-01

Hello Göran,

Happy to contribute!
Some replies inlined.
Best regards,

Dominique

Hi Dominique,

-

-

-

[GS] Another question: the 1-2 minutes waiting time for the technician, is this per device?
[DB] yes, per device. This is just a business equation. The technician idle time should not cost more than of fraction of the yearly revenue of the service, or more than a fraction of the device cost. YMMV of course, but a few minutes is fine, an hour is not, except maybe in a high margin business (nuclear plant, etc.). I'm thinking water and gas meters in a residential area.
[GS] If there are dozens of devices deployed simultaneously could they interfere with each other so that the waiting time does not increase linearly?
[DB] If there are dozens of devices doing the same transmit-intensive provisioning protocol in the same vicinity, and especially if they all transmit at the lowest datarate because they (wrongly) assume it is safer, the packet loss will be significantly higher, prompting for retransmissions, and yielding to duty-cycle exhaustion. After the first lower layer exchanges, a decent LoRaWAN network should raise the device's datarate to higher speeds (Adaptative Data Rate) to mitigate the issue, as high as link quality will allow, but (a) ADR needs quite a few transmissions to establish a link quality estimation, (b) some devices refuse ADR and just keep sending at the lowest datarate, which is understandable if they expect to be mobile (ADR is not a good fit for mobility).
I'm deliberately setting up a "decent" worst case scenario since the WG asks for scenarios, but I'm happy to be told wrong by other users of the technology.

Thanks
Göran

Hello Göran, Eric, all,

Dominique

- Certs by URL
- Certs by hash

Thanks.

Will take a lool.

OK.

-Ekr

Thank you.

Thank you.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 1 Apr 2020 18:17:01 +0200

Folks, can you do the mail messages in such a way that it doesn’t take several SI minutes to find the content inside all the redundancy?  You don’t have to repeat old stuff, we all have mail readers that allow us to find the old stuff.  Please trim the fluff.

Thank you for listening to this public service announcement.

Grüße, Carsten

---

From: Göran Selander <[email-masked]>
Date: Wed, 1 Apr 2020 17:58:48 +0000

Hi Dominique,

(trimmed down as instructed)

I’m trying to compare your challenge against the current benchmark: 1 message per packet at SF12.

Since there is no automatic mapping between uplink/downlink and flights of the AKE we need to consider both cases. (One potential way to address collisions between multiple devices accessing at the same time is that the device triggers the other endpoint start the AKE, which can act as initiator and schedule the AKE with each device.)

For the case of message 1 and message 3 being uplink, assuming key exchange protocol messages of size 51 bytes at link layer gives an air-time equal to 5.6 seconds (assuming the spreadsheet I’m using is correct). This is in the higher end of the interval 4-6 seconds of your challenge. (For EDHOC with raw public keys based ECDH the corresponding air-time is 4.4 seconds.)

For the setting where message 2 is uplink, there is a need for an additional message to trigger the AKE. Assuming a few bytes of trigger and 51 bytes at link layer in message 2 this gives an air-time for uplink slightly above 4 seconds (assuming the spreadsheet is correct; similar for EDHOC RPK).

So, the current benchmark and available data points are all compliant with your challenge.

Now message 2 is typically the largest message in the AKE, and as you acknowledged there is an uncertainty and potential cost with downlink (and also with simultaneous access). I think a benchmark should include all messages of the AKE and I would propose that we don’t formulate it in terms of uplink/downlink.

What do you think? Does the current benchmark make sense or would you prefer more restricted message sizes?

Göran

---

From: <[email-masked]>
Date: Thu, 2 Apr 2020 16:11:58 +0000

Hello Göran, all

(not sure anymore how I should write my answer)

>So, the current benchmark and available data points are all compliant with your challenge.
The numbers you provide indeed seem pretty much inline with the challenge I proposed, and I'll keep checking them as the WG progresses.
However, lets not be said that my challenge mandates the solution you propose (3 flights and 1 message per packet at SF12).
In draft-ietf-lake-reqs-02, the justification for 3 flights is Section 2.10.4, which I find kind of hand-wavy. (e.g., one could provide a similarly-hand-wavy counter argument to the 2*60 bytes vs. 3*40 bytes discussion: a shorter frame is less likely to suffer collision).

My point starting this discussion was to mention the 1 hour delay step effect as a transmitter reaches 36 s of air-time, which is not accurately reflected in column G of your spreadsheet and in the requirements draft.

> I think a benchmark should include all messages of the AKE and I would propose that we don’t formulate it in terms of uplink/downlink.
As much as I would love a general benchmark, I think LoRaWAN is very much an asymmetrical network and we need to acknowledge this fact.
I think it would do the LoRaWAN community a real service if we expressed the LAKE benchmark as two distinct cases : device-initiated AKE and infrastructure-initiated AKE. This would make it easier to map results onto real deployment cases.

Best regards,

Dominique

---

From: Jesus Sanchez Gomez <[email-masked]>
Date: Fri, 3 Apr 2020 16:22:25 +0200

Hello Dominique, all,

I think that it would be a nice addition to the document to consider the 
reality of commercially available LoRaWAN certified products' behaviour 
for EU (e.g. Microchip's RN2483, all the microphython compatible ones, 
LMiC).

I'm currently researching popular LoRaWAN certified products' datasheets 
trying to gather more information on this matter.

As the ETSI states, the 36 continuous burst is possible (considering 
RX1_delay, and RX1/RX2 windows of Class A) in theory.
However, expecting that all LoRaWAN modules are going to implement such 
functionality is uncertain AFAIK. Yo previously mentioned this in one of 
your recent messages.

Please, would you kindly provide a few names of LoRaWAN commercially 
available modules, I will take a look at how those manage said 36 
seconds continuous burst.

Another thing to consider is the configuration of optional sub-bands 
with their respective duty-cycle, that would further increase the amount 
of data that you can send in a short period of time.

Best Regards,

-- 
Jesús Sánchez Gómez
Contratado predoctoral // Phd Student. Fundación Séneca. Comunidad Autónoma de la Región de Murcia
+34 868 88 96 74
+34 635 33 26 09
[email-masked]
Department of Information and Communication Engineering
Faculty of Computer Science
University of Murcia
30100 Murcia, Spain

---

From: Jesus Sanchez Gomez <[email-masked]>
Date: Mon, 6 Apr 2020 13:52:32 +0200

Hello Dominique, all,

El 2020-04-01 a las 10:47, [email-masked] escribió:
> Can you make some useful/secure key exchange happen within 36 seconds 
> of air-time at LoRaWAN SF12 data rate, taking into account 2 
> repetitions per packet (I.e. 3 transmissions)?
> Or better yet, in only half or a third of that, because you want to 
> give some air-time to the lower layer MAC frames and to the 
> application itself.

I'm trying to model your use case, and I came up with the following 
diagram, in which each message will require up to three transmissions:

Would this make sense in the context of your original message?

If I got this right, then yes --- the whole exchange can be made using a 
duty-cycle less than half 36 seconds, and leave some room for user 
payload besides AKE.

ToA of a 51 payload LoRaWAN at SF12  = 2793 ms.

ToA times 6 (duty-cycle of End-device) = 2793*6 = 16758 ms.   // which 
is less than half 36 seconds.

Could you please comment on this?

Thank you,

Best Regards,

---

From: Göran Selander <[email-masked]>
Date: Mon, 6 Apr 2020 14:03:56 +0000

Hi Dominique,

Sorry for slow response. Again, thanks very much for your input. We have updated the requirements document based on your comments:
https://github.com/lake-wg/reqs/commit/45ec2292

Please have a look and let us know if we have addressed your concerns. Responses inline.

From: "[email-masked]" <[email-masked]>
Date: Thursday, 2 April 2020 at 18:12
To: Göran Selander <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Lake] LoRaWAN use case; Re: WGLC for draft-ietf-lake-reqs-01

Hello Göran, all

[GS] Agreed. The purpose of the exercise was to show: (AKE in 3 flights and 1 message per packet at SF12) => (device-initiated AKE comply with the challenge) and (infrastructure-initiated AKE comply with the challenge).

[GS] Yes, the argumentation needed to be improved, see updated text.

[GS] This legal requirement of the duty cycle is now in the draft. The spreadsheet is work in progress, see mails from Jesús on the LAKE mailing list.

[GS] This would be difficult to make more precise, e.g., since the infrastructure-initiated variant requires making assumptions about sizes of messages outside the AKE like the trigger message mentioned in the previous mail.  The content of the trigger messages further impacts the content and security properties of the AKE. What you request is perfectly reasonable degree of detail for the design phase when more information about the protocol is available and we should then make adjustments to the requirements if necessary when such more detailed estimates can be made. There are similar details when it comes to e.g. trade-offs between overhead and security properties that are not meaningful to detail at this stage. I hope you can agree that the current simplistic benchmark reasonably well captures your challenge.

Thanks
Göran