Re: [6lo] ND cache entries creation on first-hop routers

Jen Linkova <furry13@gmail.com> Wed, 03 July 2019 06:52 UTC

Return-Path: <furry13@gmail.com>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6C311201E0; Tue, 2 Jul 2019 23:52:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level:
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 igrQJ-hym1bW; Tue, 2 Jul 2019 23:52:10 -0700 (PDT)
Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 DA9921201E5; Tue, 2 Jul 2019 23:52:09 -0700 (PDT)
Received: by mail-qt1-x831.google.com with SMTP id a15so1358395qtn.7; Tue, 02 Jul 2019 23:52:09 -0700 (PDT)
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=im/t12M9nQtGO7XKwA/ufAEUDRiVtugobyy8j63/5j4=; b=PY+MDe+ADVLyoZ/xCCCbvmPc9GuuIG+tq/l6SpIvwl7EYEUqTnRKTarABbeVf7VzWL xQ76vmLk4IlmsaGO7/xLQTrrrIX46vefvOnPpzPPGlfy9DvsB2E1d9gWZmJ+nt9+T4vH H73f+ckxPE1yi+wyYIhXssYFU1xl3oBB8bf/Rf0Owtfl0MSyc70R6mNZ2b3UnGAC6xlt PGhphkwmIZkCbTPPiy2lsm0px2ca5qmZws9CT1jFNIhjeYDq9PSS29wyXMwH/dgI66hu En1jX7OU12byBnFUxM1s4+erN7Cn6InpJIlKD7QVZhRXmTYZXgSY56fjmQ+Sij/WaT+F Rbvg==
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=im/t12M9nQtGO7XKwA/ufAEUDRiVtugobyy8j63/5j4=; b=qvP/2cVDDJPYPOJjfDUaLqZhoqds1iIvYZAvtjHG+i2F/OxcQ7JHNs8KKdSYbM5Sia sWJ2iEdpJ0nV/cg5l5mf7Ys+UsUeBLDjF0mWYxQUq17HeMjAP5er5PgqIEVr0JDBnG29 VvosxptIKJsOzj7gxFw4s9bTW96h8oxLazOOXUNP2Jcn5jlp7pU/no40wlVRBqtt+2MP bP5j3uXtEGVDbr2T5ki64yHgIBSrh0vhm8+RqqnlYBldaYjOhbeMpx5NuYRv/ZpzsU7y rMIRII7ZSH5a2ObfnuvoFo3QpWoFXl8Ijc792kOMlNXU73AMxVz2cJiwzZZud4EBJG+B Tggg==
X-Gm-Message-State: APjAAAXcFoXyeITrGvNWZom9FMfImh/7MsjU7aWGT3MD556mz9dI5PAT gZetkjw6k0ev/18iaP8Q9JWrLnAwQDrdTvDyc+M=
X-Google-Smtp-Source: APXvYqylCn8yOtubAKuTfkEbbbc257hGmn0bDdGVYhDhhSXuxp4pwkDNq+U0QR7tDDQSolM4Zf5HjuWvjG9MqUFkRpI=
X-Received: by 2002:a0c:81f0:: with SMTP id 45mr31134286qve.13.1562136728799; Tue, 02 Jul 2019 23:52:08 -0700 (PDT)
MIME-Version: 1.0
References: <CAFU7BAQ4xrjNn9-EUyRhyHKDDT=f381Z4T6x6qJ=ftm2D2K4cw@mail.gmail.com> <5377.1562081856@localhost>
In-Reply-To: <5377.1562081856@localhost>
From: Jen Linkova <furry13@gmail.com>
Date: Wed, 03 Jul 2019 16:51:57 +1000
Message-ID: <CAFU7BAQomCzfDQaAOpJO7CmQYiAVzHFThviLv7r-0=C9v4MD-w@mail.gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: 6lo@ietf.org, 6tisch@ietf.org, V6 Ops List <v6ops@ietf.org>, 6man <6man@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/r79-b8dZpe4ZFWvgu2I6stYLRC0>
Subject: Re: [6lo] ND cache entries creation on first-hop routers
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jul 2019 06:52:13 -0000

On Wed, Jul 3, 2019 at 1:37 AM Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> I think that the discussion here is particularly relevant to constrained
> devices/routers on route-over MESH(RPL,etc.) networks.
>
> I also think that for L=0 networks, which RPL creates with RPL DIO messages
> rather than (just) RAs, and 6LRs that need to support join operations
> (like draft-ietf-6tisch-minimal-security) this may matter.

Disclaimer: I have very limited knowledge in that area.

> In particular, in the minimal-security case, we need to partition the ND
> cache such that untrusted (unverified) malicious pledge nodes can not
> attack the ND cache.

The next version of the draft will have much more details on
discussing the security considerations indeed.

> The behaviour 2.2.1.  Host Sending Unsolicited NA, should probably
> never flush an old entry out of the ND.

I'd say that the router behaviour for creating a STALE entry upon
receiving an unsolicited NA should be the same as for creating an
entry for any other reason (e.g. for receiving an RS with SLLAO).
The same safety rules shall apply.

> I think that under attack
> (whether from untrusted pledges, or from p0woned devices already on the
> network), it is better to prefer communication from existing nodes rather
> than new ones.  2.2.1.2 mentions this.

I guess your routers do purge old stale entries?

> {typo:
>       -It's recommended that thsi functionality is configurable and
>       +It's recommended that this functionality is configurable and
> }

Thanks, will fix in -01.

> I didn't really understand 2.2.2: is it exploiting some corner case in the
> spec, or maybe just some part I am not well clued in about.  So maybe an
> extra paragraph to explain things.

It's just using the standard ND process: when the node B receives an
NS from node A and that NS contains the node B  address as a target
address and SLLAO contains node A LLA,
the node B would respond with NA and would create a STALE entry for
the node A - https://tools.ietf.org/html/rfc4861#section-7.2.3

> I kinda like the ping all routers trick.

I think it's a hack ;( we do have a mechanism for communicating
neighbours addresses/reachability called ND. It would be nice to
utilise its machinery.
Pinging creates additional overhead on routers and could get filtered.
But I'd not be surprised if it's the only way we have realistically to
mitigate the issue..

>
> Jen Linkova <furry13@gmail.com> wrote:
>     > I wrote a short draft to discuss and document an operational issue
>     > related to the ND state machine and packet loss caused by how routers
>     > create ND cache entries for new host addressed:
>
>     > https://datatracker.ietf.org/doc/draft-linkova-v6ops-nd-cache-init/
>
>     > (taking into account some vendors have implemented one of the proposed
>     > solution already, I guess it's a well-known problem but it might still
>     > worth documenting)
>
>     > Comments are appreciated!
>
>     > --
>     > SY, Jen Linkova aka Furry
>
>     > --------------------------------------------------------------------
>     > IETF IPv6 working group mailing list
>     > ipv6@ietf.org
>     > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     > --------------------------------------------------------------------
>
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>


-- 
SY, Jen Linkova aka Furry