Re: [Ace] ACE Implementation for Disadvantaged Environments

Sebastian Echeverria <secheverria@sei.cmu.edu> Wed, 30 January 2019 17:11 UTC

Return-Path: <secheverria@sei.cmu.edu>
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 7B4EF1294D0 for <ace@ietfa.amsl.com>; Wed, 30 Jan 2019 09:11:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=sei.cmu.edu
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 5JrRilEyJsLe for <ace@ietfa.amsl.com>; Wed, 30 Jan 2019 09:11:12 -0800 (PST)
Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 2F2B7130E93 for <ace@ietf.org>; Wed, 30 Jan 2019 09:11:10 -0800 (PST)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x0UHB7VR012261; Wed, 30 Jan 2019 12:11:07 -0500
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x0UHB7VR012261
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sei.cmu.edu; s=t52kn2igOmwp; t=1548868267; bh=0hwL5Q0axYyIoQkp0RI4TPpQAzlukui68U//6HSluf8=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=Fsrw+mHzA3xXen9ytCoT0Lvtx8kciwwtX+rBPBAnoUkY77GCFwePP/DPPSVAS//P2 EhYMvDYrQuVHrP1RIvAMpH+qyNmiTD5F0IRWZaopZFOm+zZ+9BXtbwr71S0YnoqBOt 0easzW9/I2wWi/WkEEwSL53IjZ4yRllud78ubVUA=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x0UHB6L1048052; Wed, 30 Jan 2019 12:11:07 -0500
Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0435.000; Wed, 30 Jan 2019 12:11:06 -0500
From: Sebastian Echeverria <secheverria@sei.cmu.edu>
To: Michael Richardson <mcr@sandelman.ca>
CC: "ace@ietf.org" <ace@ietf.org>, Grace A Lewis <glewis@sei.cmu.edu>, Dan Klinedinst <djklinedinst@cert.org>
Thread-Topic: [Ace] ACE Implementation for Disadvantaged Environments
Thread-Index: AQHUs0cwxz8vJeWIVUGFns83Bt0/66XEercQgAA76QCAABjZAIAA4VeAgAJmMoA=
Date: Wed, 30 Jan 2019 17:11:05 +0000
Message-ID: <213790F7-BEFE-4A90-A25C-D3A257B559A1@sei.cmu.edu>
References: <11C08BF5-0060-459C-99DC-EABEA88DF44B@sei.cmu.edu> <VI1PR0801MB211293C28BD614D6CD8D7254FA960@VI1PR0801MB2112.eurprd08.prod.outlook.com> <0FCF1038-D6C8-4C25-9B4C-E493EB817592@sei.cmu.edu> <7387610A-D857-49FE-9964-77D54CDDA2F4@sei.cmu.edu> <23315.1548718367@localhost>
In-Reply-To: <23315.1548718367@localhost>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.200.127]
Content-Type: text/plain; charset="utf-8"
Content-ID: <BDA2A1C05C2D064ABF4EC3B06276DB13@sei.cmu.edu>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/tmhbKHyi-MOwnTVNqD6oNPUS1qE>
Subject: Re: [Ace] ACE Implementation for Disadvantaged Environments
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, 30 Jan 2019 17:11:15 -0000

Hello Michael,

Thanks! Answers to your questions here:

 - We used plain Contiki, since we forked from 6lbr, which itself forked from plain Contiki (we did this since 6lbr already had CoAPs functionality implemented). We have given thought to migrating to Contiki-ng, so that could happen at some point.

- By disadvantaged networks we do mean something similar to constrained networks as defined in RFC 7228. In the past we've mostly focused on DIL (Disconnected, intermittent, and limited bandwidth) environments mostly due to the mobility of the devices involved and the environmental conditions of our use cases. But most of the constraints are similar.

 - We are striving to get it down to around 250 kb, but we haven't spent that much time yet trimming it down. With some work, we should probably be able to get there.

Thanks for your comments!

Sebastian

On 1/28/19, 6:51 PM, "Michael Richardson" <mcr@sandelman.ca> wrote:

    
    Thanks for the report!
    
    Sebastian Echeverria <secheverria@sei.cmu.edu> wrote:
        > * We used Contiki as the base/OS for the code. More specifically, we
        > forked
    
    Contiki, or contiki-ng?
    
        > from the 6lbr project (https://github.com/cetic/6lbr), as that version
        > already had some code for handling DTLS connections and AES encryption in
        > it.
    
    
        > * We are using the TI CC2538dk board as our constrained target platform.
    
    
        > * The implementation has support for the DTLS profile, using pre-shared keys,
        > as this was enough for our use case.
    
    Yes, but often not really enough for a deployment where we need certificates
    or raw public keys, and this may have significant affects on packet sizes :-(
    
        > * We modified the Erbium CoAP server in 6lbr to be able to simultaneously
        > listen for CoAP and CoAPs connections (using TinyDTLS underneath).
    
    That's an interesting and useful change.
    
        > * The implementation has some additional optional features related to our
        > disadvantaged network environments, such as bootstrapping of the PSK
        > credentials, and detecting revoked tokens through introspection.
    
    When you say "disadvantaged", I think that you mean "constrained",
    as per RFC7228?
    
        > * The current binary is around 300 kb, which is good enough for the 512 kb
        > flash on the TI boards, though it may be a bit too large for a class II
        > device. We can probably make it a bit smaller. In terms of RAM, it fits in
        > the 32 KB available on the TI boards.
    
    The key number is 256K, so that one can double buffer the firmware image.
    
    --
    ]               Never tell me the odds!                 | ipv6 mesh networks [
    ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
    ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [