Re: [Ace] Ordering Guarantee in CoAP-EAP

Carsten Bormann <cabo@tzi.org> Thu, 15 April 2021 07:39 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFB063A13F9 for <ace@ietfa.amsl.com>; Thu, 15 Apr 2021 00:39:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level:
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDCLigL7aKkr for <ace@ietfa.amsl.com>; Thu, 15 Apr 2021 00:39:28 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66EF23A13F7 for <ace@ietf.org>; Thu, 15 Apr 2021 00:39:27 -0700 (PDT)
Received: from [192.168.217.110] (p548dc27d.dip0.t-ipconnect.de [84.141.194.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FLWSY0DnszyPR; Thu, 15 Apr 2021 09:39:25 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <20210415043057.GF79563@kduck.mit.edu>
Date: Thu, 15 Apr 2021 09:39:24 +0200
Cc: Dan Garcia Carrillo <garciadan@uniovi.es>, Rafa Marin-Lopez <rafa@um.es>, "ace@ietf.org" <ace@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A1EA066B-37B4-489B-9FAE-82BC19A27A9E@tzi.org>
References: <4a720f1d-5b46-c86d-4472-95da7774571d@uniovi.es> <20210415043057.GF79563@kduck.mit.edu>
To: Benjamin Kaduk <kaduk@mit.edu>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/HS07vvDu5SWXwzF8wUV3zxac59A>
Subject: Re: [Ace] Ordering Guarantee in CoAP-EAP
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Apr 2021 07:39:33 -0000

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