Re: [Ace] Ordering Guarantee in CoAP-EAP

[Dan Garcia Carrillo <[e-mail]>]

Dear all,

Following the discussion on the last Interim meeting, we are updating 
the I-D with the comments of Carsten (thank you).

The exchange now follows the HATEOAS principal, with the following 
resource representation: /b/x/1

Where /b represents the general bootstrapping service, /x is a randomly 
generated number that represents the ongoing authentication process and 
/1 is the current step of the authentation.
This way  we avoid defining a new option for the purpose of maintaining 
the ordering guarantee that EAP requires from the lower layer.

This resource would be generated every time the CoAP client sends a POST 
message to the CoAP server as expressed in Figure 1. The client would 
send a first EAP message message (1.) to the server, which in turn 
creates the resource associated with the current excange /x plus the 
specific indication of the current step /1 in a  2.01 Created Response (2.).

The next message (3.) the CoAP client sends the next message to the 
newly created resouce, to which the CoAP server process internally with 
the following sequence.

     - Receive the EAP payload and process it, sending its  content to 
the EAP state machine
     - Receive the response from the EAP state machine.
         -- If everything goes as expected, the next resource is created 
/b/x/2
         -- If an error occurs an error message such as 4.00 Bad Request 
would be returned depending on the cause of the rror.

     - A new resource follwing the sequence is created, /b/x/2
     - The previous resource /b/x/1 is deleted
     - A response specifying the new resource is sent back (4.)


CoAP Server                    CoAP client
-----------                    -----------
1.            <-- POST /b
2.            --> ACK 2.01 Created /b/x/1
3.            <-- POST /b/x/1
4.            --> ACK 2.01 Created /b/x/2

Figure 1. Example of the new exchange


There is still a situation that I think might be worth clarifying in 
this exchange, such as what would happen if message 4. gets lost and the 
client re-transmits message 3.

This might be an issue depending on how the CoAP engine is implemented, 
since the resouce /b/x/1 is deleted and a new resource /b/x/2 takes its 
place. I understand that the CoAP engine has to recongnize the previous 
message as a retransmission, and just re-send the ACK 2.01 Created /b/x/2.


Best Regards,
Dan.



On 15/4/21 09:39, Carsten Bormann wrote:
> 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 <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ace
>> _______________________________________________
>> Ace mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ace