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

Jen Linkova <furry13@gmail.com> Fri, 05 July 2019 03:32 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 9370E1200E9; Thu, 4 Jul 2019 20:32:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 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] 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 myMUU1q4bcOq; Thu, 4 Jul 2019 20:32:42 -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 6F7FC1200D7; Thu, 4 Jul 2019 20:32:42 -0700 (PDT)
Received: by mail-qt1-x831.google.com with SMTP id z4so6401075qtc.3; Thu, 04 Jul 2019 20:32:42 -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=82gjOTfisl07ESip9DABpzteyxL/Mgl1WCU67frieGc=; b=RDvTNPN+r96lUbuxUUic0zTXL7vvCi4zpaAUfdWjLD+nECWvNwZQvRojwERiT4qYhQ /pUlQ0k2FUYgQDpKT3t3/FS2MY/qpRK5KV9GBoNU5PvsU9xdsNAQ4N5Om/DxYcIzGwNl EuUfRA1ShAvbaVC9MjCaalApuVoVTdwEX5wZf+E/WaXiXFCDc8lEe+7pBDLoKEPQDysr MgIsyt842iGWdkKfTm70GZ3UaTVsiBXL5mx5rDU3pXD09US46+wi3rmC1RDFt23rxOR9 TzjEsk1sA7eUvpgtSL5vKj2ZZzAbkcWLh1eBXrtnd/NCnk1aoRJh6eqUUMMAfkFkhwmj X6WQ==
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=82gjOTfisl07ESip9DABpzteyxL/Mgl1WCU67frieGc=; b=V8dKrtov1zWb5DtfNvRp8aOAdyDVGmlxVPEOw84Brum/MdSO7xB9hcn0qFrEU7b0Bk Iq+L6Ab+vMyUGJypkb1mJRurufGrhaWKiMOEMBiXcYL/79by+eaTWSi1CT4WLPwi4WzN q/hdRl1PpxY+ULeFkFhsGsZ/I0rv/fe9xY7fj0QHCs1h/aqZCiqYY+8PNwyWscstvhP2 7dOIa6xzCGZyqR6XGm1apZIfpGd3fiaTJaGaFefSR6AgLGq/WCsSfEJ2y1YLZayOt3HR q+qzNa5dfwbiENJiV3sr11Sntd2NV8m/PKmCmX9CJbcBetbRazPq0P+9J0wehNZ/rDQB mHog==
X-Gm-Message-State: APjAAAVNwaOuaicmuyhx0MYMRRZb4qgeJPs+0T8etiwRCfqWdCJ8Xzb9 naVBASb4COlcHXamPatHolIbFz0JyjDfshjuj4I=
X-Google-Smtp-Source: APXvYqyhm8a5rlAFrI/0lTUdsRzvSnKETrx08/bKUvehkd62prENv0nRUR8SUxV3m/WuGb7uGud5luKQkWG9zzcYOZ8=
X-Received: by 2002:ac8:2e59:: with SMTP id s25mr876628qta.94.1562297561169; Thu, 04 Jul 2019 20:32:41 -0700 (PDT)
MIME-Version: 1.0
References: <CAFU7BAQ4xrjNn9-EUyRhyHKDDT=f381Z4T6x6qJ=ftm2D2K4cw@mail.gmail.com> <5377.1562081856@localhost> <CAFU7BAQomCzfDQaAOpJO7CmQYiAVzHFThviLv7r-0=C9v4MD-w@mail.gmail.com> <MN2PR11MB356554390F9F0CD970CEAA6CD8FB0@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB356554390F9F0CD970CEAA6CD8FB0@MN2PR11MB3565.namprd11.prod.outlook.com>
From: Jen Linkova <furry13@gmail.com>
Date: Fri, 5 Jul 2019 13:32:29 +1000
Message-ID: <CAFU7BAS0be_L45rm_zbJiqrMQ=AoBjSgjcHMMvGfo-LoKsbVow@mail.gmail.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, "6tisch@ietf.org" <6tisch@ietf.org>, 6man <6man@ietf.org>, V6 Ops List <v6ops@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/OFjHXFtS_A3YliXMSDeDxeVj7Cw>
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: Fri, 05 Jul 2019 03:32:45 -0000

Hi Pascal,

On Wed, Jul 3, 2019 at 6:18 PM Pascal Thubert (pthubert)
<pthubert@cisco.com>; wrote:
> The routers that Michael is talking about are real routers, deployed in large volumes in the field, e.g., in Smartgrid networks.
> They are not running ND as RFC 4861/4862 but as RFC 6775/8505, and then operate RPL routing within the ML subnet.
> It would be great to have a section that describes that new ND operation and shows how it changes the deal. I'd be happy to help you on that if you need.
> There are some hints in https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/.

Oh, that's an interesting plot twist ;) Migrating from 4861/4862 to 6775/8505?
Sounds like smth we might want to explore as a strategy (while the
tactical fixes my draft mostly talks about might be still needed too).
I'll re-read RFCs  6775/8505 and will be back to you with some
questions later..Thanks for the suggestion!

> > -----Original Message-----
> > From: 6lo <6lo-bounces@ietf.org>; On Behalf Of Jen Linkova
> > Sent: mercredi 3 juillet 2019 08:52
> > To: Michael Richardson <mcr+ietf@sandelman.ca>;
> > Cc: 6tisch@ietf.org; 6man <6man@ietf.org>;; V6 Ops List <v6ops@ietf.org>;;
> > 6lo@ietf.org
> > Subject: Re: [6lo] ND cache entries creation on first-hop routers
> >
> > 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
> >
> > _______________________________________________
> > 6lo mailing list
> > 6lo@ietf.org
> > https://www.ietf.org/mailman/listinfo/6lo



-- 
SY, Jen Linkova aka Furry