Re: [6tisch-security] Short address assignment

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 22 February 2017 16:00 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: 6tisch-security@ietfa.amsl.com
Delivered-To: 6tisch-security@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACEC0129A5A for <6tisch-security@ietfa.amsl.com>; Wed, 22 Feb 2017 08:00:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 wNhTeHZaCnwv for <6tisch-security@ietfa.amsl.com>; Wed, 22 Feb 2017 08:00:44 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ADE7129A41 for <6tisch-security@ietf.org>; Wed, 22 Feb 2017 08:00:44 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6271C200A3; Wed, 22 Feb 2017 11:22:35 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 860D9636BB; Wed, 22 Feb 2017 11:00:41 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: 6tisch-security@ietf.org
In-Reply-To: <22592.7216.968126.340725@fireball.acr.fi>
References: <22592.7216.968126.340725@fireball.acr.fi>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Wed, 22 Feb 2017 11:00:41 -0500
Message-ID: <26408.1487779241@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch-security/5ecU3lhnoWJh-R0fOnPgGW0b6aI>
Cc: Tero Kivinen <kivinen@iki.fi>
Subject: Re: [6tisch-security] Short address assignment
X-BeenThere: 6tisch-security@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch-security>, <mailto:6tisch-security-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch-security/>
List-Post: <mailto:6tisch-security@ietf.org>
List-Help: <mailto:6tisch-security-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch-security>, <mailto:6tisch-security-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Feb 2017 16:00:47 -0000

Tero Kivinen <kivinen@iki.fi> wrote:
    > During the teleconf I pointed out about the issues with the short
    > address assignments and security. This email provides background
    > information and explains the situation bit more.

thank you!

    > When using TSCH the situation is bit different as Frame counter is
    > replaced with network global ASN. This means that Source address part
    > needs to be unique for that timeslot. This means that coordinator

Attached below is a yang module to describe the short-address assignment.

    > PAN ID is added, as large networks might use multiple PANs, but still
    > use same secret key (it does not matter whether the ASNs are in sync or
    > not).

Do you think we should slip the PANID in with the short-address assignment?

We have not explained how the pledge knows about PANIDs: clearly it could
just use whatever PANID the beacons it hears contain.   Do you think we need
to be more explicit?

Perhaps we should at least put it in the yang model such that it read back?
I have included an inception date for the short-address for this reason as
well. I called it "effectiveat", but maybe there is a better name.

====

module ietf-6tisch-short-address {
  yang-version 1.1;

  namespace
    "urn:ietf:params:xml:ns:yang:6tisch-shortaddress";
  prefix "ietf6shortaddr";

  //import ietf-yang-types { prefix yang; }
  //import ietf-inet-types { prefix inet; }

  organization
   "IETF 6tisch Working Group";

  contact
   "WG Web:   <http://tools.ietf.org/wg/6tisch/>
    WG List:  <mailto:6tisch@ietf.org>
    Author:   Michael Richardson
              <mailto:mcr+ietf@sandelman.ca>";

  description
   "This module defines an interface to set and interrogate the short (16-bit) layer-2 address
    used in 802.15.4 TSCH mode networks.  The short addresses are used in L2 frames
    to save space.  A lifetime is included in terms of TSCH Absolute Slot Number, which
    acts as a monotonically increasing clock.  ";

  revision "2017-03-01" {
    description
     "Initial version";
    reference
     "RFC XXXX: 6tisch minimal security";
  }

  // top-level container
  container ietf6shortaddresses {
    config false;
    description
      "A 16-bit short address for use by the node.";

    leaf shortaddress {
      type binary;
      length 2;
      mandatory true;
      description
        "The two byte short address to be set.";
    }
    leaf validuntil {
      type uint32;
      description "The Absolute Slot Number/256 at which the address ceases to be valid.";
      mandatory true;
    }

    leaf effectiveat {
      type uint32;
      description "The Absolute Slot Number/256 at which time the address was originally set. This is a read-only attribute that records the ASN when the shortaddress element was last written or updated.";
      mandatory false;
    }
  }
}


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-