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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 15 April 2020 12:04 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 F22043A0D7A; Wed, 15 Apr 2020 05:04:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 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, 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=U0d/GQnl; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=JuLSo84e
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 mzBFTyMU4yDi; Wed, 15 Apr 2020 05:04:10 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DF073A0D79; Wed, 15 Apr 2020 05:04:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13141; q=dns/txt; s=iport; t=1586952250; x=1588161850; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=yJpc3GLWRPBSWM06wB5aXYNu8R8NymFXWp39t0fF3P8=; b=U0d/GQnljbpyPjYDKeK3Oo41FhdEt1HoBKhIMZuHe0ac8fcmgRHYsmq4 ZMOFeROsRIU6W9e0FpSBexZHu13WX2plFYabaNTl1QCycU123buGiN5bz mfSTkbG+YTQU/Cmu9gT/xZUzmZAHGplLqcHVkl7aZBU32NGEpRc/VU9cl w=;
IronPort-PHdr: =?us-ascii?q?9a23=3ALslIthRYJzjivi7x/uMWH51aEdpsv++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?A0DfBwDs9pZe/5NdJa1jAw4NAQEBAQE?= =?us-ascii?q?BAQUBAQERAQEDAwEBAYF7gVQkLAVsWCAECyqHYgOKaIJfgQGIcY4ygUKBEAN?= =?us-ascii?q?UCgEBAQwBASMKAgQBAYEwgxQCggMkOBMCAwEBCwEBBQEBAQIBBQRthSoIJAy?= =?us-ascii?q?FcAEBAQEDEi4BATcBCwQCAQgRBAEBAS4hER0IAgQBDQUIGoMFgksDLgEOo0c?= =?us-ascii?q?CgTmIYoIngwABAQWBRkGDBw0Lgg4JgTiCY4JChU2BRBqBQT+BEAFDgU9JNT6?= =?us-ascii?q?CHkkCAgEBGIEUARIBBxwfBSGCfYItjhWKPIFIhHSRYyxJCoJCh36FY4UvhGC?= =?us-ascii?q?CVIEFh0GEZ4g9gX6Bco9ciTeCPpBfAgQCBAUCDgEBBYFpIkQjcHAVO4JpCUc?= =?us-ascii?q?YDYV6i14JAxcVgzuFFIUEPXQCgSeLWScGghYBAQ?=
X-IronPort-AV: E=Sophos;i="5.72,386,1580774400"; d="scan'208";a="463423746"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Apr 2020 12:04:08 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 03FC485c026369 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Apr 2020 12:04:08 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 15 Apr 2020 07:04:05 -0500
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 15 Apr 2020 07:04:04 -0500
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 15 Apr 2020 07:04:04 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=F6qU5+B8RuFYv5QSOgJBbgBSzgE7yPMPDXaOcdKyTHYUEVT9h82mB812Bb4+S7KYtsTX9APFWh2E3IJGgTtA0N6zmSpAHjKoG2k4MWm7xLKN5xenPDmYBQoorlOTvp0/xoP1JD3JMoGN0UYRucMcklxTlL9jVqrEymSRQ+c4OwZPtj6MYSPFgkRZjkuPQ0kBjJTrV1LOHRJ1v565ESWQGJqKQqeNJIijuSwnW5WMlXwf2xSf3FKq18EkvcMA0+01Gi/CI/d0hedVbD21rdm9zy62hOtNvWiiwYWqyzNydzR5eRfun4nCf0DbW3V1Ad6JK4ZLJcQYB4QVAZkCTypH8Q==
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=LjRNynLl5MROEoJx7RRJbRqQZRkrvD79GstNP0pmnXs=; b=OrobdmNIhak4TkFeB7014lohLIugQzNHafmYwyhgwXgB/79R0TNuzObr/dAwRiFDBExgWqfxwBrDgNaFMMsrlmdtKjkizPLUCZHOyLfFsAKiN1wo7bZjtBckNsa83rBUc2qWl9fZiolQi0GPaYNBrCB/1+KD1jBWEq1+j4v0lr1d79gCq641LIjtXzyHz78ohsVZ2Lu0aC7Z3gAd547KV7aXGpjnF9HRAHdn+eJgAat0KnE1aCA0PJ1H3DjGLfWoPyJMCSv9OXD1SI723QSeB+516THicCflA76ouk9dSXGbUbdxaN8arl/e8e4qLp6Z/2aE+iLtauzu4hMiR/DWcg==
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=LjRNynLl5MROEoJx7RRJbRqQZRkrvD79GstNP0pmnXs=; b=JuLSo84eFe7kVEHeWg4m6Z/CgncHb3kFfPP3EKQotVIYEDHc5Ae47SSjLQuYs9JDrgRQu9eXxHCEXjVfHUvBYwZbWtJvJjh4AnP8+sBhoLE41ajjjjpWFmnAsP2UWIfKRTA1sGxBexG/HzwZ0Goq/xRcRyZrZvpd5Y5k8CFbRUU=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31) by MN2PR11MB3744.namprd11.prod.outlook.com (2603:10b6:208:f5::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.26; Wed, 15 Apr 2020 12:04:03 +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.2900.028; Wed, 15 Apr 2020 12:04:03 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Benjamin Kaduk <kaduk@mit.edu>, "6lo@ietf.org" <6lo@ietf.org>, "Mohit Sethi M" <mohit.m.sethi@ericsson.com>, Rene Struik <rstruik.ext@gmail.com>
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>
Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-6lo-ap-nd-15: (with DISCUSS and COMMENT)
Thread-Index: AQHV2IzboswYmzjUQ0uf9MGXohRBl6gO26SAgGuePSA=
Date: Wed, 15 Apr 2020 12:04:02 +0000
Deferred-Delivery: Wed, 15 Apr 2020 11:51:41 +0000
Message-ID: <MN2PR11MB356504F39938790E6FFB0DE8D8DB0@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> <MN2PR11MB35653A3E6D9D20432F2A5D78D81D0@MN2PR11MB3565.namprd11.prod.outlook.com> <20200206173042.GB14382@kduck.mit.edu> <24b06ead-e303-2ce2-d255-d30c7815972c@gmail.com> <20200207000947.GG14382@kduck.mit.edu>
In-Reply-To: <20200207000947.GG14382@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:686b:95ad:c883:2bca]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 76543dc1-2131-4312-4884-08d7e135173c
x-ms-traffictypediagnostic: MN2PR11MB3744:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MN2PR11MB3744A4A95D8D804BDD36421CD8DB0@MN2PR11MB3744.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0374433C81
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB3565.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(346002)(39860400002)(136003)(366004)(396003)(376002)(66946007)(66446008)(66556008)(8936002)(81156014)(110136005)(9686003)(8676002)(86362001)(52536014)(66476007)(54906003)(64756008)(7696005)(76116006)(55016002)(53546011)(6506007)(71200400001)(2906002)(5660300002)(478600001)(66574012)(4326008)(186003)(966005)(316002)(30864003)(33656002); DIR:OUT; SFP:1101;
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: eBmfFd31kaQ2OhWz28D1w1qz86F4xpWyvwrIISI35qXMbF4ZRcsc1LvFWXMLnxyrfQ8d0PpjnsTtC16+/0EyA5KRkQcEsiwADU/53azyFq4zJ527lmwBQyG/Cz8KbkeqOx9j2zk0jTZqV6CJjWAcC90AqcRku8LkfzznZSZdbSayf/DlQhJ2jr0MWdfbrl6CuV2u6BOND0pDuuvqPWk1W9rMkFO87PtF+4C8IA4uAawk6rDiDehrOIhhj8Xp9rznDUZKImu/tyPLLnH2KXeMLrhJ2f5euIE2ohS197r4MvjwWg8eRkxK/5c6/h3G5uOdQdMtQDpcl7NQhRVORVSRmdhICS1IWvzKg8iZ0+t6+6F6JuJJpVzX0Aoo5sUhgDmbTQq8EryNa6oSSHvIansa/rRsJQAJNE5VZdyX/GKy1sFHYmaH+bWRiEK1m89cek/4KsK5NjwNL4txynuaV+D5IlPp7MX1QxO7vZjwn6A7q37s2wXFmJFoqovXAsYFHNZXbN62lpuCHO7ko7ydL0fVGg==
x-ms-exchange-antispam-messagedata: rUK4YI9SANCVEeOphcQH/CGT7n/oUezBnG9MZCzLDwLaHwWba/m/CyFjlRcoILE4zkaGCC9pS0PI17wzLfyAHGuobqpzHmIzB6AAQuleX5LeDIe0sc6K3I0/YQCmC8w2kcLmanlB8lxRDIOirgPNS7Mg7IMb7Ak6ARuJuONRx0xjgt9aw1dAsCNk/1QdTXF8a8CaG12IaH8TQHbeeFWWpg==
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 76543dc1-2131-4312-4884-08d7e135173c
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2020 12:04:03.3648 (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: HEk+0VoWk+6f4f+RBaODrX4earUcb5DGPtmBvBOVuWANUaHBi7z/JlmRpXo0c/6jiIwqpNx2qqTXCBlYsZ9VzQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3744
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com
X-Outbound-Node: rcdn-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/90b7Q5Y_ZRPd6XH1fbe68wHRGyA>
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: Wed, 15 Apr 2020 12:04:13 -0000

Hello Benjamin and 6lo:

Just to let you know and the group that we are still chewing the IANA section on this draft.
Doing that we found 2 important things.

1) JWK may not be the favored format for the key representation in LLNs (vs. COSE's Key Object)
2) We are lacking the signal to tell the 6LN that the 6LR supports AP-ND.

