Subject: Re: [core] 🔔 WGLC of draft-ietf-core-stateless-01

From: Mališa Vučinić <[email-masked]>
Date: Wed, 10 Jul 2019 11:41:13 +0200

Dear CoRE,

As indicated during the Prague meeting, I would like to thank Klaus and the CoRE group for finalizing this document on a short notice. The stateless document was motivated by our network access use case in 6TiSCH where an unauthenticated client talks to a constrained (stateless) proxy in order to join the network.

In general, I find the document well written and easy to read. Some remarks below. 

In case the extended token and Observe are used together, where multiple (legitimate) Observe responses carry the same (extended) token, replay protection using sequence numbers at the client might falsely identify such tokens as replays. How should this be handled?

Little consideration is given to the replay protection using timestamps. It might be important to note here that a client, and particularly a constrained one, only needs to trust its own clock without any synchronization required. The question that remains though is what implementation strategy should a client use to accept/reject a given extended token when using timestamps.

A client (or intermediary in the role of a client) that depends on
   support for extended token lengths (Section 2) from the next hop to
   avoid keeping request state MUST perform a discovery of support
   (Section 2.2) before it can be stateless.

There are environments, 6TiSCH being one example, where the support for extended tokens can be known before hand, e.g. through out of band information such as dependency in the draft. In that case, saving two messages on the wire in constrained environments by omitting the discovery seems quite reasonable. I would therefore argue for this MUST to be replaced with a SHOULD.

Some nits below:

   If a server supports extended token lengths but receives a request
   with a token of a length it is unwilling or unable to process, it
   MUST NOT reject the message.  Instead, it SHOULD return a 4.00 (Bad
   Request) response.  This implies that the server returns the entire
   token verbatim.

This paragraph to me seems self-contradictory. If a server cannot process a request with a token length greater than some value, is it reasonable to expect that it can return it in the Bad Request response? If SHOULD is not respected, what happens?

 Tokens are a hop-by-hop feature: When an intermediary receives a
   request, the only requirement is that it echoes the token back in any
   resulting response.  There is no requirement or expectation that an
   intermediary passes a client's token on to a server or that an intermediary 
   uses extended token lengths itself when receiving a request with an 
   extended token length.

Note should be taken here that such intermediary can itself be “stateless”, as described in Section 3.1 just below.

In wireless mesh networks,
   where all traffic is visible to a passive attacker, encryption may
   not be needed as the attacker can get the same information from
   analyzing the traffic flows.

I am quite confused by this sentence which seems as an oversimplification. What kind of an attacker are you considering here?

Mališa

> On 26 Jun 2019, at 16:14, Carsten Bormann <[email-masked]> wrote:
> 
> This is a Working Group last call on
> 
> https://tools.ietf.org/html/draft-ietf-core-stateless-01
> 
> The WGLC will end in exactly 336 hours so we can discuss the outcome at the CoRE WG Interim meeting on 2019-07–10.  Please indicate your position in a message to the CoRE mailing list ([email-masked]) or, exceptionally, to the chairs ([email-masked]).
> 
> Please find my chair’s review below; I believe the items raised there can be discussed during the WGLC alongside the concerns of other WG members.
> 
> Grüße, Carsten
> 
> 
> Chair’s review of draft-ietf-core-stateless-01
> 
> # Major
> 
> Discovery is currently focused on whether the server supports extended token lengths at all.  Given that the maximum extended token is rather large for a constrained environment, the client may be interested to find out how large tokens can be for this server.  With CSM, this would be trivial (change empty option value to an uint value).  With trial-and-error, this leaves the client with binary search (probably along the lines of the token sizes it actually can make use of).
> 
> # Minor
> 
> Section 3.3 suddenly starts to talk about authentication tags and freshness indicators; this might require additional explanation (in particular since there are BCP 14 keywords in these paragraphs).  Section 4.2.1 has some implementation guidelines that could possibly be expanded to cover this.
> 
> 
> 
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 10 Jul 2019 13:51:10 +0200

Hi Mališa,

thank you for these remarks.
Let me respond to some of them before we hear from the author.

> On Jul 10, 2019, at 11:41, Mališa Vučinić <[email-masked]> wrote:
> 
> Dear CoRE,
> 

Can you more specific about the scenario?

3.1 says:

   When multiple clients observe [RFC7641] the same resource,
   aggregating requests is REQUIRED (Section 3.1 of RFC 7641).  As this
   cannot be satisfied without keeping request state, an intermediary
   MUST NOT include an Observe Option in requests it sends without
   keeping request state.

> There are environments, 6TiSCH being one example, where the support for extended tokens can be known before hand, e.g. through out of band information such as dependency in the draft. In that case,…

Or, alternatively, being set up for operation in such a network could count as such a form of discovery.

> This paragraph to me seems self-contradictory. If a server cannot process a request with a token length greater than some value, is it reasonable to expect that it can return it in the Bad Request response?

The note (“This implies”) already points out the significant onus.  I’m not sure we can really require the MUST NOT.

> If SHOULD is not respected, what happens?

The client might have trouble fully assessing the situation.

> I am quite confused by this sentence which seems as an oversimplification. What kind of an attacker are you considering here?

I agree that there is a large box of pandora here.  In particular, an endpoint often cannot be sure their traffic stays within the wireless network.  I’m also not sure this is only about wireless mesh networks and not other wireless networks. So I would reformulate this “Where a passive attacker can get the same information from analyzing the traffic flows, there may be little gain in adding encryption.”.

Grüße, Carsten

---

From: Mališa Vučinić <[email-masked]>
Date: Wed, 10 Jul 2019 14:22:20 +0200

> On 10 Jul 2019, at 13:51, Carsten Bormann <[email-masked]> wrote:
> 
>> On Jul 10, 2019, at 11:41, Mališa Vučinić <[email-masked] <mailto:[email-masked]>> wrote:
>> 

My understanding is that the text above relates to a proxy handling observations from multiple clients. I do not read from this that Observe is in general forbidden with extended tokens.The scenario I am talking about is just the basic client - server interaction, with client being stateless and using the Observe option. The server will send multiple Observe responses with the same token. How should client’s implementation of replay protection handle this?

> Or, alternatively, being set up for operation in such a network could count as such a form of discovery.

Could we have a note on this in the draft?

> The note (“This implies”) already points out the significant onus.  I’m not sure we can really require the MUST NOT.

Ok, so I would suggest rephrasing this to:

"Instead, it SHOULD return a 4.00 (Bad Request) response and attempt returning the entire token verbatim."

> I agree that there is a large box of pandora here.  In particular, an endpoint often cannot be sure their traffic stays within the wireless network.  I’m also not sure this is only about wireless m…

Works for me.