IETF Logo Mail Archive

Re: [6tisch] tagging join traffic wih DSCP: why inside IP header?

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 17 November 2017 14:27 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 ECC59126DCA for <6tisch@ietfa.amsl.com>; Fri, 17 Nov 2017 06:27:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 G7pH1Q5Ajqam for <6tisch@ietfa.amsl.com>; Fri, 17 Nov 2017 06:27:18 -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 465FB120727 for <6tisch@ietf.org>; Fri, 17 Nov 2017 06:27:18 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9B9AE20072; Fri, 17 Nov 2017 09:29:05 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0151382B25; Fri, 17 Nov 2017 09:27:17 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
cc: Thomas Watteyne <thomas.watteyne@inria.fr>, "6tisch@ietf.org" <6tisch@ietf.org>
In-Reply-To: <4673E5F7-CFF7-4283-8C59-14498F6FCC5D@cisco.com>
References: <CADJ9OA_cKxWZLvfpNXhjNgL1HurfdK-Oqj1M-wU9pK5t+1kU4g@mail.gmail.com> <20396.1510678103@obiwan.sandelman.ca> <32033.1510687749@obiwan.sandelman.ca> <92bca0456cb746c995733131edad10a2@XCH-RCD-001.cisco.com> <CADJ9OA_b2fHUg=3utnCv8iTMZcwL-n3J_H2N6uU=v8SjenjmFA@mail.gmail.com>, <12598.1510855839@obiwan.sandelman.ca> <4673E5F7-CFF7-4283-8C59-14498F6FCC5D@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: Fri, 17 Nov 2017 09:27:16 -0500
Message-ID: <2670.1510928836@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/1KxGmcq-7gOMUkX9bCKXRYNYOuM>
Subject: Re: [6tisch] tagging join traffic wih DSCP: why inside IP header?
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: Fri, 17 Nov 2017 14:27:20 -0000

Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
    > Looks like a great idea Michael.

    > In an ideal world the Root would become a filtering Join Relay (think
    > DHCP relay here).

Yes.... although once the traffic has reached the root, the network has
already paid for it, so filtering it is less interesting, I think.

Can 6p allocate bandwidth in the reverse direction? i.e. could the DAGroot,
seeing a lot of legitimate join traffic from some branch allocate more
bandwidth towards itself (the DAGroot)?  I think that this is planned, but
beyond minimal, right?

    > Like in RFC 3048, this also means extra information for the relayed

RFC3048: Reliable Multicast Transport Building Blocks for One-to-Many
         Bulk-Data Transfer

I think this might be a typo, but I tried 3408 and 3084, and neither made
sense either.

    > packets, so the JR can point on its local state of the pledge on the
    > way back (if the root is JR it needs the addresses of the JP or a
    > locally significant pointer to it).

The DAGroot can encapsulate the traffic entirely (VXLAN, GRE, IPsec), or
could terminate the CoAP/UDP traffic into a NAT64 if it wants.  Anything is
possible, but it's all out of scope.
Having said this, I believe that proxies SHOULD support a JRC address which
is not the DAGroot.  In addition to the off-LLN situation, there is also the
case where there are multiple possible DAGroots, but only one of them intends
to be the JRC, yet the other DAGroot is for whatever reason the active one.

    > Are there security implications that do not foresee, like which of the
    > JP and JR has an SA with the JRC vs end to end protection of the join
    > response?

You write "JR" and "JRC" in the same sentence, and I thought above that JR
was just short for JRC.   Whether it's DTLS or OSCORE or ???, the SA is
always between the pledge and the JRC, and the rest are just helpful plumbing.

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

v2.23.0 | Report a Bug | By Email