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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Sun, 22 March 2020 09:14 UTC

Return-Path: <pthubert@cisco.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 096C53A0400; Sun, 22 Mar 2020 02:14:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=cYjNoXSX; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=jq/fO5vW
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 rrKg6NoxoYK7; Sun, 22 Mar 2020 02:14:53 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 456E13A0404; Sun, 22 Mar 2020 02:14:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25150; q=dns/txt; s=iport; t=1584868493; x=1586078093; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kSKET2rImUerp7BQbNrZ/52UNwJSYUp4OUrv8FF6CeE=; b=cYjNoXSX5UtiLhrdpIe18QBKdep7wkwmJHGMH2m1HnaS330Vr4sMOfnS Fe0GOi2T/Z90vAO162CxvXizZSEH1cZQ7WxESwQErj/HsNBmWhdRd7m+g UPkegmbotaJiUn6KI7jXNHPRarqcpFhIPJyQ7Mk6kB31vq8iQ0BNDIu59 0=;
IronPort-PHdr: =?us-ascii?q?9a23=3AHwyZFBRCZjPhPCDsmsyDgEGQv9psv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOjQmHNlIWUV513q6KkNSXs35Yg6arw=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ClBQBLK3de/5NdJa1mDg4BAQEBAQc?= =?us-ascii?q?BAREBBAQBAYF7gVRQBWxYIAQLKoQYg0UDinCCX4lqjjKBQoEQA1QJAQEBDAE?= =?us-ascii?q?BIwoCBAEBhEUCF4INJDgTAgMBAQsBAQUBAQECAQUEbYUqByUMhWMBAQEBAgE?= =?us-ascii?q?SEREMAQEmEQELBAIBCA4DBAEBAwImAgICHxEVCAgCBAEJBAUIGoMFgksDDiA?= =?us-ascii?q?BDqA6AoE5iGJ1gTKCfwEBBYEzAoNrDQuCDAMGgQ4qiWN4NYEfGoFBP4EQAUe?= =?us-ascii?q?BfVA+ghtJAgIagQ8FAQsHAQkaJIJrMoIsjVwgBC+CDTuQFo8ARAqCPI0xhRm?= =?us-ascii?q?EWoJMiCuMDoRUjw2BUIl0kC0CBAIEBQIOAQEFgWkiRCNxcBU7gmxQGA2IDoY?= =?us-ascii?q?PDBcVgzuFFIUEPXSBKYsCAgUhB4IUAQE?=
X-IronPort-AV: E=Sophos;i="5.72,292,1580774400"; d="scan'208";a="741568672"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Mar 2020 09:14:49 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 02M9Eoat024805 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 22 Mar 2020 09:14:50 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 22 Mar 2020 04:14:49 -0500
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 22 Mar 2020 04:14:49 -0500
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Sun, 22 Mar 2020 04:14:49 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; =?utf-8?q?b=3Dhl3m39sh5wzp+DobHGoaAz2HuOyS6+w1KLz/ePIa6era9UP8owpAmo8HEwU02?= =?utf-8?q?qYQS92R1r7+fTcHOpd8S4Ei9Sm/yqkjCDp+0eZwTUZSJ84tL0OJD1udpKatDvcLFJ?= =?utf-8?q?Vig00hacoxn7cqnYTl4I46Mr88KkAWltk9zDa9SdaVp0BrVIKpqsmtImau+vjSkoG?= =?utf-8?q?1jzW1kWJUTcf0tLtB9/eJnsroaCvWureRadjJhbwTtMlMS2ygn1aygZoFo9z9lSQn?= =?utf-8?q?yKvPm3wRdiVwJy8/6TBGZFYIrnC0Gp/PyExCezMma3ebYT4Qho+ZyRhgx4WwT1d5k?= =?utf-8?q?qX8fCxrLrFYh60Q7+J3UA=3D=3D?=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AMessage-ID=3ACont?= =?utf-8?q?ent-Type=3AMIME-Version=3AX-MS-Exchange-SenderADCheck=3B?= =?utf-8?q?bh=3DkSKET2rImUerp7BQbNrZ/52UNwJSYUp4OUrv8FF6CeE=3D=3B_b=3Dib3W29?= =?utf-8?q?ib02F4tAa3tIWIM0bUcd2nwdx+CD6Ah1Rc3kk5hhFbV0orYI4F0tynGAkFlJQ+fiF?= =?utf-8?q?aSxyRE4F57eJ2v8PA6kZFlW2lt33NCfVpimumHWYHz2Abb5KDX+KAO7xEIP+VYKC6?= =?utf-8?q?Rhzr8Kgr6Ol15qjRd7Dj4gNOwIHdT+ouyLFvEzHB/WpsRjlgTeR99//m76/GUy9OJ?= =?utf-8?q?OnrOL8KrPxFsI9VsZlK6DcAoc29WYHxz96+AboAJiiajpZyJ3/Md0BJRVQlulRbQ/?= =?utf-8?q?g0wRauOa5A68YOpgQRmwlwR02x5lEgHUht+6aip2s02qD3130X68khdtgQsHRe3IG?= =?utf-8?q?2yn8R9t+iKQ=3D=3D?=
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AM?= =?utf-8?q?essage-ID=3AContent-Type=3AMIME-Version=3AX-MS-Exchange-SenderADC?= =?utf-8?q?heck=3B_bh=3DkSKET2rImUerp7BQbNrZ/52UNwJSYUp4OUrv8FF6CeE=3D=3B_b?= =?utf-8?q?=3Djq/fO5vWsXnnwXpKnaYJbL3JV6FtU9x88Gz3mjtiaPhu314JGAT9b3XV/TIblg?= =?utf-8?q?9V1pQhtFR3sZZQl+ePtw1Qbc6hA+aRYd0rk4MmCn4v6jKB3HOXUOU6x1IRV63gEPR?= =?utf-8?q?BORbBCXtVGMWbxigiye1z6MSNEJj5d2LIHM840iRKzls=3D?=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31) by MN2PR11MB3776.namprd11.prod.outlook.com (2603:10b6:208:ee::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.22; Sun, 22 Mar 2020 09:14:48 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::113b:3127:ef12:ea7]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::113b:3127:ef12:ea7%7]) with mapi id 15.20.2835.021; Sun, 22 Mar 2020 09:14:48 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Roman Danyliw <rdd@cert.org>, The IESG <iesg@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>
CC: "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>, "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: Roman Danyliw's Discuss on draft-ietf-6lo-backbone-router-16: (with DISCUSS)
Thread-Index: AQHV53zkstvbyNNlvE+QqWau4rvLJag2tzBAgB1ESQCAAHjgwA==
Date: Sun, 22 Mar 2020 09:14:33 +0000
Deferred-Delivery: Sun, 22 Mar 2020 09:13:57 +0000
Message-ID: =?utf-8?q?=3CMN2PR11MB35659CCA837306620F668D30D8F30=40MN2PR11MB3?= =?utf-8?q?565=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?=
References: <158215515848.17730.5131182816417321507.idtracker@ietfa.amsl.com> =?utf-8?q?=3CMN2PR11MB356509E64B148481894581CFD8E40=40MN2PR11MB3565=2Enampr?= =?utf-8?q?d11=2Eprod=2Eoutlook=2Ecom=3E?= <359EC4B99E040048A7131E0F4E113AFC0216FBA15C@marchand>
In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC0216FBA15C@marchand>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [2a01:cb1d:4ec:2200:d078:d127:f556:3d87]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 819efe45-cee2-4b49-c42a-08d7ce41782d
x-ms-traffictypediagnostic: MN2PR11MB3776:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: =?utf-8?q?=3CMN2PR11MB3776F44DCA35D4B061647FADD8F?= =?utf-8?q?30=40MN2PR11MB3776=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?=
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 0350D7A55D
x-forefront-antispam-report: SFV:NSPM; =?utf-8?q?SFS=3A=2810009020=29=284636?= =?utf-8?b?MDA5KSgzOTg2MDQwMDAwMikoMzQ2MDAyKSgzNzYwMDIpKDM2NjAwNCkoMzk2?= =?utf-8?b?MDAzKSgxMzYwMDMpKDE5OTAwNCkoMzM2NTYwMDIpKDg5MzYwMDIpKDE4NjAwMyko?= =?utf-8?q?71200400001=29=2881156014=29=2854906003=29=286666004=29=288116600?= =?utf-8?b?NikoMTEwMTM2MDA1KSg4Njc2MDAyKSg0MzI2MDA4KSg2NjU3NDAxMikoNTUw?= =?utf-8?b?MTYwMDIpKDc2OTYwMDUpKDUzNTQ2MDExKSg5NjYwMDUpKDg2MzYyMDAxKSg3?= =?utf-8?q?6116006=29=2866946007=29=2866556008=29=2866446008=29=2830864003?= =?utf-8?b?KSg2NjQ3NjAwNykoNjQ3NTYwMDgpKDMxNjAwMikoMjkwNjAwMikoNTY2MDMw?= =?utf-8?b?MDAwMikoNTI1MzYwMTQpKDQ3ODYwMDAwMSkoOTY4NjAwMykoNjUwNjAwNyk7?= DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3776; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: =?utf-8?q?zn6Zxtlk6MmhcsyeJFZt3dE1RjMfWhp?= =?utf-8?q?IjGj0GXsa47yOb/9EcN95K8KGw/lthv2PFvZyzkT9lZKy/rDlVwwQ1FhGP6oX+NFF?= =?utf-8?q?vD15v3Oed8FmoHSvZdf1mKB4iphR2cqA14b+oMCHdDRYsrkUGn0AGLlQrUcJ5NSUW?= =?utf-8?q?LQfqrf7R9UYo9WnNDUFvNDNLzGXIDmmixwKzuqsZdWpNgt/veqjxBOuF/w0JKIYP7?= =?utf-8?q?Z2n3tagIEIMA2WRWd/Fac6bHXsv92InxPGOHDo/sHvtQJbRYzj4SUo3iLqsd9hY73?= =?utf-8?q?Fe7bjaf3H4n+KIOOzR9eqd4y5e0mPr/EDvX1V1JmcJ2CIteZSycb/RIjj28JuDNB7?= =?utf-8?q?mA5mGqP3dt9yxOu+ZB6Sv6OxLZVIAuqHvbhcH0X3qNZVDNKTHT35o4akwCXcx7nbk?= =?utf-8?q?YZim5lC5ve+MVnJ/JMgTNV5/YzXOVjFzsLfHuwnPUwjslgdiekKafNhegsfVHxeMf?= =?utf-8?q?I+YkDSinkvK7L/mhf9PkczVFSiyyLsfVYuMn54swIpdpz7rQ=3D=3D?=
x-ms-exchange-antispam-messagedata: =?utf-8?q?Vkk0pWHV3144vyw1PfDNioKXLVlUm4?= =?utf-8?q?RxZl4N12pLlKEeLIktcQ6g8BfAUPWLeCJp/NUtVN7426lOx3KMBtTvhcUvRwCh4sS?= =?utf-8?q?FZ8K24v7T6h1FNl3ooJfuD+mB0SL8/LashO/J40ZLbYxKfPaxIT11ymfPEgDPOyqd?= =?utf-8?q?5WT5FsHmNaIZodwYgWCFDd+l5unm/RWAS7pTILTplQDxUXnk4r+kyA=3D=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 819efe45-cee2-4b49-c42a-08d7ce41782d
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2020 09:14:47.7117 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: =?utf-8?q?h8KcET+EM7e/wa8eOflJI?= =?utf-8?q?e3ps83U1FC7fl1XIrHn0QPawzHKEZjtJy7z+HZ5p8m8U4inrqFVASgjw4HGLK/WFQ?= =?utf-8?q?=3D=3D?=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3776
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com
X-Outbound-Node: rcdn-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/0V0v0mj69g-sWavd-fP_xZwyo-A>
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: Sun, 22 Mar 2020 09:14:56 -0000

