Re: [6tisch] nbr cache recommendation

Rahul Jadhav <rahul.ietf@gmail.com> Mon, 13 November 2017 15:49 UTC

Return-Path: <rahul.ietf@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 B68FE129AFC for <6tisch@ietfa.amsl.com>; Mon, 13 Nov 2017 07:49:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 uBYt3-DiWCis for <6tisch@ietfa.amsl.com>; Mon, 13 Nov 2017 07:49:33 -0800 (PST)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 6F9841200FC for <6tisch@ietf.org>; Mon, 13 Nov 2017 07:49:33 -0800 (PST)
Received: by mail-wm0-x22f.google.com with SMTP id l8so10245262wmg.4 for <6tisch@ietf.org>; Mon, 13 Nov 2017 07:49:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NAuSrraIYpDZDKmXObd2JZwJGKNlA4Ta6nuNGv5T4bU=; b=BYhcUr6p/1jDu4gJD+fNnOhMDKiR4hYZANlmeZe8aG8R6zq5ZwVkE6PNUO11yMJ57K oNXEIWvyjN+A6SQvnYNkQsyHAPPBvxkpStt18X5XnZmo+L+CGYANwfI6BOalHFX5NIfb yJnH4SYRJ2QlVaoXnyZZ4XWesrkxbU/BAjeDZgIEj3Z75AG3BoyVQ7JB6a6sOMsDdlFl 2iEkK9q0k5Ag+CHIu+nyrkHH/oepvf3GH+Y7IoAhAEj4mqoX22pjPx16ydroV28TEb01 m2E3cB/LgqC18bTmqAA+RoJDevSswgQlGvZJehQ74wCfOhVvQbv9cmkhBzZb9fBXfahL j8Vw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NAuSrraIYpDZDKmXObd2JZwJGKNlA4Ta6nuNGv5T4bU=; b=a55zlIC/JQSTuZvNfMVS4FwJVjljeEvNJKRqJSq0J97L6mLB3OBLf0g1p07c4iRzw4 PhVx5Y8ShQu22Wr6zvDH7hXT/vLglKlqkPYN2nrXtQ/tpRakI78iZR6TzJDzRf6LpVjj /nnoaBQKSWdsNvaBKF0P5PUDEcZcTtlz5WZkjtq+Qe83o0Sz/pPYmw22Op1mtBN7YI2T fnyBd7U0dqdIQ5NeF3NaddKdlUIAs7A8yfti+ypL1OMnPNe2QcrFTCTQN7/CNprVH6ui sk75w/jvKI3PNgM0YUF4czjph2hU4XXcJQvEQDND7YNFpP5smTRw8s/qswVuLWoNkuYj tF/A==
X-Gm-Message-State: AJaThX7/XWdLryGjDiJzjU327mJEg5wmo9gqeRYEc2L3xTWsdy90bXuF gEw5diIAAwbuOZavwNyebFcFVdGH9nuWEkH4TcY=
X-Google-Smtp-Source: AGs4zMYjDqG7ibH8suz2H6OKMJ3jl0rJcwAc1yYg6ZPWE8gHacli5zU76lsQGZhbrITQ5J35OGejZ/AyHwIOHq7eIKo=
X-Received: by 10.80.205.28 with SMTP id z28mr13529925edi.264.1510588171976; Mon, 13 Nov 2017 07:49:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.80.142.74 with HTTP; Mon, 13 Nov 2017 07:49:31 -0800 (PST)
In-Reply-To: <6AFD13BD-A1B0-4CCC-B27D-75DC90FF6E60@inria.fr>
References: <CAO0Djp0Wa5NdT3JySXNg_GtmA5DncBP-8kuzeDZ4UD_EZgnSCA@mail.gmail.com> <6AFD13BD-A1B0-4CCC-B27D-75DC90FF6E60@inria.fr>
From: Rahul Jadhav <rahul.ietf@gmail.com>
Date: Mon, 13 Nov 2017 23:49:31 +0800
Message-ID: <CAO0Djp3L3hzLPC36bDGcGh3J25drt5se9fn0eWbesmTtw7KBWA@mail.gmail.com>
To: Mališa Vučinić <malisa.vucinic@inria.fr>
Cc: tisch <6tisch@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c1b00926485e5055ddf3717"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/-1ihltCZX5aL9tpwy5s9T3atE2k>
Subject: Re: [6tisch] nbr cache recommendation
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: Mon, 13 Nov 2017 15:49:36 -0000

Thanks Malisa for the instant feedback.
The draft specifies that neighbor entries are reserved and nodes during
pre-auth phase can occupy only certain set of entries. There is a "reason"
field in every entry which would identify such entries and thus it should
take care of this.
Having said that, we ll definitely look into making the text more explicit
and clearer about this context.

Thanks,
Rahul

On 13 November 2017 at 18:45, Mališa Vučinić <malisa.vucinic@inria.fr>
wrote:

> Hi Rahul,
>
> Thanks for the pointer. I skimmed through the draft but couldn’t find how
> relay (JP) or new joinee (pledge) should handle each other before the
> authentication procedure completes. You state:
>
> > Relay element does not hold any state information on behalf of the new
> joinee node except for its neighbor cache entry.
>
> If one doesn’t differentiate between neighbor entries from
> already-authenticated nodes and yet unauthenticated pledges, depending on
> the policy by which new entries are added, there is a potential DoS attack
> on relay (JP) where the attacker could flood it with spoofed entries.
>
> I think that you should explicitly stress what is the recommended way of
> managing this in your draft. One could implement a separate cache for
> untrusted entries or keep a common cache and add complexity in the policy
> by which new entries are added. The latter would require an “untrusted”
> flag in each entry based on which we could count untrusted neighbors and
> decide whether to overwrite an existing neighbor with a new (untrusted) one.
>
> Let me know if I missed something :).
>
> Mališa
>
> > On 13 Nov 2017, at 10:46, Rahul Jadhav <rahul.ietf@gmail.com> wrote:
> >
> > Malisa mentioned recommendations about maintaining untrusted nbr cache
> entries. There is another work-in-prg on lwig which takes into
> considerations these aspects of maintaining nbr entries for network
> access/auth protocol.
> >
> > https://datatracker.ietf.org/doc/draft-ietf-lwig-nbr-mgmt-policy/
> > Pls check if your considerations are handled. Thanks.
> >
> > Regards,
> > Rahul
> > _______________________________________________
> > 6tisch mailing list
> > 6tisch@ietf.org
> > https://www.ietf.org/mailman/listinfo/6tisch
>
>