Re: [dhcwg] Iotdir last call review of draft-ietf-dhc-slap-quadrant-07

"Eric Vyncke (evyncke)" <evyncke@cisco.com> Fri, 05 June 2020 14:45 UTC

Return-Path: <evyncke@cisco.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA8A3A07D4; Fri, 5 Jun 2020 07:45:12 -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_H4=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=BviCRUGb; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=KwzXGvqY
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 heyPvSayCXMf; Fri, 5 Jun 2020 07:45:11 -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 EAE413A07E1; Fri, 5 Jun 2020 07:45:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8052; q=dns/txt; s=iport; t=1591368311; x=1592577911; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=k7dFPUJmhCnsnf02PQ/X2gM/07Z0h5XTYhpwqhxGOnw=; b=BviCRUGbN9o8ZKztzcz2un66r3lDOPMroxsrmoprOD7FyWyvyfe6OfVk g3VLFVLITBF1qhd1gneEljnhAmYfa7YPJxLhFp+/EakiKaYP9YLly0nvW TBXVSktip59R8nw1mv3mNLmU+NHnmRbU1b6th7NByIchKibrTyCLtkBCj 8=;
IronPort-PHdr: =?us-ascii?q?9a23=3ABkOEtRGO9eJ/W5oyvDaH3p1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401A+bXIbarfxF2KLasKHlDGoH55vJ8HUPa4dFWB?= =?us-ascii?q?JNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2YklWGYDwZg6arni79zVHHB?= =?us-ascii?q?L5OEJ8Lfj0HYiHicOx2qiy9pTfbh8OiiC6ZOZ5LQ69qkPascxFjA=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAgBBWtpe/4ENJK1mGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAUCBSoFSUgeBRy8shCWDRgONGiWJfo5TglIDVQsBAQE?= =?us-ascii?q?MAQEtAgQBAYREAheCHQIkOBMCAwEBCwEBBQEBAQIBBgRthVsMhXIBAQEBAxI?= =?us-ascii?q?REQwBATcBCwQCAQgRAwECAwImAgICHxEUAQgIAgQBDQUigwSCTAMuAadXAoE?= =?us-ascii?q?5iGF2gTKDAQEBBYU9DQuCDgmBDiqCZIloGoFBP4ERJwwQgk0+gh6CGIMsM4I?= =?us-ascii?q?tinGDZAFWglqhMEwKglmTOWUEhF8DHZ5BkQCMTpE8AgQCBAUCDgEBBYFqIoF?= =?us-ascii?q?WcBVlAYI+UBcCDZBADBeDT4pWdDcCBgEHAQEDCXyNbQFfAQE?=
X-IronPort-AV: E=Sophos;i="5.73,476,1583193600"; d="scan'208";a="491012711"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Jun 2020 14:45:09 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 055Ej1do015398 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 5 Jun 2020 14:45:09 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 5 Jun 2020 09:45:05 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 5 Jun 2020 09:45:04 -0500
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 5 Jun 2020 09:45:04 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Z/VPRdolx5S54NjiRy3nyOeohaZpCeajYWHv+CLSy4/nq+1mQ4k++Evu5zYRiXQ9w+oBumkKwK3cdTtne9dFWW+wf5bZo9ca16YhVaseesJTWcdsZgL7g5RntfkCjkjIRf020LxFeafcbbHu13YybPwI5AIZStoYwW16jzMXIQtp0g4yIgFvrUuwTAhCCBgf8y7NNuhLXB7uVg+QQ2Rdrw2Rqz/UvuLlrjtEBhO+Czu0KeuUW/R38dTxOPxh1z6EW3V5DIEHe3JwewkevrARip5l+rpWRZRwrFOa3li46I2JHYROhZ43rYTllKD6rZVZV1irj3s9IFc/BMBhyp//2A==
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=k7dFPUJmhCnsnf02PQ/X2gM/07Z0h5XTYhpwqhxGOnw=; b=fhIqXdaN735Nugc8C41wfNwAHWq9PIgz235XKvoJoActbB2h3nEwyk/lnfJ20yi/3p3kpKv6zpd/zYnCKJgtMlPm8DLY9rfs/EKMIzHu0T0yymVupejn4BpoKMuWWcIMygOUh8E0D1/xZsogQMqR4EWG3OVjGTqFxt/0dCBV3eqqNEQ6JvVphzvZg2on55nqhvgxBQpkm91gaAgzUnWt3FZOigrqH2sKEonW0jvO8W9Sabwnd5ishnDKiegDju5dDlScRsaYtdGAWA6NTlByY5MVhXrZNeE7+5d0JfDSAtFwpw6IcXtr6g9m4qmi2EK82vohPiNVK4+FJCYJUZcrog==
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=k7dFPUJmhCnsnf02PQ/X2gM/07Z0h5XTYhpwqhxGOnw=; b=KwzXGvqYM7Pg3+mafjIbcC0GE2EoUpwa2GsOqzdLBhLpTLWP7pTSaa00aoglhw5mIZRoXFrtKyR8pa/sMM42hHJKXSAbCz8tW8PJ6JJHgZmpcZH7Bk+8vs3fTArjHyNzwThmUB40T6U1yivX3crvY8jW+axG6rqlffyfbKJIndg=
Received: from DM5PR11MB1753.namprd11.prod.outlook.com (2603:10b6:3:10d::13) by DM5PR11MB1625.namprd11.prod.outlook.com (2603:10b6:4:b::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Fri, 5 Jun 2020 14:45:03 +0000
Received: from DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::a14c:59b6:47b0:f630]) by DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::a14c:59b6:47b0:f630%7]) with mapi id 15.20.3066.022; Fri, 5 Jun 2020 14:45:03 +0000
From: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
To: Jaime Jimenez <jaime@iki.fi>, "iot-directorate@ietf.org" <iot-directorate@ietf.org>
CC: "last-call@ietf.org" <last-call@ietf.org>, "draft-ietf-dhc-slap-quadrant.all@ietf.org" <draft-ietf-dhc-slap-quadrant.all@ietf.org>, "dhcwg@ietf.org" <dhcwg@ietf.org>
Thread-Topic: Iotdir last call review of draft-ietf-dhc-slap-quadrant-07
Thread-Index: AQHWOkXvAcb55jZvJkmSCOfYRXNJo6jKPMQA
Date: Fri, 5 Jun 2020 14:45:03 +0000
Message-ID: <6AD5240B-F121-4005-9436-67FE5C87EA35@cisco.com>
References: <159125749726.19650.16749433552197061248@ietfa.amsl.com>
In-Reply-To: <159125749726.19650.16749433552197061248@ietfa.amsl.com>
Accept-Language: fr-BE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.37.20051002
authentication-results: iki.fi; dkim=none (message not signed) header.d=none;iki.fi; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2001:420:c0c1:36:49cf:4cb9:c570:518f]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 28076f9e-fff1-46fd-5ba8-08d8095f080a
x-ms-traffictypediagnostic: DM5PR11MB1625:
x-microsoft-antispam-prvs: <DM5PR11MB1625D739022E62AF12C20CA2A9860@DM5PR11MB1625.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0425A67DEF
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: /jVJOfILlFvT9SxXppXlIstMwQ0cabaW+qBr1Nn0iM1v9dKHzp/sfU6stEeGhvvLbz2mQwbE8ChPvWZ/prUxgJx9hjvBEGPKMWKK2rOS2bspezKsnIo/av5+Hk/bwHnlpDQXXf6YXQHWeAvf5Lv6rKis4CwTfuXBV7KttesBdipMGUVWZF3lDFz3eFiIUWQn9ouwTsqY18yYx3NzMR25mJKvbdV4cO8pOOEjsp07bCdT9VIn++ET2bnlyNHInDVeGVIsnWAGhgmFnAlY1DJFsq54qjE0Bsa9eRzxTttVuPBHBERDZJJV5lWJPdNxoadcK3KJoo0Zfstjxn/71Ap61Q==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR11MB1753.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(346002)(39860400002)(366004)(376002)(136003)(2906002)(54906003)(186003)(316002)(83380400001)(2616005)(6512007)(8676002)(4326008)(6506007)(91956017)(8936002)(53546011)(76116006)(66476007)(36756003)(66556008)(66946007)(86362001)(64756008)(6486002)(71200400001)(110136005)(5660300002)(478600001)(66446008)(33656002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: rxushNSGoLTwivgaBwOha873+gt1h27Fz3qRKe6tRUNhmHfFPzH0uMlpbVA7hqx05UI1sPhBCVUZLPel0imtXwHVrLe3gl0mITER3ImmCwnz1/6aKbrehdTuUnO0ptofHg+i6jUzeKJDXEdYqmwFqyX64AkkSjr62DeuBiG0capQluBsq3fH4Qh9hnRbzjnPsKg3Oge64kiYYJRsBNCtKET23Fh57AwJbTfk77lGAqoyyCPMuPQAos6i7GgjgJRnvv84iffNrWDa7UaH1P7bBkVfq4K2aH52CY65n0VMlDLspROZJJw4EYQi39lTFIhDCoIGDvFDEnRKMpsDLbE7cou7kUdL7R9hAdZwcYjBa9B4r3J0lIsAKirK1qcUPiKmlhfAuPeIxyJC2HCWDqA0P9PLTmI8b3/jAaieFsQyT6WbtmPyu4RByow89s2+pdh5vzB4OkzYbZDkKpYF5hxHHsnIic1rYGe3nnNStIoMPLV39OzXPSuecTlBUNSb/GtwtrFxnw73sJJHW0g2GzHZjQpd50J9ZeBrhsce4fooA5c=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <71CA7B62F90AFD4288E652DD4D65A7F6@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 28076f9e-fff1-46fd-5ba8-08d8095f080a
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2020 14:45:03.2775 (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: 5dCfmbkONkEP4qZYejZ6HlkmeUWrzlR1rNwAIFmY2Cy15yMf3JnWQK7+UYfDj6nUN0v8GOn0HRDP1ZpG03Nk+A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1625
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/CCE5L-MgWI_1j_sAPOSgTRHi4tk>
Subject: Re: [dhcwg] Iotdir last call review of draft-ietf-dhc-slap-quadrant-07
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Jun 2020 14:45:13 -0000

Thank you Jaime,

I will make sure that my IESG ballot will refer to your review

-éric

-----Original Message-----
From: Jaime Jimenez via Datatracker <noreply@ietf.org>
Reply-To: Jaime Jimenez <jaime@iki.fi>
Date: Thursday, 4 June 2020 at 09:58
To: "iot-directorate@ietf.org" <iot-directorate@ietf.org>
Cc: "last-call@ietf.org" <last-call@ietf.org>rg>, "draft-ietf-dhc-slap-quadrant.all@ietf.org" <draft-ietf-dhc-slap-quadrant.all@ietf.org>rg>, "dhcwg@ietf.org" <dhcwg@ietf.org>
Subject: Iotdir last call review of draft-ietf-dhc-slap-quadrant-07
Resent-From: <alias-bounces@ietf.org>
Resent-To: <cjbc@it.uc3m.es>es>, <alain.mourad@interdigital.com>om>, <tomasz.mrugalski@gmail.com>om>, <volz@cisco.com>om>, <ek.ietf@gmail.com>om>, Eric Vyncke <evyncke@cisco.com>om>, Tomek Mrugalski <tomasz.mrugalski@gmail.com>om>, Ian Farrer <ianfarrer@gmx.com>om>, <ianfarrer@gmx.com>
Resent-Date: Thursday, 4 June 2020 at 09:58

    Reviewer: Jaime Jimenez
    Review result: Ready with Nits

    draft-ietf-dhc-slap-quadrant-07 iodir review
    ============================================

    This draft is complementary to draft-ietf-dhc-mac-assign. It defines mechanisms
    to allow for the use of IEEE's SLAP quadrant when using DHCP for MAC
    allocation. It also defines a new DHCPv6 Option (QUAD) for that purpose.

    Both drafts verse on the use of DHCP to assign MAC addresses to hosts, which as
    a concept was strange to me to begin with. However I am not up-to-date in the
    latest developments on host configuration so I am likely to be missing a big
    part of the picture.

    I find this draft quite useful to understand the rationale behind
    draft-ietf-dhc-mac-assign, and I regret not having paid more attention to it
    before I did the draft-ietf-dhc-mac-assign review. At the time I understood the
    rationale to be the use of MAC address as a deployment mechanisms while in
    reality, it is a privacy mechanism. I think the security scenario makes more
    sense as IoT devices normally are deployed with MAC information from the
    factory. I believe that is the primary purpose of both dhc-slap-quadrant and
    draft-ietf-dhc-mac-assign when it comes to IoT, perhaps that information should
    be emphasized on draft-ietf-dhc-mac-assign.

    This draft is clearly written and seems ready, below are few concrete comments:

    Abstract:

       Consider splitting in two shorter sentences the paragraph below.

       "                                         [...] Recently, the IEEE
       has been working on a new specification (IEEE 802c) which defines a
       new "optional Structured Local Address Plan" (SLAP) that specifies
       different assignment approaches in four specified regions of the
       local MAC address space."

    Section 1:

        s/specified regions/regions/ ?
        "different assignment approaches in four specified regions of the"

    Section 3:

        "[...] if the IoT device can move, then it might prefer to
          select the SAI or AAI quadrants to minimize address collisions
          when moving to another network."

        I wonder if collisions are likely to occur in practice.

    Section 4.1:

        Naive questions on MAC usage. Could an IoT device self-assign a MAC with a
        specific SLAP quadrant information? Would the DHCP Server accept it without
        the negotiation mechanisms described here (providing it is not in the MAC
        address pool)? Could an endpoint use an OUI from a different vendor? If so,
        how are potential collisions or attacks preventable?

        "[...] The server MAY alter the
           allocation at this time."

        It would be helpful to explain in which way allocation might be altered
        (i.e., by reducing the address block)

        "5.  When the assigned addresses are about to expire, the client sends
           a Renew message.  It includes the preferred SLAP quadrant(s) in
           the new QUAD IA_LL-option, so in case the server is unable to
           extend the lifetime on the existing address(es), the preferred
           quadrants are known for the allocation of any "new" addresses."

        Is it correct to assume that step 5 causes either:
         - to assign the existing block
         - to start on step 1 with the new QUAD if the block is no longer available.

        So, is it then the case that the client sends a Renew message -for the
        existing block- with _alternative_ SLAP quadrants different than the ones
        in use in case the block is no longer available?

        "6.  The server responds with a Reply message, including an LLADDR
           option with extended lifetime."

        What happens with the _fail_ case, in which the block is no longer
        available? How is the REPLY format denying the addresses?

        A style suggestion, as "Advertise", "Renew", "Reply", etc are specific DHCP
        message types, you might want to write them capitalized "ADVERTISE",
        "RENEW", "REPLY", etc to avoid potential confusion.

    Section 4.2:

        "9.   When the assigned addresses are about to expire, the client
          sends a Renew message.
        [...]
        12.  The relay sends the Reply message back to the client."

        Same as in section 4.1, steps 9 to 12 might need to be revised.

    Section 7:

        The Security section looks a bit thin but I have no good suggestions to
        improve. Is it even possible for a bad actor to spoof a RENEW lease on
        behalf of another node? Perhaps some information on authentication
        mechanisms for DHCP would be handy.

    References:

        [IEEEStd802c-2017] does not provide a link to the document. It would be
        useful to include that when available.