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

[Carsten Bormann <[e-mail]>]

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ć <[e-mail]> wrote:
> 
> 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?

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.

> 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.

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

> 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?

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.

> 
> 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?

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