Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-6lo-ap-nd-15: (with DISCUSS and COMMENT)

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Thu, 06 February 2020 09:50 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 9AC9F120844; Thu, 6 Feb 2020 01:50:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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=WHdDPLT3; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=mrjD2Iuo
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 7v0Mhrh8HBkv; Thu, 6 Feb 2020 01:50:34 -0800 (PST)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE36D120271; Thu, 6 Feb 2020 01:50:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4521; q=dns/txt; s=iport; t=1580982633; x=1582192233; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QJImZAXn0o4WMql6Um0pUVk6Huh2KQukthjGFDufG2w=; b=WHdDPLT3fWkLbo3ttI8nDQjOtoA1CPQx8Hw4K0GwrlgLIVu1ZhWRfWCP zt64KiDHqlP+I4RUe4SRXe6pxfHWRPVpw7UlA1cHgMtF7eYI5kP8bRO9z TPd8I/bEdW4JWxL+TsMVNjYwJPx9IgZTDhbJNuP+G0z5/iagmfAVCt9eq o=;
X-IPAS-Result: =?us-ascii?q?A0AMCAAu4Dte/4YNJK1mDg8BAQEJAREFBQGBe4FUUAVsW?= =?us-ascii?q?CAECyqHWwOKfoJfmBKBQoEQA1QJAQEBDAEBIwoCAQGEQAKCPCQ4EwIDAQEBA?= =?us-ascii?q?wIDAQEBAQQBAQECAQUEbYU3DIVmAQEBAQIBEi4BATcBCwQCAQgRBAEBAS4yH?= =?us-ascii?q?QgCBA4FCBqDBYJKAw4gAQIMn38CgTmIYoIngn8BAQWFLxiCDAMGgTiFHoVBg?= =?us-ascii?q?UMagUE/gRFHgkw+gmQCAgEZgS8cg0CCLJAghyGIeI82CoI6h0qPF4JIiBCOT?= =?us-ascii?q?YFml06SNwIEAgQFAg4BAQWBaSJEgRRwFYMnUBgNjh0MFxWDO4UUhQQ7dAKBJ?= =?us-ascii?q?4pKJ4IaAQE?=
IronPort-PHdr: =?us-ascii?q?9a23=3ABk12Wxb1wXf7uAhuTb3qfyH/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavycywnFslYSHdu/mqwNg5eH8OtLwSI8Ge/5jMTBB?= =?us-ascii?q?jzcBFtKLSpSKjVicn/l/io/IHeaBlJgzz7Zq5uKBKxrkPascxEyYBjMa02jB?= =?us-ascii?q?DOpzNEfOlNjWVvORqfkg396cG54JMGkWxItugk9tJcXKmyZKk+QbFCRDQhKH?= =?us-ascii?q?wupcA=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.70,408,1574121600"; d="scan'208";a="408045990"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Feb 2020 09:50:31 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 0169oVSE012770 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 6 Feb 2020 09:50:31 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 6 Feb 2020 03:50:30 -0600
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 6 Feb 2020 03:50:30 -0600
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 6 Feb 2020 04:50:30 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nJ6YWdlvGa8RxAO+3I7j2fJQ/XMv/cCjeL8rJ9Mlo2bqPaWmgdzZiDV5Ie1ED4MzKtm2Qd60Q8mwF4kwLzUlJjN6g9pfmZe2kLPmzis9d7bHKvYy4erEhwXwElqtYE8sDr+PkzMhvgfvNFszFI6M5x8HGM3OkXY3qn5VAWwI5zq8io+3Ua66UwcQz/2eVfoAmMiza50HoPiG9jtSCsBGDyBGh8wFdEHtoia1tA4jFthde/UZwVVX+MWum9CLansCmLZG+FmM5iEHJG58yl0Ejs7hV6Cn26OdPlp/zipyRTpI71gzIRLSAps0+TOETiAncbehNXX8tS0c6RP/Xhs39A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=S4Y2RPkuPxF8VTANr3Q9fke7/5IEd99orGpiaWCzqks=; b=g5CRCqdWl2ryInmExZClAm7IiNYPwBLgUSI73w0VaOJCZ28gxvEK5Sjap8bc44tGyxEP40eDnzBXaZr3YGpnu42uudS7JQWzFvTP7eKij2nznYpRiypu0qNzR24k+HGPCjl5SN7RTHz1Btr1FZDiNry8V7htuGGulF74geNj/Cff35bUh3Dfm4nNvyidoxZbW9cWPyDjIhuNpYD/r7CKMnTpOuxnTT2iGiaV7xReXr0O+hl8s4hJvbFpJhgrkRl8VRlyJAZfXJ5K1Mza7FczLwDnhx+rbuRrdhlQUQnwqW5PWPk7OwE75C4pHeLiAiIvJUTYNimYQqV+AUNTtUNRVg==
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; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=S4Y2RPkuPxF8VTANr3Q9fke7/5IEd99orGpiaWCzqks=; b=mrjD2IuoJhAiCgsicuAd5Ah9YIAIYf8weFmM45wkp32ntjOCtJDbkzcKHsYPJ0uyXv4uzL8Ey9usP3jIvVfS3b/7XdfNhFnNieVx9CcyI4L0aLIuD5aN/zgQGDRpBz1RD/xAxirJTeoo7kgygcATTmdd+3H8rXkuz4NxaPR0Iss=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3551.namprd11.prod.outlook.com (20.178.250.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.27; Thu, 6 Feb 2020 09:50:29 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a%3]) with mapi id 15.20.2707.023; Thu, 6 Feb 2020 09:50:29 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: The IESG <iesg@ietf.org>, "draft-ietf-6lo-ap-nd@ietf.org" <draft-ietf-6lo-ap-nd@ietf.org>, "Shwetha Bhandari (shwethab)" <shwethab@cisco.com>, "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-6lo-ap-nd-15: (with DISCUSS and COMMENT)
Thread-Index: AQHV2IzboswYmzjUQ0uf9MGXohRBl6gGYZDwgAP8MYCAAGiTEIAAVUFAgAIHboCAAMIVUA==
Date: Thu, 6 Feb 2020 09:50:05 +0000
Deferred-Delivery: Thu, 6 Feb 2020 09:49:30 +0000
Message-ID: <MN2PR11MB3565D8C850C5238B162C4C6FD81D0@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <158051274858.21121.16988738930495243847.idtracker@ietfa.amsl.com> <MN2PR11MB3565552065F2F21DD481EEC3D8000@MN2PR11MB3565.namprd11.prod.outlook.com> <20200204030143.GB53329@kduck.mit.edu> <MN2PR11MB35658E5BA1A1DF2BBA232F2DD8030@MN2PR11MB3565.namprd11.prod.outlook.com> <MN2PR11MB3565284DDAB5F7D94CB2F039D8030@MN2PR11MB3565.namprd11.prod.outlook.com> <20200205212015.GC84913@kduck.mit.edu>
In-Reply-To: <20200205212015.GC84913@kduck.mit.edu>
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:b110:bae2:d4a9:9c5b]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b0738560-1016-4f3c-8020-08d7aae9ffd4
x-ms-traffictypediagnostic: MN2PR11MB3551:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MN2PR11MB3551BF24B7BF6ACBF5CF2237D81D0@MN2PR11MB3551.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0305463112
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(366004)(136003)(376002)(346002)(39860400002)(189003)(199004)(8936002)(71200400001)(9686003)(55016002)(81156014)(8676002)(81166006)(7696005)(54906003)(186003)(53546011)(316002)(6506007)(33656002)(76116006)(86362001)(478600001)(966005)(5660300002)(6666004)(66574012)(6916009)(66476007)(66946007)(52536014)(64756008)(2906002)(66556008)(66446008)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3551; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; 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: JdMjaSEqMGac/1APC9Rn1W4kpNiBuTJd9wg8SzUWmFfvNlRDXqGxj2K4hJAkbEWSTG3FCYxSsjuaKfcGgJY+B9qV5cMsGObYQ7hadXhx7CH22AvdliSG5N+myLNfPcK4+1mZqGtP9hZyBOGRHyxmDTEjNqgAt4H9CUZta/1hqIleVNZFhRKXKfuWqa/FObsMsGLlZwkZbrLBTRS6LHYsklLWTAgWrhwYGAZmAWUFgn4M4u6lwAhFsVIrlRt88CmmwdgrbYH8zE5YZEv035oOl0Ede/h6QyxvXOW65jKvfLRw1IhoC8czWfH4skhmFbPYwM4P2nf0Z7eCol0kp23vw8Zu0RQN3bu73cO4PcbhNm8vVTeiAOgiWAF8hc4S28fLzMNh+wEYfhDk9qpDY4isp8BAL511pQgB7BK6w+ZNLJWBmkoBGb2k0WRS20Ju/esumcXPWd0dZU1WxQh1bseumDXwXwY14oZzabYWtoYVg2Pvt/4muPpxbJZpwbQBtRlZJPmtqBeRI82hXMRZuATMIg==
x-ms-exchange-antispam-messagedata: Oo6zwIQXO5fyssztpZcHBSgkqAH/21DV/KrEAlxVdnHX33rTmqw/9lLC5/5iYp/zQRojvQX1Ij3b1i1dzYGvRHQnpH91QfnLXpZhq2zmOaT6yoirIhukK6HwNIqiNh7sIVPwDiKYYbhsR1hqLGb7Wf44Kp2f9M+QuuZkH89q/Ev/2nZREsAvl7Y68hwwBGJeCRxuuvrPyXcGodE3dh9B/Q==
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b0738560-1016-4f3c-8020-08d7aae9ffd4
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2020 09:50:29.1613 (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: 9G1vB1LS17LM+oCuO1Rcj4NPIQLi4UQyWpOdaelBwdMDaOZcDv6vOyZPe70qx+YdQyzVQY10xKwquOQuTxgHtw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3551
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com
X-Outbound-Node: alln-core-12.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/vSIYSa-H_qt6GZkkXnPKVKXVAmI>
Subject: Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-6lo-ap-nd-15: (with DISCUSS and COMMENT)
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: Thu, 06 Feb 2020 09:50:37 -0000

Hello Benjamin

We're getting there.  I snipped the places were we appear to have converged.

Please let me know if the DISCUSS is now solved (we removed all ambiguity on the crypto-ID and forced that a key is employed uniquely for the purpose of this draft and for one crypto-ID).

More below:

> -----Original Message-----
> From: Benjamin Kaduk <kaduk@mit.edu>
> Sent: mercredi 5 février 2020 22:20
> To: Pascal Thubert (pthubert) <pthubert@cisco.com>
> Cc: The IESG <iesg@ietf.org>rg>; draft-ietf-6lo-ap-nd@ietf.org; Shwetha Bhandari
> (shwethab) <shwethab@cisco.com>om>; 6lo-chairs@ietf.org; 6lo@ietf.org
> Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-6lo-ap-nd-15: (with
> DISCUSS and COMMENT)
> 
> On Tue, Feb 04, 2020 at 02:22:23PM +0000, Pascal Thubert (pthubert) wrote:
> > This was truncated when I received the echo, retrying...
> 
> It appears different here as well; interesting.
> I will remove a layer of quoting to make it easier for me to write a reply.
> 
> > Hello Benjamin
> >
> > Whao, that was quick. Many thanks again!
> >
> > I got a comment on the change to BCP201 and looked it up. Seems there
> > was a confusion, BCP 201 is RFC 7696 not RFC 7748. So I rolled back
> > the overload. Did you expect something else?
> 
> I think I did expect something else; I thought I wrote:
> 
> % It's probably better to cite RFC 7696 as BCP 201 directly.
> I guess maybe there was a copy/paste glitch.

Oups then : ) I changed the reference, also for BCP 26.

