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

Tengfei Chang <tengfei.chang@gmail.com> Fri, 06 December 2019 21: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 00A7D12006B for <6tisch@ietfa.amsl.com>; Fri, 6 Dec 2019 13:49:52 -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 A--nLI-798iz for <6tisch@ietfa.amsl.com>; Fri, 6 Dec 2019 13:49:50 -0800 (PST)
Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (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 7E18D12002F for <6tisch@ietf.org>; Fri, 6 Dec 2019 13:49:50 -0800 (PST)
Received: by mail-pl1-x62c.google.com with SMTP id h13so3281307plr.1 for <6tisch@ietf.org>; Fri, 06 Dec 2019 13:49:50 -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=75r0Ben0FAlX9WPCb/NE5DQcl/2RCCx88gOCv/T0X9U=; b=Os2fRLzcCgmNnHe3pHd3TXrcMvk2sgp34Fw+dWPQgZ59NPSFAeGL5pB7EFHYJDEB6d zcRkJGd+bfdBny9G62OYBIrskWl817DhOOXjCdMsET7i4+EZ0hc43vVQF9HYaNtqXIp9 5rGyPUYmN/pkYuxRGzamltPcQbuuPPyxKC+JC6HaeVwjnzs9DMUMuVG95JSLKkbZyYiE idhf7Q6AFqUbLZak8sfI/xATjJB6LKv1lbe55unNOWHYAJW9+Lkz143u5wpQLmo0Qokt NCIJQJcKBaENFE4eJsmBYfwyxeX9E8rhLlwEXBjSqu884SgLj2Bcdbm+dHMUErZ+ZOot ZbBQ==
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=75r0Ben0FAlX9WPCb/NE5DQcl/2RCCx88gOCv/T0X9U=; b=rGyVW7cUtZvGnPIDjkxMkq/5ULCnlFr91Sjl0S3b+WUhwp6RzH2OtyQuxPHJKWUBIU bB7n9gCx7u4iqRbVpA2Qp5Jsnh8nRyQjlkCcxlvL3GVaeyzZ2XQkH7Z8KhhtsRbW5fXD DNgQVKzwkimAEsBJ/4DbMQ1UcMOzupmse7tbQbv33/2sDj73pzkCR5E6fSnVR2m6BrDP I0OxAADpTIyFYJA3Xy7K0wkmb1P6/8inWK2bMUVxzhjQrtdaNYPYLMLusCxVXg9wS/0i 2nUkbr0+cdvBryioIV77SIDI/AEmEeOXkGzzzuVQbgmRz+QdOeGTFOGWawS402fLE6Vq NggQ==
X-Gm-Message-State: APjAAAX5NrUrY4KAnYZGdEJ2yH8mFJ4G0ey8EI28j58ra0ySx61WjOXb f4og/mXE+TCGbBGUe621hNOnPbBvajVcT97W6JU=
X-Google-Smtp-Source: APXvYqwEvD5+MJAYegG3MGw24ctowRY4zMO2n1nWdG9WkpKQOFRdxfmKr1wb7oumTU5JR96kPC8Bss3s2c+rEO6F5W4=
X-Received: by 2002:a17:902:be10:: with SMTP id r16mr17220685pls.169.1575668989856; Fri, 06 Dec 2019 13:49:49 -0800 (PST)
MIME-Version: 1.0
References: <CAAdgstRGHyRKoMLBhRih8yHwDvf-DTp42ZTEBmBP57FSgt8MyA@mail.gmail.com> <MN2PR11MB35652B278DB4225DAAE30956D85C0@MN2PR11MB3565.namprd11.prod.outlook.com> <CAAdgstQG7nkXr7tKffdChftjd8JDG4LvyOqepFsQ8eqZqHt0Aw@mail.gmail.com> <812b5502-9703-b99d-196b-3c983fdc0d5e@inria.fr>
In-Reply-To: <812b5502-9703-b99d-196b-3c983fdc0d5e@inria.fr>
From: Tengfei Chang <tengfei.chang@gmail.com>
Date: Fri, 6 Dec 2019 22:49:37 +0100
Message-ID: <CAAdgstRB86SUFaMXqCzwggh6gy6Jx6uof3W5kDb3imMGZ85r6A@mail.gmail.com>
To: Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr>
Cc: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, 6tisch <6tisch@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006c93ca0599100681"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/wwJ6NsWrqfHfoFHKfNKwGs5AFUo>
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 21:49:52 -0000

On Fri, Dec 6, 2019 at 9:31 PM Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr>
wrote:

> Hi Pascal, Tengfei,
>
> On 12/6/2019 6:48 PM, Tengfei Chang wrote:
> > 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..
>
> I think these two are different things...
>

I agree, I am  only referring Pascal's reply before. What you discussed
with Malisa is another thing.


>
> Handling DSCP value will be a per-packet process. Can we pass DCSP value
> to the TSCH layer using the interface for transmission defined by
> IEEE802.15.4? I don't think so.
>

TC: Not sure this is a standard way to do so. For implementing, tut this
value or a flag could have a default value.
TC: If this value is not given, i.e. frame from IEEE802.15.4 layer, just
use the default value.

>
> I don't see any problem in allocating additional cells for "acceptable"
> amount of traffic including relayed join requests. To prevent
> application packet drops, such allocations could be a good thing.
>

I get your point from your previous  comments.
I think the key point is the during the join phase, the JP can't
distinguish the traffic from:
-pledge or
- an attacker

Another way of thinking of security, if we didn't adapt the unauthorized
traffic, the attacker can still send lots of "fake" join request,
Instead of occupying the bandwidth, it delays or drops the join request
from pledge, which is an security issue as well.

I think the compromise solution is allowing MSF adapt the traffic but
report if there is unusually mount of join traffic detected.


> Rather than giving some L3 information to L2, the L3 may need L2
> information, like available bandwidth (cells) for a certain link. For
> the MSF case, if the IPv6 layer on an intermediate node limits outgoing
> traffic of relayed join requests below 20% of available bandwidth,
> undesired cell allocations could be avoided, assuming
> LIM_NUMCELLSUSED_HIGH is 75% and the link has almost the perfect link PDR.
>
> Best,
> Yatch
>


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

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

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