Re: [Ace] Ordering Guarantee in CoAP-EAP

Dan Garcia Carrillo <garciadan@uniovi.es> Wed, 05 May 2021 11:53 UTC

Return-Path: <garciadan@uniovi.es>
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 83B3A3A12C0 for <ace@ietfa.amsl.com>; Wed, 5 May 2021 04:53:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=unioviedo.onmicrosoft.com
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 k28BG8fUrgOH for <ace@ietfa.amsl.com>; Wed, 5 May 2021 04:53:32 -0700 (PDT)
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2041.outbound.protection.outlook.com [40.107.20.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FC6D3A12BE for <ace@ietf.org>; Wed, 5 May 2021 04:53:32 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Fqz3+pE/lT7Sq8eqERKDXNmZaNBtL+WKH+iLBgoR+LOww47b+QgkpT8Dn59QKhINlxSc5ty3PzTwxVYuEB+B/t24vayLCOnPCpzC5hgTp5T5YP/J7oV6/a4Ni3I9DdkHDnq/Z24k13C/mq+7FK3PlqWyLvoYGv9Je6kcqbiIapf6AyO2+jypCETnAHs2rPrd+U0g4Qgm/pKsXtzJ7QgoIph5Jza0Y2E6L++VYlBVskBfbIggAOmoF+pR+HRLJVqavHcjeGcwVqyg3TkTn6KfOEdbfASF2vbEMiG3NG7NdWXPN9JYhXiB220ppx/053zx7YXnF4bdtypY87LPIJvX0Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=l/C5WTEfLDSnX+WSNV3CFM/qiATMkkcunq5rqsF/uRQ=; b=aEgRKb/TH6awCebk/u5LRycRRkQYwl9OfTrQ7iNUMop5BqD7+1Hd+XJkNzbv3cut1hUOaXyWnEkFvvpxNB33ECi2kjJRM33fjLYdovc35lANCVUr0PtZ2Ee4LpXAGpODytJIbDd1Pl2X284Jmc7NhTmX1AT6ZOOEM03xOdGgUvOflv06Jnz9eW/wJuuvkWlpD0OWTgLzCBewZui9XUO0OPdQCLloNyJu+yI7HxlNo1SuzAAdwlEDYRihdB7z6c8AhFvFj/xvpug9wpZUZCOnm9LX7XHrPfK5qReMdd06RMbcpoMnDHPgONjEX/jW/42nuAxeMih1ty3Z+pFKz5jgng==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uniovi.es; dmarc=pass action=none header.from=uniovi.es; dkim=pass header.d=uniovi.es; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unioviedo.onmicrosoft.com; s=selector2-unioviedo-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=l/C5WTEfLDSnX+WSNV3CFM/qiATMkkcunq5rqsF/uRQ=; b=vdtL4ZmteRUxleovpw00tOphWdXqStdX9+UzBU9Mhv66JZZg6JTi56VkKibHDr9YXUh3ukpiXB3IbRqNyPWRmI9zqF7ryPExZt40RlCFj6il4+FuO/x+t9wz5Ralr+6GD29xYStNnjy0RFG3e224yabGCEmOBEVrHSoLSXLzC8c=
Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=uniovi.es;
Received: from DBBPR08MB6202.eurprd08.prod.outlook.com (2603:10a6:10:209::9) by DB6PR0801MB1959.eurprd08.prod.outlook.com (2603:10a6:4:75::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4087.43; Wed, 5 May 2021 11:53:27 +0000
Received: from DBBPR08MB6202.eurprd08.prod.outlook.com ([fe80::1162:3ce2:d5ff:8822]) by DBBPR08MB6202.eurprd08.prod.outlook.com ([fe80::1162:3ce2:d5ff:8822%7]) with mapi id 15.20.4108.025; Wed, 5 May 2021 11:53:26 +0000
Cc: garciadan@uniovi.es, Rafa Marin-Lopez <rafa@um.es>, "ace@ietf.org" <ace@ietf.org>
To: Carsten Bormann <cabo@tzi.org>, Benjamin Kaduk <kaduk@mit.edu>
References: <4a720f1d-5b46-c86d-4472-95da7774571d@uniovi.es> <20210415043057.GF79563@kduck.mit.edu> <A1EA066B-37B4-489B-9FAE-82BC19A27A9E@tzi.org>
From: Dan Garcia Carrillo <garciadan@uniovi.es>
Message-ID: <7de32172-ebbb-bf5d-1945-7e1b7c035158@uniovi.es>
Date: Wed, 5 May 2021 13:53:24 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
In-Reply-To: <A1EA066B-37B4-489B-9FAE-82BC19A27A9E@tzi.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-Originating-IP: [156.35.225.67]
X-ClientProxiedBy: MRXP264CA0044.FRAP264.PROD.OUTLOOK.COM (2603:10a6:500:14::32) To DBBPR08MB6202.eurprd08.prod.outlook.com (2603:10a6:10:209::9)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from DansMacBookPro.local (156.35.225.67) by MRXP264CA0044.FRAP264.PROD.OUTLOOK.COM (2603:10a6:500:14::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.25 via Frontend Transport; Wed, 5 May 2021 11:53:26 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 16281fbb-94fd-4fea-0a68-08d90fbc6496
X-MS-TrafficTypeDiagnostic: DB6PR0801MB1959:
X-MS-Exchange-Transport-Forked: True
X-Microsoft-Antispam-PRVS: <DB6PR0801MB1959468653529C017E16D95EB4599@DB6PR0801MB1959.eurprd08.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: XRxa3rmFZMNcDCofhsv/AvHxXC7zBGa0i6eOAxiKxw8TOTqCxkwMlgdZEAWCSmLRdcyqteM2R7y4eXLGM4vgkU4EwV7nSplCvFa0EiHCCRIUdpbMqj+TDbyLHrTXPxoieMFwYi6DkIlzO5ZfTjQ03PXrV78YEq10UOvxJWMfQwXYjXuduwjazCrNGWkj3beXO8v8Mlo98hq4C7P/Y/NwQGPzXM+HeXmmwdhgQX2Hu5bWMyrKj44DwV10h304iig/jBFd/soMfzAqiB0fsZJXjCDM/k1vtwwWC7CIDmeX7UQ1B1A1f4Xm+WtpK6JJa31he4wFaT6pSxyYpsfD1JyKZ4s0iDUDHEtPXIuqSB1Jsutv+682FQsUwiG+3Z/2DRRu8POnn9zGxujl0vK4LQIfFVs2RvF8Ld/6QOd4S8qjAUraSmLEvIqn4tekgwz8IWK/tvs93pRiFfSfg1DTaN4xHHn0t0+dq4zmMIkLD1tDETSmCv7hLYHLFaq5Sv+T6dCbK+6f/pZN/2KnV8s7pSABysAG9fZoNCbgzBW+qJ/BCzZShlr4dHfCvaC9QTe0Z8hPZxUZwiwtmrI/x6CihFw7wQWXYhiptXsI+zLEexOM0JUfjI9nVuqrLd1moaTNJNeOVkZ+n4lyqnlljidUlR9EocRN4d8ZxmuyfQSZeaviQEWMFwZJ1QZ9xm+18gd3UhTHNFd4Cl+HQj54i+qgo+CQjMl4p18pHQeQLltmnZM0GhrdND9qTqZoorObIH6z7ewPogG74+PQhdC/IsmMVp8KReaH4SjG0thjRM6s3FajCjg=
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBBPR08MB6202.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(396003)(346002)(39850400004)(366004)(376002)(110136005)(54906003)(6506007)(186003)(31696002)(16526019)(26005)(2906002)(31686004)(53546011)(4326008)(786003)(478600001)(316002)(52116002)(8936002)(966005)(8676002)(6512007)(36756003)(2616005)(956004)(38100700002)(6486002)(66946007)(38350700002)(83380400001)(86362001)(66556008)(66476007)(5660300002)(45980500001)(43740500002); DIR:OUT; SFP:1101;
X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?MlM2U2R5bkhMZTNab2xjTXg4RSt4cW5qRUlMSmxRYnVKSC8xVy9PSUVWU2xi?= =?utf-8?B?Y1dDWWFlRFBKOGZTVUwvOTNDdzBBSjVRMmVMZnMvZjVHckdEZDZVKzNYZ2dH?= =?utf-8?B?TEJHbk1Qa1d3SDcvT0s4ZFF3OHpGdXhEUS92aHN3TmYzMTlWRWI1cVdHYnNU?= =?utf-8?B?SFJGTkp0aWg1ZU0xK2ZUL1NOTGJFRURwUmV5OE9yeFJhejJrOTFxQTJVZkJK?= =?utf-8?B?T3JlNTJIZHpzM0lENlF2eWw5U2FMcndWWndzc3RaUHVSVkt6WkNZanUvSjRZ?= =?utf-8?B?cmVYN3o1KytSbEF4RDlhTVRSWThSb1A0dkpXY0UvckNiNkRLdHFXOVROUWxK?= =?utf-8?B?b2lxRjU2Tk9lenEwSThqVGhGOHJxTHc1U0VuWjB1VmtEYWVIK0ltRnI3aHYx?= =?utf-8?B?bjB5NjlWK2V0QWovWUN3eEZxRnVtbksrbStJSWdSMWtKdHhXYk4zN1FzaFBi?= =?utf-8?B?Vm8ySFRNYTZVc1B1Zm5QaHpLVi9vdkQzU29pdE5pejkvYTNIM0FoT0k1R3pH?= =?utf-8?B?bWJTVHNKWVg5d1cvTXFkU25PdC9JUkdTWHpqQ3N0cmE2dXV2RVNxSFRDNzBE?= =?utf-8?B?ajkrK081YVNXUmxKMG1MWFRKZ1E2TVBJZDVtOGZPWDVJT1NYRlZlZ2RqSUx3?= =?utf-8?B?NG02RmZZUzlVbllQcDlEVnc5Sy96dkw2WHViV1gwY3I3Y2liRXRVTnNCWXVM?= =?utf-8?B?MHZkQzZzdEQ0clVJbytGdTN5cjZFZ2YvZU5Yd0pVL3B0MTc2NzBuZ3pRaEcx?= =?utf-8?B?OWo2SnZsTkNlbHc0NHhuc0MzdjZKTWpNeU1VUHl5Sm9lQUZhYWpRY3lNblQ3?= =?utf-8?B?c3RvYWRwakozUHFzdFBJZlZzNWdnU0hqS0paQmxiK3B2S1dYc2kzK05lMW5E?= =?utf-8?B?S1dxallIUDJJUWpuTkhzZ2tJU0NMUEpHZ2RsSEJjc0hQTk1UUmFUL21ZMVRq?= =?utf-8?B?aE1abExzRmphQTE1djFoblIzTjU4dnNVSHZEbGNVNHNvZnNBdERQQ09NeHZO?= =?utf-8?B?dFpDK2lVTVNUMmVqUUpqVDE1MnRCazlKMkZkaW1PU2c0b0tqL0Z0Umc0alpP?= =?utf-8?B?Uk1ubmlEK2tlWS9YZDZPOUhTU0hCQTFlYnEyTC9HNEdJd2VLejdHdnBsUXhY?= =?utf-8?B?SmpIZHFyQXQzUEk4OFZneHJNdEFsNmFHclRLWW1lYzY0YTJwZ29JVTR4Q3Nx?= =?utf-8?B?cXIzZ1luUktYeGFoK0dKeThUN1l0eDI0NHZMdDNrdmN4YWMvSkZBMUI2L09i?= =?utf-8?B?eHNETVVBcGQ2Rnhnc3BWQWxrWXVyYVMyZURYTVBwUXpJUFcwcTU0c0hzMEZG?= =?utf-8?B?VkdFbzJROU1IQlNTREcrSE9ZU1QxbitQRnZGYS92d3BpRTJvaU9CRDJ6c09u?= =?utf-8?B?MVI3T0J2TitQSUpmMSt2cWxEMnEzV0tTbEkwcmRqOUMwR25ZVjR2WFFBcHJo?= =?utf-8?B?anoxbEJ5bW9xYzRNa2ZzY1VEWUZMU29Xc2ZqK3FqNE9GMlJXS2IzbHZSVXlO?= =?utf-8?B?UDF1WDhQdXJkdmZ4ZmhYSmx1Snp0SStJS2VBeU9LalgrSTlNZW15TzZaYVRC?= =?utf-8?B?ZGZML0xqQXQybFRvTmk3L0VwNG9TLzFTZ2RVdXJsUWJ6SVVUSWx6RGhvMFRx?= =?utf-8?B?eUJFSXZqRDg3MVk3b1RhSU5iZlY2NDBKUVdXTkxRdVZxSFNiSTR4dCtpdkdu?= =?utf-8?B?N3ZxdnJTY2xNSmhXeU15QnVvbkRDU1p3Wk0xYWwybU0zT0M1SEtMeUhXcTBx?= =?utf-8?Q?hAzXxOE0yxFQfxauMR8OWzn0la1U9mymI3VbI0t?=
X-OriginatorOrg: uniovi.es
X-MS-Exchange-CrossTenant-Network-Message-Id: 16281fbb-94fd-4fea-0a68-08d90fbc6496
X-MS-Exchange-CrossTenant-AuthSource: DBBPR08MB6202.eurprd08.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 May 2021 11:53:26.7669 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 05ea74a3-92c5-4c31-978a-925c3c799cd0
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 8MTI0gDfl1Ahi5vUS2gSfMCUkXEkiZpJfG+u1/9B6CSrWpOd5WRS/lP68ELRrXvpK44SYZsNu5YCqQqcfWUwuw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0801MB1959
X-MS-Exchange-CrossPremises-AuthSource: DBBPR08MB6202.eurprd08.prod.outlook.com
X-MS-Exchange-CrossPremises-AuthAs: Internal
X-MS-Exchange-CrossPremises-AuthMechanism: 06
X-MS-Exchange-CrossPremises-Mapi-Admin-Submission:
X-MS-Exchange-CrossPremises-MessageSource: StoreDriver
X-MS-Exchange-CrossPremises-BCC:
X-MS-Exchange-CrossPremises-OriginalClientIPAddress: 156.35.225.67
X-MS-Exchange-CrossPremises-TransportTrafficType: Email
X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0;
X-MS-Exchange-CrossPremises-SCL: 1
X-MS-Exchange-CrossPremises-Processed-By-Journaling: Journal Agent
X-OrganizationHeadersPreserved: DB6PR0801MB1959.eurprd08.prod.outlook.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/5_S959xDeIcnf9pBmRyWzjiyijE>
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: Wed, 05 May 2021 11:53:36 -0000

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