IETF Logo Mail Archive

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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 17 November 2017 15:59 UTC

Return-Path: <pthubert@cisco.com>
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 EC2891243FE for <6tisch@ietfa.amsl.com>; Fri, 17 Nov 2017 07:59:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level:
X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 y57k-9wC9oQa for <6tisch@ietfa.amsl.com>; Fri, 17 Nov 2017 07:59:20 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E12D0126FDC for <6tisch@ietf.org>; Fri, 17 Nov 2017 07:59:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8801; q=dns/txt; s=iport; t=1510934359; x=1512143959; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=udo02MpJx3Y3QUvvJ0w9c1wSL2X95XysbFE9BmaVoe8=; b=Z3sEtEX2mYbxeGLwk06KcRU7zhCDcaR80VYeJD79foQB61AlT2ZcrtKP /G9IG7+Nn9+kFOD2Skk3ZkRkkl/POThTgsEqPLqHkH0X/Y7q7U2iVPReY zj89I6lSVyO5QmIwwabK4p2ccybBRonmetRZG6Gm2bS0AQMbqmEMS9+e/ E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AUAQCjBg9a/4YNJK1bGQEBAQEBAQEBAQEBAQcBAQEBAYM8gVIng3+KH48lkxaFSYIRCoIBgzoCGoRNPxgBAQEBAQEBAQFrKIUfBiNWEAIBBgI/AwICAjAUEQIECgQFiUFkjCqdaIIniwIBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgzSCB4FVgWkpgwKIMDGCMgWiPgKVCpNMlgUCERkBgTkBHzmBdHoVdgGCNoJcHIFnd4pWAQEB
X-IronPort-AV: E=Sophos; i="5.44,410,1505779200"; d="scan'208,217"; a="32344994"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Nov 2017 15:59:19 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id vAHFxJid031051 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 17 Nov 2017 15:59:19 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 17 Nov 2017 09:59:17 -0600
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Fri, 17 Nov 2017 09:59:18 -0600
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
CC: Thomas Watteyne <thomas.watteyne@inria.fr>, "6tisch@ietf.org" <6tisch@ietf.org>
Thread-Topic: [6tisch] tagging join traffic wih DSCP: why inside IP header?
Thread-Index: AQHTXX7XkXA3VPJ770+1uJQzOJ8GOaMUpmAwgAKrEVGAAH18NIABOwAA//+1Ie4=
Date: Fri, 17 Nov 2017 15:59:18 +0000
Message-ID: <DB06B936-5E63-47F5-B1B7-E31A3C9E7E86@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>, <2670.1510928836@obiwan.sandelman.ca>
In-Reply-To: <2670.1510928836@obiwan.sandelman.ca>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_DB06B9365E6347F5B1B7E31A3C9E7E86ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/N0qa0dwBKifUI7kkrKdSVpFqMb8>
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 15:59:22 -0000

That’s RFC 3046 sorry for the typo 😊

Small phone fat fingers...

Pascal

Le 17 nov. 2017 à 22:27, Michael Richardson <mcr+ietf@sandelman.ca<mailto:mcr+ietf@sandelman.ca>> a écrit :


Pascal Thubert (pthubert) <pthubert@cisco.com<mailto: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<mailto:mcr+IETF@sandelman.ca>>, Sandelman Software Works
-= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email