Many thanks Roman!

> -----Original Message-----
> From: Roman Danyliw <rdd@cert.org>
> Sent: dimanche 22 mars 2020 02:00
> To: Pascal Thubert (pthubert) <pthubert@cisco.com>om>; The IESG
> <iesg@ietf.org>rg>; Benjamin Kaduk <kaduk@mit.edu>
> Cc: draft-ietf-6lo-backbone-router@ietf.org; Carles Gomez
> <carlesgo@entel.upc.edu>du>; Samita Chakrabarti <samitac.ietf@gmail.com>om>;
> Shwetha Bhandari (shwethab) <shwethab@cisco.com>om>; 6lo-chairs@ietf.org;
> 6lo@ietf.org
> Subject: RE: Roman Danyliw's Discuss on draft-ietf-6lo-backbone-router-16:
> (with DISCUSS)
> 
> Hi Pascal!
> 
> The new language in -19 looks good to me and addresses my feedback.  Thanks
> for making these updates.
> 
> Roman
> 
> -----Original Message-----
> From: Pascal Thubert (pthubert) <pthubert@cisco.com>
> Sent: Tuesday, March 3, 2020 11:03 AM
> To: Roman Danyliw <rdd@cert.org>rg>; The IESG <iesg@ietf.org>rg>; Benjamin Kaduk
> <kaduk@mit.edu>
> Cc: draft-ietf-6lo-backbone-router@ietf.org; Carles Gomez
> <carlesgo@entel.upc.edu>du>; Samita Chakrabarti <samitac.ietf@gmail.com>om>;
> Shwetha Bhandari (shwethab) <shwethab@cisco.com>om>; 6lo-chairs@ietf.org;
> 6lo@ietf.org
> Subject: RE: Roman Danyliw's Discuss on draft-ietf-6lo-backbone-router-16:
> (with DISCUSS)
> 
> Dear Roman and Benjamin
> 
> Many thanks for your reviews!
> 
> I took the liberty to merge your comments on section 11 in a single thread,
> since they have commonalities.
> Also, I'll try to answer the questions with my own words as they come, and
> then propose a global change to section 11 at the end of the email.
> The overall changes are posted as -1ç but you may use the copied text below to
> propose amendments / additions, I hope that all works for you.
> 
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-backbone-router-19
> 
> 
> Please see below:
> 
> >
> > ----------------------------------------------------------------------
> > DISCUSS (Roman):
> > ----------------------------------------------------------------------
> >
> > Section 11.  Can assumptions of the about the security properties of
> > the links be clarified.
> >
> > This specification applies to LLNs and a backbone in which the
> >    individual links are protected against rogue access, e.g., by
> >    authenticating a node that attaches to the network and encrypting at
> >    the MAC layer the transmissions that may be overheard.  In
> >    particular, the LLN MAC is required to provide secure unicast to/from
> >    the Backbone Router and secure Broadcast from the Backbone Router in
> >    a way that prevents tampering with or replaying the RA messages.
> >
> > -- what are the specific assumptions about the protections that will
> > be on the link.  Is the list of properties in the “e.g.” the full list?
> 
> For all I know it is the full list, let me remove the "e.g.,".
> 
> Compiling this question with Benjamin's below I'd say that this work inherits
> from ND, which allows any node that can access the link to do anything,
> appear as a router,  source traffic and attract traffic. ND can also be used to
> DoS a network from a remote node by sending high volumes of packets, each
> to a different forged address, and each causing a temp state in the router and a
> broadcast on the fabric.
> 
> We interwork with that on the backbone, and the draft gives precedence to the
> legacy operation, meaning that a node that can attack ND can attack us in the
> exact same way.
> 
> I can add words to say that. RFC 4861 section 11.1 tells us to "keep the bad
> guys out or all bets are off", IOW, Woodstock. Section 11.2 has the hopeful
> thinking that SeND will be deployed, and we know it will not happen. For info,
> this only implementation that shipped that I'm aware of is the router side by
> our co-author Eric in Cisco's IOS. We are well placed to know it's doomed and
> very motivated to give another chance to securing ND. Which lead us to AP-
> ND.
> And since ND does nothing for that, it means "do not let the bad guys access
> the network at L2" and "do not let the bad guys compromise any system on the
> network". I will not even try the Woodstock analogy there.
> 
> What changes:
> - nodes that are attached to the LLN cannot attack that easily (if AP-ND is
> enforced)
> - we have nodes that are more sensitive than others (the 6BBR and 6LBR are
> new targets that can impact many nodes, note that the default router already
> was one, and anybody could impersonate it).
> - when a policy enforces AP-ND to all nodes including the backbone then :
>     * the increased security that we have on the LLN will also apply to the
> backbone (no impersonation or stealing address)
>     * the complete list of addresses n the network will be known to the default
> router which will block the remote DoS attacks
>     * DAD and Lookups will be fast and without multicast, which again will be a
> protection against some ND-based DoS attacks.
>     * DAD will work on Wi-Fi (arguably it does not today in a large conference
> like IETF)
>     * L2 tables will be small and stable
> 
> 
> > -- As the second sentence references the only the LLN MAC, using
> > Figure 1 and 2 as a reference (realizing they are non-normative),
> > what’s expected properties of the links between the router-and-6BBR or
> > IPv6 node-and-6BBR (i.e., the links connecting to the “backbone side”)?
> 
> This is typically (IOW always) a legacy ethernet link and the expectation has to
> be compatible with existing deployments and capabilities (Woodstock).
> The registration is an attempt to migrate to a more zero-trusty behavior.
> 
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT: (Benjamin)
> > ----------------------------------------------------------------------
> >
> >
> > We force a sequencing that has EDAR/EDAC occur before normal NS(DAD);
> > does this provide a new DoS avenue by virtue of delaying the normal
> > NS(DAD) procedure by (e.g.) dropping the EDAC messages?
> 
> I do not see a large opening since the unicast query is rapid. The node could
> have a short time out in the order of a few ms before it starts DADing. Which is
> negligible compared to the 1s (time x retries) DAD time out that plagues IPv6
> over Wi-Fi in IEEE 802.11ai (Fast Link Setup, aka FILS) scenarios.
> I see a DoS attack against the 6LBR, but that's common to any server like DNS
> or LISP MSMR, and the traditional methods apply.
> 
> 
> > It might be worth a brief preface that since we're modifying the ND
> > and DAD processes, the attacks in scope are basically limited to
> > blocking discovery of taking over addresses from other nodes (which,
> > to be fair, can in some cases have substantial consequences in terms of
> reading the "stolen" traffic!).
> 
> I had trouble parsing but after a night's sleep it appears that an s/of/or/ helps a
> lot. Point taken, this relates to the classical ND attacks on the backbone that
> cannot be defeated unless the registration is the only form of ND on the
> backbone. It seems relevant to point out the Woodstock approach in classical
> ND in the intro and indicate that we're subject to it by contagion on the
> backbone.
> 
> "
> 
>    This specification considers a special type of MLSN with a central
>    backbone that federates edge (LLN) links, each Link providing its own
>    protection against rogue access and tempering or replaying packets.
>    In particular, the use of classical IPv6 ND on the backbone requires
>    that the all nodes are trusted and that rogue access to the backbone
>    is prevented at all times (see Section 11).
> 
> "
> 
> 
> >    This specification applies to LLNs and a backbone in which the
> >    individual links are protected against rogue access, e.g., by
> >    authenticating a node that attaches to the network and encrypting at
> >    the MAC layer the transmissions that may be overheard.  In
> >    particular, the LLN MAC is required to provide secure unicast to/from
> >    the Backbone Router and secure Broadcast from the Backbone Router in
> >    a way that prevents tampering with or replaying the RA messages.
> >
> > It seems like it would be worth stating these
> > requirements/applicability statement much earlier in the document
> > (possibly in addition to here), e.g., in the Introduction.
> 
> Incorporated in the above
> 
> 
> >
> >    provide the proof-of-ownership.  A possible attack over the backbone
> >    can be done by sending an NS with an EARO and expecting the NA(EARO)
> >    back to contain the TID and ROVR fields of the existing state.  With
> >    that information, the attacker can easily increase the TID and take
> >    over the Binding.
> >
> > The 6BBR can also perform such an attack, right?  It might be worth
> > explicitly stating that we trust it to behave honestly in order for
> > this stuff to work properly.
> 
> We trust any node on the backbone to behave honestly, that's the Woodstock.
> In the 'what changes' text I need to mention the 6BBR and the 6LBR, as points
> of concentration which would naturally attract an attacker, because they are
> bottlenecks that see all of a particular type of traffic. But as look as classical
> ND is operated in the network, compromising any node is probably enough to
> perform any ND attack.
> 
> >
> > We could also discuss how things break if the "distributed database"
> > of registrations gets out of sync across 6BBRs/etc..
> 
> Yes, I'll have a paragraph on that, bottom line is that a stale state will lose in a
> fight and disappear ultimately when there is none.
> Still, a legacy node that does not understand EARO in NA may pick the old
> 6BBR even if the new one also responds.
> 
> >
> > How do things degrade if a secondary 6BBR "stands back" to let a
> > primary handle a given message but the primary 6BBR has gone offline
> > unbeknownst to the secondary?
> 
> Yes, text needed too. Not just in the security section. If the registering node
> loses a 6BBR,  it should reregister to another (that's an obvious), and if it is
> registered to multiple 6BBRs, it should refresh the other registrations with a
> new TID (text needed). We have no design for a registered node using multiple
> registering node, and that's worth mentioning too.
> 
> 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
>    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
>    indicate an identical Binding in another 6BBR (same Registered
>    address, same TID, same ROVR) are silently ignored but for the
>    purpose of selecting the primary 6BBR for that registration.
> 
> <...>
> 
>    If a Registering Node loses connectivity to its or one of the 6BBRs
>    to which it registered an address, it retries the registration to the
>    (one or more) available 6BBR(s).  When doing that, the Registering
>    Node MUST increment the TID in order to force the migration of the
>    state to the new 6BBR, and the reselection of the primary 6BBR if it
>    is the node that was lost.
> "
> 
> >
> > Are there any noteworthy scaling requirements to the bridging and
> > routing proxy modes?  (I don't think so, and we just allude to
> > "dimensioned for the number of registrations that each needs to support"
> > in Appendix B, but it doesn't hurt to ask.)
> 
> Not really that I can figure, beyond the obvious that you mention.
> 
> Putting it all together there we go for the proposed section 11 update:
> 
> 
> "
> 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
>    secure unicast to/from the Backbone Router and secure broadcast from
>    the routers in a way that prevents tampering with or replaying the ND
>    messages.
> 
>    For the IPv6 ND operation over the backbone, and unless the classical
>    ND is disabled (e.g., by configuration), the classical ND messages
>    are interpreted as emitted by the address owner and have precedence
>    over the 6BBR that is only a proxy.  It results that the security
>    threats that are detailed in section 11.1 of [RFC4861] fully apply to
>    this specification as well.  In very short:
> 
>    *  Any node that can send a packet on the backbone can take over any
>       address including addresses of LLN nodes by claiming it with an NA
>       message and the Override bit set.  This means that the real owner
>       will stop receiving its packets.
> 
>    *  Any node that can send a packet on the backbone can forge traffic
>       and pretend it is issued from a address that it does not own, even
>       if it did not claim the address using ND.
> 
>    *  Any node that can send a packet on the backbone can present itself
>       as a preferred router to intercept all traffic outgoing the
>       subnet.  It may even expose a prefix on the subnet as not-on-link
>       and intercept all the traffic within the subnet.
> 
>    *  If the rogue can receive a packet from the backbone it can also
>       snoop all the intercepted traffic, be it by stealing an address or
>       the role of a router.
> 
>    This means that any rogue access to the backbone must be prevented at
>    all times, and that nodes that are attached to the backbone must be
>    fully trusted / never compromised.
> 
>    Using address registration as the sole ND mechanism on a link and
>    coupling it with [I-D.ietf-6lo-ap-nd] guarantees the ownership of a
>    registered address within that link.  The protection is based on a
>    proof-of-ownership encoded in the ROVR field and protects against
>    address theft and impersonation by a 6LN, because the 6LR can
>    challenge the Registered Node for a proof-of-ownership.
> 
>    The protection extends to the full LLN in the case of an LLN Link,
>    but does not extend over the backbone since the 6BBR cannot provide
>    the proof-of-ownership when it defends the address.
> 
>    A possible attack over the backbone can be done by sending an NS with
>    an EARO and expecting the NA(EARO) back to contain the TID and ROVR
>    fields of the existing state.  With that information, the attacker
>    can easily increase the TID and take over the Binding.
> 
>    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
>       increased security that [I-D.ietf-6lo-ap-nd] provides on the LLN
>       will also apply to the backbone; it becomes impossible for an
>       attached node to claim an address that belongs to another node
>       using ND, and the network can filter packets that are not
>       originated by the owner of the source address (SAVI), as long as
>       that the routers are known and trusted.
> 
>    Remote ND DoS attack avoidance:  the complete list of addresses in
>       the network will be known to the 6LBR and available to the default
>       router; with that information the router does not need to send a
>       multicast NA(Lookup) in case of a Neighbor Cache miss for an
>       incoming packet, which is a source of remote DoS attack against
>       the network
> 
>    Less IPv6 ND-related multicast on the backbone:  DAD and NS(Lookup)
>       become unicast queries to the 6LBR
> 
>    Better DAD operation on wireless:  DAD has been found to fail to
>       detect duplications on large Wi-Fi infrastructures due to the
>       unreliable broadcast operation on wireless; using a 6LBR enables a
>       unicast lookup
> 
>    Less Layer-2 churn on the backbone:  Using the Routing Proxy
>       approach, the Link-Layer address of the LLN devices and their
>       mobility are not visible in the backbone; only the Link-Layer
>       addresses of the 6BBR and backbone nodes are visible at Layer 2 on
>       the backbone.  This is mandatory for LLNs that cannot be bridged
>       on the backbone, and useful in any case to scale down, stabilize
>       the forwarding tables at Layer 2 and avoid the gratuitous frames
>       that are typically broadcasted to fix the transparent bridging
>       tables when a wireless node roams from an AP to the next.
> 
>    This specification introduce a 6BBR that is a router on the path of
>    the LLN traffic and a 6LBR that is used for the lookup.  They could
>    be interesting targets for an attacker, but not more than a default
>    router and a DHCP server, respectively, which already exist in
>    classical networks, and can be defended using the same methods.
> 
>    A possible attack over the LLN can still be done by compromising a
>    6LR.  A compromised 6LR may modify the ROVR of EDAR messages in
>    flight and transfer the ownership of the Registered Address to itself
>    or a tier.  It may also claim that a ROVR was validated when it
>    really wasn't, and reattribute an address to self or to an attached
>    6LN.  This means that 6LRs, as well as 6LBRs and 6BBRS must still be
>    fully trusted / never compromised.
> 
>    This specification mandates to check on the 6LBR on the backbone
>    before doing the classical DAD, in case the address already exists.
>    This may delay the DAD operation and should be protected by a short
>    timer, in the order of 100ms or less, which will only represent a
>    small extra delay versus the 1s wait of the DAD operation.
> 
> "
> 
>