For 1)

We'll poll the list if we can live with JWK only for this version. We have prepared candidate text if not.

In the meantime, and to be opened to the future where more key representations come in, I believe we should extend a change we made for your review in the crypto-id computation and add the whole CIPO to the signed material, as opposed to selected fields from the CIPO (JWK-encoded public key and Crypto-Type value). Doing that, we'll be able to add different encodings, new flags that signal it, and have all that protected in the signature.

The text in "6.2.  NDPSO generation and verification" becomes:
"
*  Concatenate the following in the order listed:

      1.  The 128-bit Message Type tag [RFC3972] (in network byte
          order).  For this specification the tag is 0x8701 55c8 0cca
          dd32 6ab7 e415 f148 84d0.  (The tag value has been generated
          by the editor of this specification on random.org).
      2.  the CIPO
      3.  the 16-byte Target Address (in network byte order) sent in the
          Neighbor Solicitation (NS) message.  It is the address which
          the 6LN is registering with the 6LR and 6LBR.
      4.  NonceLR received from the 6LR (in network byte order) in the
          Neighbor Advertisement (NA) message.  The nonce is at least 6
          bytes long as defined in [RFC3971].
      5.  NonceLN sent from the 6LN (in network byte order).  The nonce
          is at least 6 bytes long as defined in [RFC3971].
      6.  1-byte Option Length of the EARO containing the Crypto-ID.
