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

Tengfei Chang <tengfei.chang@gmail.com> Fri, 06 December 2019 17:49 UTC

Return-Path: <tengfei.chang@gmail.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 8E075120071 for <6tisch@ietfa.amsl.com>; Fri, 6 Dec 2019 09:49:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.397
X-Spam-Level:
X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 0194ClmmMlGm for <6tisch@ietfa.amsl.com>; Fri, 6 Dec 2019 09:49:12 -0800 (PST)
Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A16A412016E for <6tisch@ietf.org>; Fri, 6 Dec 2019 09:49:09 -0800 (PST)
Received: by mail-pl1-x630.google.com with SMTP id s10so3022312plp.2 for <6tisch@ietf.org>; Fri, 06 Dec 2019 09:49:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zY4wKIDAcPdud/vPEOdgf3oww6BwMh+GRAJ+HYoaR1w=; b=QsU7vk30mT2XomRpIZQ654ZOCtjvSgZTJusuBEmXwBvk+OQnIRRDzDj7vf6Nox1mOl b3jG1mtlUqkwCosWPq2gdsxJW/aXjM7fEIAJwktkl4WCcUUXBD8ab7czp6KrnV7hDWFa TWkT51c7ULxIEfPJ3LY5NsHnGHequqAXQuSmAb44wxWNFarIP4b84SA5WBDY6rm1fMyz wZaRWFdD/JSFuRMm2M4KhnK1k/Q+xp9xlcrwZtzk2cNEl6GPhXWh4KAYnf0gZj2YZe4W cTg6lP79JXLRdAWDXLj4LWPBLFc6BglzNoiM2tiiNEThSSKx8RnLbgL5E9y6Pc1WHdO3 pC+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zY4wKIDAcPdud/vPEOdgf3oww6BwMh+GRAJ+HYoaR1w=; b=FHAQSbVoQyRVq1s16Oc9w7UBrUfhkZ+Sc4QygblMc3TOObWMcyJKB+hzp7Hh6GsU38 ZaiI2cIdMm98BTLO6ZolpKTswHjZE/hFCqN4OGXfXWCfABSwGSkdAc5Qjr4nxvs2hA1V lmjiD0X3NJaDi+5cFIp4Ht0mMUyJlXjK01vVhJd73aPvYr8a6OloaHeP/BnSAP5c+ZUq 2hkr28CsRJmsZW2BpF3g6eGCj1I97REl+6kWyt7Pz4HanvN6PSDNc23fVrWr3t0Ykuwr WsqcR18zkFn9BDGeLVYUcvmtXLiqWTlP44U2R6ldkbcQXT/Wfq1p5fReRXTjDilvMr2W ALAg==
X-Gm-Message-State: APjAAAV+MkHPaWiSBewb8De4/OruRWla3Q9YuvS8ykxezl+JmtX6nM2/ J5jAO2MDx2yg7O32xIgaIZnf2NC78q5KGrK913pEM7yihIA=
X-Google-Smtp-Source: APXvYqxgGVrvT29/roWY5Q0C9eaJrYQfUxnDQ5mVXyxADmH8hdpSrGeo/cyxrcytun+Z824j/jW+B7Z/AGUFkDpR+Fc=
X-Received: by 2002:a17:90a:1a1a:: with SMTP id 26mr17002793pjk.129.1575654549057; Fri, 06 Dec 2019 09:49:09 -0800 (PST)
MIME-Version: 1.0
References: <CAAdgstRGHyRKoMLBhRih8yHwDvf-DTp42ZTEBmBP57FSgt8MyA@mail.gmail.com> <MN2PR11MB35652B278DB4225DAAE30956D85C0@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB35652B278DB4225DAAE30956D85C0@MN2PR11MB3565.namprd11.prod.outlook.com>
From: Tengfei Chang <tengfei.chang@gmail.com>
Date: Fri, 6 Dec 2019 18:48:57 +0100
Message-ID: <CAAdgstQG7nkXr7tKffdChftjd8JDG4LvyOqepFsQ8eqZqHt0Aw@mail.gmail.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: 6tisch <6tisch@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000af784505990ca9d6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/u__fs0nJqZkUv1XYfFFkrDXpaik>
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 17:49:16 -0000

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>
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> *On Behalf Of *Tengfei Chang
> *Sent:* jeudi 5 décembre 2019 08:18
> *To:* 6tisch <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/
>
> ——————————————————————————————————————
>


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

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/
——————————————————————————————————————