Re: [6lo] Roman Danyliw's Discuss on draft-ietf-6lo-backbone-router-16: (with DISCUSS)

Benjamin Kaduk <kaduk@mit.edu> Tue, 24 March 2020 03:27 UTC

Return-Path: <kaduk@mit.edu>
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 C6BD73A0FD6; Mon, 23 Mar 2020 20:27:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 eLL6JvxpPHQJ; Mon, 23 Mar 2020 20:27:15 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77ABE3A0FD4; Mon, 23 Mar 2020 20:27:14 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 02O3R1hm008007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Mar 2020 23:27:03 -0400
Date: Mon, 23 Mar 2020 20:27:00 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-6lo-backbone-router@ietf.org" <draft-ietf-6lo-backbone-router@ietf.org>, Carles Gomez <carlesgo@entel.upc.edu>, Samita Chakrabarti <samitac.ietf@gmail.com>, "Shwetha Bhandari (shwethab)" <shwethab@cisco.com>, "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>, Roman Danyliw <rdd@cert.org>, "6lo@ietf.org" <6lo@ietf.org>
Message-ID: <20200324032700.GS50174@kduck.mit.edu>
References: <158215515848.17730.5131182816417321507.idtracker@ietfa.amsl.com> <MN2PR11MB356509E64B148481894581CFD8E40@MN2PR11MB3565.namprd11.prod.outlook.com> <359EC4B99E040048A7131E0F4E113AFC0216FBA15C@marchand> <20200322185707.GA50174@kduck.mit.edu> <MN2PR11MB35656584660590C7583A407FD8F00@MN2PR11MB3565.namprd11.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <MN2PR11MB35656584660590C7583A407FD8F00@MN2PR11MB3565.namprd11.prod.outlook.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/nbrYPcPIdDhpMIti02n5-P-JHGM>
Subject: Re: [6lo] Roman Danyliw's Discuss on draft-ietf-6lo-backbone-router-16: (with DISCUSS)
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: Tue, 24 Mar 2020 03:27:17 -0000

On Mon, Mar 23, 2020 at 10:17:43AM +0000, Pascal Thubert (pthubert) wrote:
> Hello again Benjamin:
> 
> Just to make sure you're kept busy ; )
> 
> > > Proposed changes in 3.5.  Primary and Secondary 6BBRs
> > >
> > > "
> > >    A Registering Node MAY register the same address to more than one
> > >    6BBR, in which case the Registering Node uses the same EARO in all
> > >    the parallel registrations.  On the other hand, there is no provision
> > >    in 6LoWPAN ND for a 6LN (acting as Registered Node) to select its
> > 
> > I'm assuming that "6LoWPAN ND" here means "stuff currently published as
> > RFCs, excluding this document, AP-ND, etc."
> 
> That is correct in -20 but AP-ND does not either. 
> 
> In the terminology section (2.4) we say
> 
> 
>    6LoWPAN ND:  Neighbor Discovery Optimization for Low-Power and Lossy
>       Networks [RFC6775] and "Registration Extensions for 6LoWPAN
>       Neighbor Discovery" [RFC8505].
> 
> But then, I believe that it should include AP-ND.
> Note that both this are in C310, held by the same docs
> 
> "
>    6LoWPAN ND:  Neighbor Discovery Optimization for Low-Power and Lossy
>       Networks [RFC6775], "Registration Extensions for 6LoWPAN Neighbor
>       Discovery" [RFC8505], and " Address Protected Neighbor Discovery
>       for Low-power and Lossy Networks" [I-D.ietf-6lo-ap-nd].
> "
> Note that AP-ND is mentioned several times later;  Is that OK? (more below)

I don't mind.  (But I'm not sure that I'm the best placed to comment...)

> 
> > 
> > >    6LBR (acting as Registering Node), so it cannot select more than one
> > >    either.  To allow for this, ND(DAD) and NA messages with an EARO
> > > that
> > 
> > (in particular with respect to "cannot select more than one".)
> 
> I guess you're confused between 6LR and 6LBR. The 6LN can attached to multiple 6LRs but it is the 6LRs that select the 6LBR, not the 6LN.

Ah, I think you are right about my confusion.

> Are we in sync?

It looks like it.

> 
> > > 11.  Security Considerations
> > >
> > >    This specification applies to LLNs and a backbone in which the
> > >    individual links are protected against rogue access, by
> > >    authenticating a node that attaches to the network and encrypting at
> > >    the MAC layer the transmissions so packets may neither be overheard
> > >    or nor forged.  In particular, the LLN MAC is required to provide
> > 
> > I think that the "authenticating a node that attaches [...]" is meant to apply to
> > the LLN links, and perhaps the backbone provides the protection against rogue
> > access by physical access protection?  Maybe we need two clauses after the
> > comma, e.g., "on the LLN by [...], and on the backbone by [...]".
> 
> Yes, as discussed in the next block, the attacks on the backbone are a lot easier if backwards compatibility has to be maintained. There's the discussion on who should win when a legacy fights with an LLN node, the current text has the legacy win to enable a smooth incremental deployment.
> 
> Proposed change:
> "
>   This specification applies to LLNs and a backbone in which the
>    individual links are protected against rogue access, on the LLN by
>    authenticating a node that attaches to the network and encrypting at
>    the MAC layer the transmissions, and on the backbone side using the
>    physical security and access control measures that are typically
>    applied there, so packets may neither be overheard or nor forged.
> 
> "

+1

> 
> > 
> > >    If the classical ND is disabled on the backbone and the use of
> > >    [I-D.ietf-6lo-ap-nd] and a 6LBR are mandated, the network will
> > >    benefit from the following new advantages:
> > >
> > >    Zero-trust security for ND flows within the whole subnet:  the
> > 
> > (I'm tempted to try to work "non-router" in here somehow, but not sure it's
> > worth the effort.)
> 
> Sorry I'm not sure I see the point. The duplication may be with a router.

I can see why you were confused at this remark; it's ... pretty opaque!

I was reacting to "zero-trust security" -- we still have to trust the
routers to do the right thing, so my knee-jerk reaction is to not apply
"zero-trust" to them.

-Ben