"
Which is echoed in the signature validation
"
it tries to verify the
   signature in the NDPSO option using the following:

   *  Concatenate the following in the order listed:

      1.  The 128-bit Message Type tag specified above (in network byte
          order)
      2.  the CIPO
      3.  the 16-byte Target Address (in network byte order) received in
          the Neighbor Solicitation (NS) message.  It is the address
          which the 6LN is registering with the 6LR and 6LBR.
      4.  NonceLR sent in the Neighbor Advertisement (NA) message.  The
          nonce is at least 6 bytes long as defined in [RFC3971].
      5.  NonceLN received from the 6LN (in network byte order) in the
          NS message.  The nonce is at least 6 bytes long as defined in
          [RFC3971].
      6.  1-byte EARO Length received in the CIPO.
"
Is that OK?

2) is an easy change, we can extend the 6CIO as we do in RFC 8505 already:


"
4.5.  Extensions to the Capability Indication Option

   This specification defines 2 new capability bits in the 6CIO, defined
   by [RFC7400] for use by the 6LR and 6LBR in IPv6 ND RA messages.

   The "A" flag indicates that AP-ND is enabled in the network.  It is
   set by the 6LBR that serves the network and propagated by the 6LRs.

   The "J" flag indicates that the 6LR supports JWK-encoded keys in the
   CIPO option.


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |   Length = 1  |   Reserved    |J|A|D|L|B|P|E|G|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Reserved                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 4: New Capability Bits in the 6CIO

   New Option Fields:

   J:  1-bit flag.  This 6LR supports AP-ND with JWK encoding

   A:  1-bit flag.  This network supports AP-ND
