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 <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
