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 12: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 6CC49120891; Thu, 6 Feb 2020 04:14:12 -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=ZSmCPn3k; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=j7RDU/gD
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 mOowRpuRKCcX; Thu, 6 Feb 2020 04:14:10 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E247F12004C; Thu, 6 Feb 2020 04:14:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4599; q=dns/txt; s=iport; t=1580991250; x=1582200850; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+cJucBjG5w81tUwySxJ+MCkBKn5pWC2wuCF64SCVMD4=; b=ZSmCPn3kyBhLRy+GrBmpQL7TftMdVbjt2v/3sXZhPc1mphLwbzVO+5GH iXdzTMB36GUt8sT3T0Vvu8bZYoTt5E+SVZ+dBRQ8jEwnTQI7iLbx5S29U cOH9Ga2Mj/Mj2mCoFrkUYnKaVCLvAx4etl6RFkW5qSm0C/kk8eFlU2GY/ Y=;
IronPort-PHdr: =?us-ascii?q?9a23=3AgFl7ohDXj0YpdeL9G+rUUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs03kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuNOLqciY3BthqX15+9Hb9Ok9QS47z?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKCADOATxe/49dJa1mDg8BAQEJARE?= =?us-ascii?q?FBQGBe4FUUAVsWCAECyqHWwOLAIJfmBKBQoEQA1QJAQEBDAEBIwoCAQGEQAK?= =?us-ascii?q?CPCQ4EwIDDQEBBAEBAQIBBQRthTcMhWYBAQEBAgESLgEBNwELBAIBCBEEAQE?= =?us-ascii?q?BLjIdCAIEDgUIGoMFgkoDDiABAgygLQKBOYhigieCfwEBBYUyGIIMAwaBOIU?= =?us-ascii?q?fhUGBQxqBQT+BEUeCTD6CZAICARmBLxyDQIIskCCHIYh4jzYKgjqHSo8Xgki?= =?us-ascii?q?IEI5NgWaXTpI3AgQCBAUCDgEBBYFpIkSBFHAVgydQGA2OHQwXFYM7hRSFBDt?= =?us-ascii?q?0AoEnimAnghoBAQ?=
X-IronPort-AV: E=Sophos;i="5.70,409,1574121600"; d="scan'208";a="423274012"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Feb 2020 12:14:08 +0000
Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 016CE84G009474 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 6 Feb 2020 12:14:08 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 6 Feb 2020 06:14:01 -0600
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 6 Feb 2020 06:14:01 -0600
Received: from NAM04-BN3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 6 Feb 2020 07:14:01 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ml/KEzr3XD1qKA4odkIbm8X5DQPWDdKz0ln5uIYPx2QGcFqPnugWJ6Z+EX1o3C6Bynfc3O3FdsVJE5K1pX5KMdeCw9ijlrSzOUvZIuS0UcVS/ocjyAcJFZsp2rag2fcwSJenzPq4IZYhSzG7AK3TYPOTZCOO/H1aGjeOqpXrdPHswPb+P+1tf1vUqfSHMiSI4sySwtFLgZ7HOdMij62voMpvreOYFuPyD2w0Fdfts6fXTqARK/2k7IvRBT1hsF+Yg5kyblbL7NWqMIND6n8CpS2K2BjxfRuqEaVST4xGgNBwwcCvBFomewCUWU9u4TviFm9qXJLt8VO+IPzn1u7B8Q==
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=IrnaOz1zFiEJNhB/TQVdWlr0+gp+MppB9+ZH2Q7QqOI=; b=OtuZkRwdY0LwziVFFbpbJ+XcyvAnOcanyhY9ymPWufoW6jVLXwuhtmWHOcRPn46a0938AZST80IihYKC5azI2LeHTIAWE9u9hU9VOe4V/pZivbk/V12oV825ILO0I24rKhM6Meox2ZNwOUI5bkUR15/u6gW3kRlYMvNou3QUe5iKLHxxGtkOlmKsyjopLOW52sKuXz7kUk4bwcDlTfgKW5lKTDIeW61fUBXwXyoWkCjo38y73S/WU8Hg1FiTxqQsKhuEb4g+4htyNDYP1d8iqQExEHG7lYJoWqpRZXrDJsboJj1byrDpkNVlBXmFuCYS5NZ72C+iHLxcb7htTWqdEQ==
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=IrnaOz1zFiEJNhB/TQVdWlr0+gp+MppB9+ZH2Q7QqOI=; b=j7RDU/gDUoryLVqR78x+Hldi76R8dS+M25F9sbmUfgPV1/E1upM4lgBC8Q7vjfhQIA9/evj8yloN89olhtySMDx09U04ZlQDiqJNtZ2oMNq7Z0kzLQnQZMQUIaQlLAwQns8IFtyJUcsssocz8yp9Pbt2oiNoqUVu6B8D49u2Xns=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4510.namprd11.prod.outlook.com (52.135.36.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.32; Thu, 6 Feb 2020 12:14:00 +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 12:13:59 +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: AQHV2IzboswYmzjUQ0uf9MGXohRBl6gGYZDwgAP8MYCAAGiTEIAAVUFAgAIHboCAAMIVUIAAIpOA
Date: Thu, 6 Feb 2020 12:13:43 +0000
Deferred-Delivery: Thu, 6 Feb 2020 11:00:13 +0000
Message-ID: <MN2PR11MB35653A3E6D9D20432F2A5D78D81D0@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> <MN2PR11MB3565D8C850C5238B162C4C6FD81D0@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB3565D8C850C5238B162C4C6FD81D0@MN2PR11MB3565.namprd11.prod.outlook.com>
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:10e4:7b65:5b94:6d07]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1836a75b-7321-498c-db6d-08d7aafe0be0
x-ms-traffictypediagnostic: MN2PR11MB4510:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MN2PR11MB45109EB3B2A624D97AEA1D57D81D0@MN2PR11MB4510.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0305463112
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(346002)(396003)(366004)(39860400002)(189003)(199004)(53546011)(6506007)(2940100002)(478600001)(4326008)(2906002)(966005)(33656002)(186003)(66574012)(7696005)(8936002)(81156014)(316002)(54906003)(81166006)(86362001)(6916009)(5660300002)(76116006)(52536014)(55016002)(71200400001)(66946007)(9686003)(66446008)(8676002)(6666004)(64756008)(66476007)(66556008); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4510; 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: PFrV8Qqxq2zqHW7fj0W0FZIEve1wulhdgojShUL0i7kB7KH3TqgXbQbYiauSZDzNx89FXivkbob26f5rQdhVuhoyB9wJBsdHHCWxb4icQCHwQwAN1mFyVwUf1/X6yc2d27vxOSJqSurfNAO2F/FU1BUOfpzCqpHjfL3xQh3J+1ISCYlDYaNJiK42D6aMzFu7tVcn9wApjlbbZB+okJXAYN47YQN4EnsGXATec7RvMKd6HN/BGhptrp9+krVP+cXprUD/fl9R9Z4whMHWDc0OOTOPMOo4Z+MPC5iU+pzCYWzXjOqn+iooq0dI8gzltQD/0CllLfuaemzA7Pl30671VTWk7J/4/6fd1erkaXR65tkjH3I59n7EimmY/8FnsUAqmcrccVjuVxfUeDMVZLLd9N/+i1Mn6CsEArjwtRIPoGWFVGj8/5h7132qQXpqiEf5y1sGZ2jzj5XMf93rCX//mq2ujUmKlJLldMtou/86e/T0HCXteHhbDnryGExRmsd6YHTonW+5ARKX4uJcQX9M0A==
x-ms-exchange-antispam-messagedata: CKCldFAaqumuaLGVYw8+/lAUGJwYqFogGDTzsIr3hdI39GBqwdenmrYtPC1u0lP/r4Sb5CGJ7VjnfAfcKCaXR1qivy9l6OzK5oAwIlj7+49WcA9EY830Mw1BEI8hYaMfSon53yrqezlAUg59wRCOJb1Dp+uZDfLEdcKuXYuk8gbjTlzpneg1rPk+t0thV8+c1cr9fmzbiO7D3+WB5aGx3Q==
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 1836a75b-7321-498c-db6d-08d7aafe0be0
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2020 12:13:59.1436 (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: wK0/LOX1pQKifeh9KScWRO2LCv0DXBAnIjhG8PLTCkEIHubqMn+5NL4lmDmSC+VN8jeR4/q2y65sKXX+XZ1c2g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4510
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/JtYx9gCxt1B-aYRUl2Z0HHObJEQ>
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 12:14:12 -0000

Hello Benjamin 

<truncated again, retrying>

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