"
And
"
   This specification protects the ownership of the address.  Its use in
   a network is signaled by the 6LBR by setting the 'A' flag in the
   6CIO.  This is echoed by the 6LRs, that also indicate the key
   encoding format that they support in another 6CIO flag, currently the
   'J' flag for JWK.

   When using a ROVR that is a Crypto-ID, a 6LN MUST use a 6LR that
   supports the key encoding used in the CIPO.  If the 6LR does not
   support the Crypto-Type, it MUST reply with an EARO Status 10
   "Validation Failed" without a challenge.  In that case, the 6LN may
   try another Crypto-Type until it falls back to Crypto-Type 0 that
   MUST be supported by all 6LRs.
"

Does that work for you?

You all keep safe;

Pascal



> -----Original Message-----
> From: Benjamin Kaduk <kaduk@mit.edu>
> Sent: vendredi 7 février 2020 01:10
> To: Rene Struik <rstruik.ext@gmail.com>
> Cc: Pascal Thubert (pthubert) <pthubert@cisco.com>om>; The IESG
> <iesg@ietf.org>rg>; draft-ietf-6lo-ap-nd@ietf.org; Shwetha Bhandari (shwethab)
> <shwethab@cisco.com>om>; 6lo-chairs@ietf.org
> Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-6lo-ap-nd-15: (with
> DISCUSS and COMMENT)
> 
> Hi Rene,
> 
> As implied by the later exchange with Pascal, it may be more expedient to
> move the registration from the LWIG document into the AP-ND one, in which
> case this question becomes moot.  But, for completeness, there is not a strict
> need to change the intended status of the LWIG document in order to use it
> as a normative reference from a proposed standard -- we can run through a bit
> of an exception-handling process to do such a "downref"
> (which in many cases is not an exception, as there's now a list of ones that are
> deemed to be acceptable without additional review:
> https://datatracker.ietf.org/doc/downref/).
> 
> -Ben
> 
> On Thu, Feb 06, 2020 at 12:49:18PM -0500, Rene Struik wrote:
> > Hi Ben:
> >
> > I just read your note below. Does this mean I should simply change the
> > intended status of the next rev
> > ofhttps://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representatio
> > ns/ to Standards Track? Are there any procedural hoops that this would
> > imply or can I just simply change the category field in
> >
> > 	<rfc category="std" ipr="trust200902" docName="draft-ietf-lwig-
> curve-representations-09">? (well, Rev-09 is not out yet, but almost...).
> >
> > BTW - the Rev-09 version will not change any of the existing technical
> content, so does not impact the IANA request section in the published version
> (Rev-08).
> >
> > Best regards, Rene
> >
> > On 2/6/2020 12:30 PM, Benjamin Kaduk wrote:
> > > Hi Pascal,
> > >
> > > On Thu, Feb 06, 2020 at 12:13:43PM +0000, Pascal Thubert (pthubert)
> wrote:
> > >> 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).
> > > I think the technical aspects are all resolved and there just
> > > remains the tiniest of process nits.  Specifically, in order to use
> > > some of the algorithms we define in the protocol we define, we rely
> > > on the IANA codepoints currently requested to be registered by [CURVE-
> REPRESENTATIONS].
> > > So we have a normative dependency on those registrations being made,
> > > but right now [CURVE-REPRESENTATIONS] is listed as only an
> > > informative reference, so there's not anything that will enforce the
> > > sequencing of publication.  It's probably easiest to promote that
> > > reference to being normative and make a note (either near Table 2 or
> > > in the IANA
> > > considerations) that we rely on the codepoints being registered by
> > > [CURVE-REPRESENTATIONS].
> > >
> > > Sorry to be so picky!
> > >
> > >> 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.
> > > Thanks!
> > >
> > >>>> 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?
> > > [covered above]
> > >
> > >>
> > >>>>
> > >>>>> 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
> > > "backward compatibility with" is easy to misparse, so maybe add a
> > > comma, or go with "backward compatibility but adds the capability"?
> > >
> > > -Ben
> > >
> > >>     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
> >
> >
> > --
> > email: rstruik.ext@gmail.com | Skype: rstruik
> > cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
> >