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

[Mališa Vučinić <[e-mail]>]

> On 10 Jul 2019, at 13:51, Carsten Bormann <[e-mail]> wrote:
> 
>> On Jul 10, 2019, at 11:41, Mališa Vučinić <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 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.


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?


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

Could we have a note on this in the draft?

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

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

>> If SHOULD is not respected, what happens?
> 
> The client might have trouble fully assessing the situation.


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

Works for me.