Re: [6tisch] Tagging join traffic

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 29 November 2017 15:36 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 7F1F612711B for <6tisch@ietfa.amsl.com>; Wed, 29 Nov 2017 07:36:52 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, 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 rq9Pg9N2LF0k for <6tisch@ietfa.amsl.com>; Wed, 29 Nov 2017 07:36:51 -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 552EE124B18 for <6tisch@ietf.org>; Wed, 29 Nov 2017 07:36:51 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id DF65220008 for <6tisch@ietf.org>; Wed, 29 Nov 2017 10:39:20 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6623B807CC for <6tisch@ietf.org>; Wed, 29 Nov 2017 10:36:50 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: 6tisch <6tisch@ietf.org>
In-Reply-To: <D28EDD34-A92B-4853-8245-65DEA62697D3@cisco.com>
References: <07BA1D2B-2546-4E7B-B722-0CCE1E395BEE@inria.fr> <5691.1509986797@dooku.sandelman.ca>, <7888.1511918950@obiwan.sandelman.ca> <D28EDD34-A92B-4853-8245-65DEA62697D3@cisco.com>
X-Mailer: MH-E 8.6; nmh 1.7-RC3; 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, 29 Nov 2017 10:36:50 -0500
Message-ID: <6445.1511969810@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/gvxTYhRHJ78TQ4545Xc4-gUDbys>
Subject: Re: [6tisch] Tagging join traffic
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 29 Nov 2017 15:36:52 -0000

Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
    > Yet not sure the MAY on the return path is a good idea. Either make it
    > a SHOULD or a no no. Otherwise we do not know what to expect in a given
    > network with mixed implementations.

I can live with SHOULD.
SHOULD means that a co-located JRC which has access to the scheduling APIs
can do the right thing and not have to spend a byte on DSCP.
As I say, the 6LBR can also have an ACL to recognize the join responses.

    > I think that it is actually an important traffic now that security
    > checks were done. More so than some data from a sensor. It is probably
    > still a good idea to tag this packet and the rest of the join but not
    > with AF43. We want to favor it over data else the network will never
    > come up...

yes, I agree with the argument, and I was thinking it myself.  S
Should be be AF42 then?  Something higher?
Or do you propose some other treatment?

Please realize that the tagging that we do for 6tisch-minimal-security will
also be identically used for 6tisch-zerotouch-join, and that traffic might be
larger, and it will take some additional round trips before we know that the
node is legitimate.  (many RTTs if we have to use DTLS, two if we can have EDHOC)

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