Re: [6tisch] Benjamin Kaduk's No Objection on draft-ietf-6tisch-enrollment-enhanced-beacon-13: (with COMMENT)

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 24 February 2020 00:31 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5F73A12B1; Sun, 23 Feb 2020 16:31:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Jg5FFajNwlIs; Sun, 23 Feb 2020 16:31:28 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E9033A12AF; Sun, 23 Feb 2020 16:31:26 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 44C003897C; Sun, 23 Feb 2020 19:30:26 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2EA345A0; Sun, 23 Feb 2020 19:31:25 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Benjamin Kaduk <kaduk@mit.edu>
cc: The IESG <iesg@ietf.org>, pthubert@cisco.com, 6tisch-chairs@ietf.org, 6tisch@ietf.org, draft-ietf-6tisch-enrollment-enhanced-beacon@ietf.org
In-Reply-To: <20200222051155.GJ53538@kduck.mit.edu>
References: <158206755196.14101.10514108989438939697.idtracker@ietfa.amsl.com> <3706.1582226579@dooku> <20200222051155.GJ53538@kduck.mit.edu>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.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: Sun, 23 Feb 2020 19:31:25 -0500
Message-ID: <9524.1582504285@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/TPyAAqiB_Rhnj4DLMZF7PfktSrY>
Subject: Re: [6tisch] Benjamin Kaduk's No Objection on draft-ietf-6tisch-enrollment-enhanced-beacon-13: (with COMMENT)
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Feb 2020 00:31:30 -0000

Benjamin Kaduk <kaduk@mit.edu> wrote:
    > Thanks for these updates!  I see you had one question at the end...

    >> >    visible.  Encrypting the schedule does not prevent an attacker from
    >> > jamming, but rather increases the energy cost of doing that jamming.
    >>
    >> > Perhaps also the side effects/collateral damage of the jamming.
    >>
    >> I'm not sure what you are saying/suggesting here.

    > If the attacker doesn't know the schedule, they use more power ("energy
    > cost") to jam all the time, in some sort of always-on broadband jamming
    > technique.  This broadband jamming could end up blocking traffic the
    > attacker doesn't care about, in addition to the target of the jamming;
    > that in turn might make the fact that the attacker is jamming at all easier
    > to detect.  I'm suggesting that the attacker's decision process about
    > whether/how to jam is much more complicated if they don't have the schedule
    > available, and there are additional factors that would come into play that
    > might discourage the attacker from jamming even though (as is already
    > noted) it does not "prevent" the attacker from jamming.

So, just to be clear, the schedule is happening thanks to RFC8180, section 4.5.
What this document adds is the ability to determine which EB are from the
same network, even if they have different PANID.

There is a very good discussion about the jamming costs in:
      https://datatracker.ietf.org/doc/draft-tiloca-6tisch-robust-scheduling/

Unfortunately, it isn't clear if this work can go ahead in the IETF as it
apparently makes changes that the IEEE is responsible for.  At the same time,
it must coordinate with (re-)keying , which the IEEE is not responsible for.

I don't know what else I could say in enhanced beacon about this.
The topic of selective jamming is a bit distant from this document.

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


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