Re: [Ace] Ordering Guarantee in CoAP-EAP

Hi Ben,

we discussed this in the ACE meeting yesterday.
2.01 actually is the right response code for creating a new resource, indicating the advance in the application state (HATEOAS).
The name of the new resource could be indicated via Location-Path/Location-Query, and would be sent in the next request via Uri-Path/Uri-Query.
Even though many applications will not need that (or not even have the capacity for that), that easily provides for parallel executions of the protocol.
(Making sure that protocol executions cannot be confused with each other is an important basis for some security considerations, too.)

So: no new options or creative use of existing options are needed.

An example for such a protocol, albeit with fewer steps, can be found at:
https://datatracker.ietf.org/doc/html/draft-schmertmann-dice-codtls-01
(At the time we didn’t have the Echo option, so the draft contains its own cookie mechanism; this can now be replaced by — standard usage of — the Echo option.)

Grüße, Carsten

> On 15. Apr 2021, at 06:30, Benjamin Kaduk <kaduk@mit.edu> wrote:
> 
> Hi Dan,
> 
> I think the Echo option should be workable for your case (and in fact would
> provide an example of a case where the "time-limited single-use
> cryptographic nonce" that I had asked about in my review of
> draft-ietf-core-echo-request-tag might be applicable).
> 
> I expect the URI-Query proposal would be functional as well, but perhaps
> require more complexity, especially when the number of round-trips in the
> EAP mechanism is not going to be known in advance.
> 
> I don't think I quite understand the concerns with Location-Path and
> Location-Query (possibly because it's late in the day for me) and can't
> provide an answer for your question about that mechanism.
> 
> -Ben
> 
> On Tue, Mar 30, 2021 at 06:49:32PM +0200, Dan Garcia Carrillo wrote:
>> Hi ACE,
>> 
>> Last Thursday we had a conversation with Christian regarding possible 
>> optimizations on how to provide the requisite of the ordering guarantee 
>> for EAP.
>> 
>> This is currently achieved with an Option we define (SeqNum) to maintain 
>> a sequence number. This number is initialized randomly by the Controller 
>> and increased monotonically. This way the IoT device is able to know 
>> which is the next expected message.
>> 
>> In previous investigations, having into account that we are dealing with 
>> a lock-step protocol, we consider using the MSG-ID. The fact that they 
>> can be generated randomly was not a problem, since we considered that 
>> the CoAP engine store the recent MSG-IDs to detect duplicates, and any 
>> new message with an unregistered MSG-ID was considered the next expected 
>> message.
>> 
>> After our conversation with Christian, he pointed out that there may be 
>> implementations which may not keep track of recent MSG-IDs, hence we may 
>> need to rely on other mechanism to ensure the message sent is the one 
>> expeted.
>> 
>> To avoid defining a new option, we could use existing solutions to help 
>> provide ordered delivery:
>> - URI-Query
>> - Location-Path and Location-Query
>> - Echo Option
>> 
>> URI-Query:
>> We can use this as part of the request to specify accesing a resource 
>> with a subsequent value that indicates the step we are currently in 
>> (e.g., /b/x/n), 'b' -> bootstrapping service; 'x'-> resource for the 
>> currenty bootstrapping state; 'n'-> the current exchange
>> 
>> Location-Path and Location-Query:
>> In the response we would indicate the update on the current state and  
>> what is expected from the client in the next message, by adding the 
>> Location-Path and Location-Query Options. The problem is that currently 
>> these options are specified with 2.01 response code, not 2.04 Changed 
>> (the one we are using every time we update the bootstrapping state).
>> 
>> Our question is, would be possible to have this confirmation in the 
>> response?
>> 
>> Echo Option:
>> Finally, another option proposed by Christian is to use the Echo Option, 
>> starting in the first ACK from the server, to achieve the ordering 
>> guarantee. The server would state a number that has to be replied in 
>> another Echo Option in the next POST request from the server.
>> 
>> 
>> We feel that the mechamism finally chosen, that we are pursuing for the 
>> need of the EAP requirements, could be used for any lock-step protocol 
>> using CoAP as transport.
>> 
>> This is what we understood, please Christian comment if there is 
>> something to be clarified.
>> 
>> 
>> I think the option with the Echo Option we achieve a clean solution with 
>> a similar approach as we propose with the SeqNum Option.
>> 
>> Best Regards,
>> 
>> Dan.
>> 
>> 
>> 
>> [1] https://tools.ietf.org/html/draft-ietf-core-echo-request-tag-12
>> 
>> 
>> 
>> _______________________________________________
>> Ace mailing list
>> Ace@ietf.org
>> https://www.ietf.org/mailman/listinfo/ace
> 
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace