Re: [6tisch] MSF adapts to traffic only for secured packets

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 06 December 2019 18:03 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 8820A1200F9 for <6tisch@ietfa.amsl.com>; Fri, 6 Dec 2019 10:03:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.899
X-Spam-Level:
X-Spam-Status: No, score=-13.899 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1, 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 header.b=E9nPaM1p; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=kRvVfaGd
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 gxyuF66ei11q for <6tisch@ietfa.amsl.com>; Fri, 6 Dec 2019 10:03:32 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E43F1200A3 for <6tisch@ietf.org>; Fri, 6 Dec 2019 10:03:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18265; q=dns/txt; s=iport; t=1575655412; x=1576865012; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dsNTCuQOUF5Q1hmps6+bpiuI5AKD1nNB+PwC+PZz4bQ=; b=E9nPaM1pD92LYV6WypihsfsuWQ/gtXld1PQaMJKD8FjJBOnqW8um029C VDg3CE1CGGsCT2sB0ay6bGSo73a7uOmFrj9Dm+j4RAi40wosOaT5ucmH6 68ATqIplAnD6fTf15rBpZntHFVggo6Z/cqQi8ICICB4yl/TtJVJaSj7E1 E=;
IronPort-PHdr: 9a23:IlU3XB2PuaAGQOiksmDT+zVfbzU7u7jyIg8e44YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSwdDjMwXmwI6B8vQEVH7MfTndTASF8VZX1gj9Ha+YgBY
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BmCACYlupd/5RdJa1lHAEBAQEBBwEBEQEEBAEBgX6BHC9QBWwPSSAECyqELINGA4p/gjoliVuJSIRiglIDVAkBAQEMAQEbEgIBAYRAAheBfiQ4EwIDDQEBBAEBAQIBBQRthTcMhVIBAQEBAxIRHQEBMAcBDwIBBgIRBAEBKAMCAgIfERQJCAIEDgUJGYMAAYF5TQMuAQKSCJBkAoE4iGF1gTKCfgEBBYJKglANC4IXCYE2hRyGfBqBQT+BOAwUgkw+ghuCZAiCUjKCLJAnhVCJTo5TQwqCLpFHhB4bgkKMM4UghhyZJI9QAgQCBAUCDgEBBYFpIoFYcBVlAYJBCUcRFIxmg3OFFIU/dIEojVABAQ
X-IronPort-AV: E=Sophos;i="5.69,285,1571702400"; d="scan'208,217";a="679150062"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Dec 2019 18:03:28 +0000
Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id xB6I3QZ3031279 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 6 Dec 2019 18:03:28 GMT
Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 6 Dec 2019 12:03:26 -0600
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 6 Dec 2019 12:03:26 -0600
Received: from NAM04-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 6 Dec 2019 13:03:25 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Msoa/eq7QEsRgVefa6hqq/NHvjyK5KSex4IGdJius7Tp3qWgOMJXrur2BDngJLcRv1mIRYRZXwMIz6DCZJPV7rhZbp6LUT808OnkfT2RRETwms0WNWVbEoRk+FDnWqkebIK92DaxlfXuShuneloQWmlgfHT+i966rotiYzhChjpiUZIR/5ZScWCJix8ebuLdYuR0e7pjw1Ow5l6DJvBvXnOc/hhtCngJQW/6p5/Mniyj4era3XBKyahN2M9dusWZ9aU7dhj1r9Dhg0Qyjg+3Z7pzZEF2oWercU6f+88bYHyL0iTWHRpE5FU14+3R0n/y5ziQEFRVxz7jUC7bNsshaA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dsNTCuQOUF5Q1hmps6+bpiuI5AKD1nNB+PwC+PZz4bQ=; b=M1M9aV/+AnMM51jjPKHYT8VVM2mJFqAMHqgVK5pc1cjFwNkex6ARGOmdddEpXHhTBlP80GE1/OdaT4Td0j8xjpyAVztVvh7aMRLwebOpCPClhf3pF6ZT9Qe1JVNjSuexwxYpPsvgLbssJ+vKNV8aT0uCNPcXxSplRi1dsfmnfHuUDU8PiLFHA2nwrkgGgp2ZEEKAIwo1pV1+YKSvnRPs1syx268qgrIR2OLtcKPNU4qbuhyR+rpn/WHbKSdsJIABsl6QfpPoP6TrSONcA86ZZHJMaQ/ZYBGhXbRXQZEPkiYCVmyC+f+BsXLtLb/W3MAeDdhI5mijjNryqRIuFHbvZw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dsNTCuQOUF5Q1hmps6+bpiuI5AKD1nNB+PwC+PZz4bQ=; b=kRvVfaGd4OCic1VMegLfudjqwNf5h0G1QSrxOHrG4Q35XAUzIsIv6Gggtd3gn1gmb9WbNkFq0+3QcGtfOOmTG0RvnlUPweCHpiXqT9vnf6PYgvETmZ8PtiA8xgUvCbESfT15+pFNdhHN28Tpo9twsX1l0HZ/5DmL0et7Io7b6NI=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4031.namprd11.prod.outlook.com (10.255.180.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.22; Fri, 6 Dec 2019 18:03:24 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::3037:66f1:dc79:b564]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::3037:66f1:dc79:b564%7]) with mapi id 15.20.2495.014; Fri, 6 Dec 2019 18:03:24 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Tengfei Chang <tengfei.chang@gmail.com>
CC: 6tisch <6tisch@ietf.org>
Thread-Topic: [6tisch] MSF adapts to traffic only for secured packets
Thread-Index: AQHVq4eZrJKqi5A/BEWNlP7phaDTaaervyzQgAGkooCAAAQKPw==
Date: Fri, 06 Dec 2019 18:03:24 +0000
Message-ID: <F5784750-D459-4219-B4E1-EF9E58E353DE@cisco.com>
References: <CAAdgstRGHyRKoMLBhRih8yHwDvf-DTp42ZTEBmBP57FSgt8MyA@mail.gmail.com> <MN2PR11MB35652B278DB4225DAAE30956D85C0@MN2PR11MB3565.namprd11.prod.outlook.com>, <CAAdgstQG7nkXr7tKffdChftjd8JDG4LvyOqepFsQ8eqZqHt0Aw@mail.gmail.com>
In-Reply-To: <CAAdgstQG7nkXr7tKffdChftjd8JDG4LvyOqepFsQ8eqZqHt0Aw@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [2001:420:30d:1254:58d5:af9c:2a5e:bcb5]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 45481e04-cc18-4f54-4e75-08d77a7696b1
x-ms-traffictypediagnostic: MN2PR11MB4031:
x-microsoft-antispam-prvs: <MN2PR11MB4031F71798E7FD624DD073FCD85F0@MN2PR11MB4031.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 0243E5FD68
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(366004)(376002)(346002)(396003)(189003)(199004)(53754006)(51914003)(8676002)(66946007)(66556008)(64756008)(91956017)(76116006)(66446008)(66476007)(86362001)(8936002)(81166006)(81156014)(186003)(102836004)(6512007)(33656002)(99286004)(54896002)(53546011)(76176011)(36756003)(6916009)(6506007)(5660300002)(2616005)(4326008)(2906002)(316002)(5070765005)(478600001)(229853002)(71200400001)(71190400001)(6486002)(66574012)(244885003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4031; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: j2WovyHwYyQvzKBjCrCjbnqh/JMRYkj2GQRvzJxmU/kT95UcJXUgPj7nMnU1mnzm0cZirKUhr+iIzdv6RxY+izRfticoR1g/mxfxFFyXVUstfTuExOA7M3Mwdpijkrx3S5JeoUL3AAMrsxAYHhn7LWqUH265R8iZFBCQa40aBWQzGuyJIQqs6b41BUV9D0Kdgmx2KQoJiwU+CVYo9D0gJcku5y3Td4jRjLlRuh6TMuQeSEcYs+RCvE2zEXqsXRQrCPF0Bxx4YfEop2TCnXseGQfyVl0nM94AiETfXOggC5w+93BCJKGFTLF0zHim8Yfxl9/OGHIysZ9QEejZYLVZWbO5GsJjrxDbpdOvX95lq/WyqHiX5fZvqDL/HBjJXRqVwfrG/n7qgFYatXtR+UlJeAQuxYhR3F42UQ2dbLJyjSgZvWZevhb3Vojrxybd93xegbig8GuFo2F3ZI8B81E+pGPf/hoaUduxoktyz4tVs9N612+mOV7PfiOn1UaMNItPINsdPN8MbkJugewDFI+F8E03JVhrVsqDUskT2Ixjfjowa8nRHHo0AqykVErSfm7q2K1ahJ4ZCCiII2DTcqb2Yw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_F5784750D4594219B4E1EF9E58E353DEciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 45481e04-cc18-4f54-4e75-08d77a7696b1
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2019 18:03:24.6098 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: zDxUUueX8xGaZTKASmXbzmlf0BebOJkg4XHYi7fvpH/7mSCl2hEphT8vfrc3B7bMLeNKZq8qn/hceNQaeEbWvg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4031
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.25, xch-rcd-015.cisco.com
X-Outbound-Node: rcdn-core-12.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/-dna3jsqZZZKipL5O0C1EC9Kd0s>
Subject: Re: [6tisch] MSF adapts to traffic only for secured packets
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: Fri, 06 Dec 2019 18:03:34 -0000

Yes I do


Regards,

Pascal

Le 6 déc. 2019 à 09:49, Tengfei Chang <tengfei.chang@gmail.com> a écrit :


Pascal,

Yes, MSF indeed aware of the routing information such as RPL parent, I consider this is like an information stored at IPv6 layer that MSF can read it from without touching the frame L2 payload.
In such sense, I could consider the DSCP value can be another information stored at upper layer that MSF have read access to it.

Thinking in this way, it seems OK for me.
Do you agree such interpreting?

Tengfei

On Thu, Dec 5, 2019 at 5:50 PM Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>> wrote:
Hello Tengfei

Architecturally speaking, MSF right now is used to allocate cells in the L3 bundle with a parent.

“

Layer-2 vs. Layer-3 bundle:
Bundles are associated for either Layer-2 (switching) or Layer-3 (routing) forwarding operations. A pair of Layer-3 bundles (one for each direction) maps to an IP Link with a neighbor, whereas a set of Layer-2 bundles (of an "arbitrary" cardinality and direction) corresponds to the relation of one or more incoming bundle(s) from the previous-hop neighbor(s) with one or more outgoing bundle(s) to the next-hop neighbor(s) along a Track as part of the switching role, which may include replication and elimination


“

So even if it is operating under IP, it is working for IP. Even the notion that the neighbor is a parent is an IP layer consideration. So MSF is IPv6-aware.
IOW the IP layer passes an IP packet to the lower layer (6top), and 6top needs to assign the packet to a bundle. Once that is done, if the bundle is managed by MSF, then MSF observes the transmission. Same goes for incoming traffic.

Do you want me to provide the sentences or do you feel safe about putting your own words?


From: 6tisch <6tisch-bounces@ietf.org<mailto:6tisch-bounces@ietf.org>> On Behalf Of Tengfei Chang
Sent: jeudi 5 décembre 2019 08:18
To: 6tisch <6tisch@ietf.org<mailto:6tisch@ietf.org>>
Subject: [6tisch] MSF adapts to traffic only for secured packets

Hi All,

For securing the MSF, (comments from minimal security, thanks for the input!)

In the next version of MSF, we need to add sentence saying MSF only adapts the traffic which is secured, practically by checking the DSCP value set with zero or no, which is in IPv6 header.

In other hands, MSF is a link layer protocol, it doesn't suppose to know the frame is a IPv6 packet or not. no need to say a field value.

I would like to have some suggestions/comments on this issue.
Does anyone know other way to make the SF not adapt to unsecured traffic without knowing upper layer field?

Thanks!
Tengfei
--
——————————————————————————————————————

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/<http://www.tchang.org/>
——————————————————————————————————————


--
——————————————————————————————————————

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/<http://www.tchang.org/>
——————————————————————————————————————