> 
> > I'm publishing 17 for the delta below, we still have the 3 open
> > points. Please check the diffs at
> > https://tools.ietf.org/rfcdiff?url2=draft-ietf-6lo-ap-nd-
> > 17.txt
> >
> > More below:
> >
> > > > Why do we need to allow ambiguity/flexibility as to the point
> > > representation
> > > > > within a given Crypto-Type value (as opposed to fixing the
> > > > > representation
> > > as a
> > > > > parameter of the Crypto-Type)?  Alternately, what does
> > > "(un)compressed"
> > > > > mean, as it's not really clarified directly?  Furthermore, Table
> > > > > 2 lists an "(un)compressed" representation for type 0 (over
> > > > > P-256), but RFC 7518
> > > notes
> > > > > that the compressed representation is not supported for P-256
> > > > > (Section 6.2.1.1).  I also am not finding the needed codepoints
> > > > > registered in the
> > > JOSE
> > > > > registries to use ECDSA25519 (crypto-type 2) -- do we need to
> > > > > register anything there?
> > > >
> > > > Let us take this one separately in a thread with the co authors
> >
> > I keep this item in the thread, to track that it's progressing
> > separately

Please consider the changes in  https://tools.ietf.org/rfcdiff?url2=draft-ietf-6lo-ap-nd-18.txt 
Did we clear the DISCUSS?



