IETF Logo Mail Archive

Re: [6tisch-security] transporting Router Advertisements in Extended Beacons: draft-richardson-6lo-ra-in-ie

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 19 October 2016 13:49 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 041A212957A; Wed, 19 Oct 2016 06:49:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.332
X-Spam-Level:
X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431, 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 SBQ7Gld-xYXb; Wed, 19 Oct 2016 06:49:29 -0700 (PDT)
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 D5AB21295E3; Wed, 19 Oct 2016 06:49:28 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 081C9203B0; Wed, 19 Oct 2016 10:04:06 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 61F6063AFE; Wed, 19 Oct 2016 09:49:27 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: 6tisch@ietf.org, 6lo@ietf.org
In-Reply-To: <12199.1476807186@obiwan.sandelman.ca>
References: <147680041580.30853.17692159482786173917.idtracker@ietfa.amsl.com> <12199.1476807186@obiwan.sandelman.ca>
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-sha1"; protocol="application/pgp-signature"
Date: Wed, 19 Oct 2016 09:49:27 -0400
Message-ID: <11163.1476884967@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch-security/mr1-BXByBYubR-KQKQQjP5K5zWM>
Cc: 6tisch-security@ietf.org
Subject: Re: [6tisch-security] transporting Router Advertisements in Extended Beacons: draft-richardson-6lo-ra-in-ie
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, 19 Oct 2016 13:49:31 -0000

to reply to myself

Michael Richardson <mcr+ietf@sandelman.ca> wrote:
    > This will contain a copy of the 16-byte DODAGID so that a very sleepy
    > node returning to operation would be able to identify which beacon
    > belongs to which network.  A joining node will have no idea which
    > DODAGID it wants, and a maliciously sent beacon could have any manner
    > is superfuge here.  Nodes which have already joined the network SHOULD
    > be able to authenticate the beacons.  However, this is one of the
    > larger objects in the 56 bytes that I describe, and maybe it is
    > excessive to store so many bytes here.

I realized today that the RA probably also needs to carry the ABRO to be
useful to secured hosts.  Such hosts will still have to unicast as RS to get
the PIO from a router.  I'm sure that we don't want to put the PIO into an
unencrypted EB/RA.

The ARBO has the 6LBR address which is often, but not always the same as the
DODAGID.   It can equally well be used to identify the network.

    > I want to attempt to apply RFC7400 (GHC) to this, the savings will be
    > probably on the order of ten bytes of zeroes.

So far, the savings I got with GHC was 4 bytes.  I posted an update to the
git repo.  (     https://github.com/ietf-roll/6lo-ra-in-ie )


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

v2.23.0 | Report a Bug | By Email