> >
> >
> > >
> > > Perhaps it goes without saying (as part of DAD), but the 6LBR has to
> > > consult its database of ROVR/IP address to determine what response
> > > to give in the DAC.  Part of my question above was about what state
> > > the 6LBR needs and what verification the 6LBR does as part of the
> > > process
> > > -- am I correct that it's just checking whether (1) the requested
> > > address is already registered and (if so) (2) that the ROVR in the
> > > EARO matches the one registered with the requested address?
> >
> > Yes, per RFC 8505, inherited from RFC 6775. I'd say that DAD expressed
> > as you did is the core function of RFC 6775.
> > This draft does not really change the 6LBR, just adds the capability
> > to stimulate a revalidation by the 6LR.
> 
> It sounds like it does go without saying :) Thanks for confirming.

This draft is really an extension of RFC 8505 and cannot be implemented separately.
But I guess it does not hurt to clarify a little bit. Maybe by changing the first paragraph of section 3 as
"
   Section 5.3 of [RFC8505] introduces the ROVR that is used to detect
   and reject duplicate registrations in the DAD process.  The ROVR is a
   generic object that is designed for backward compatibility with the
   capability to introduce new computation methods in the future.  Using
   a Crypto-ID per this specification is the RECOMMENDED method.
   Section 7.3 discusses collisions when heterogeneous methods to
   compute the ROVR field coexist inside a same network.
"
Is that readable?

I'll publish this with the changes suggested by Roman

Thanks a million!

Pascal