Re: [dhcwg] [Iot-directorate] Iotdir last call partial review of draft-ietf-dhc-mac-assign-06

CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es> Thu, 28 May 2020 19:26 UTC

Return-Path: <cjbc@it.uc3m.es>
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 E80EF3A07E3 for <dhcwg@ietfa.amsl.com>; Thu, 28 May 2020 12:26:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es
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 ixtkVtBTv50e for <dhcwg@ietfa.amsl.com>; Thu, 28 May 2020 12:26:43 -0700 (PDT)
Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5DF73A085C for <dhcwg@ietf.org>; Thu, 28 May 2020 12:26:43 -0700 (PDT)
Received: by mail-il1-x12e.google.com with SMTP id y17so88659ilg.0 for <dhcwg@ietf.org>; Thu, 28 May 2020 12:26:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CBSmWJZFcoAHTxsmok966EATTV207ONUk1me0u7rwFs=; b=dxAEEDbfW7NvTGwFlP6FgJwkazqQXXW3oYKpsYWsnO0yLonMDDykmaBXNPdFNeoYFo VRF49XzgBJz5ccBWW+M+eLhkXQ9bJKsaTGKN4GnuMaOH+bnKJzDQVO+ay1kduVulEwzi CjZ/m1EfDJGXrjm3hzspCC1xl0OcuX887jWMHRLI5pT8HJwfw2iImTo1qK3b15+fIKtV j6qXDXbvDj9mvW/K1+dAFEqOeE+PpMIKbIfuO5kiNUGQPj7pgeQrWBK8bP8WCXZG7vfg kvFGe9sffSn8IAg0sibfGYiYJ4/87norhp61MIJH4fv5yHbJD3YqFbIHVoR7cDp3txVD UEyw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CBSmWJZFcoAHTxsmok966EATTV207ONUk1me0u7rwFs=; b=TyI18oy0F/+tUPxG97+zfioL2/CcdyBLS0J1gTn/0KLUp+1D7u5XOtDD1dpZITQjSX 83QLMdDpkj+67i7CetmIjt5g4MBgwbS46dgW1FYTlrKnNPIKhWxUd2rCdCb5kB+MUx4F S/YhagWOx10tZSt6cJjXr48n7b/IbLFWabLajgcCdgxgs40CqzqJVITSbUXxvCkhn1Ue 2ieEwYKXbfXW4W5QZZiuUO3MjdnTR4zo1vE3GQDnCAIyf22WPURvahazeMLTvzuURkPD oS57g6R4fQIdM56AeuYZncDVN3tw/laEc8W9d6kWh4QlTsI8AIGZkr5KPUEu5NdbPnKg zY+g==
X-Gm-Message-State: AOAM532oh49OvnQj9TquMzbVw2UCS3vp1qHpP2mbR4Q7G0SKfe9PfM9P PGhjtpt1JMgMFVYektwqaM97w42HVDaEjBSZNLyjaQ==
X-Google-Smtp-Source: ABdhPJxlQdnzbYCVkPYzEa3EJRDv8vXgBt4D//NEpauxIdBLpPi5e+e1PjWYimRXP6HPMIH38pEcExWFT1aRqp1Emag=
X-Received: by 2002:a92:980f:: with SMTP id l15mr4242156ili.251.1590694001982; Thu, 28 May 2020 12:26:41 -0700 (PDT)
MIME-Version: 1.0
References: <BN7PR11MB2547E35FBB803AFF5BA8102CCFB00@BN7PR11MB2547.namprd11.prod.outlook.com>
In-Reply-To: <BN7PR11MB2547E35FBB803AFF5BA8102CCFB00@BN7PR11MB2547.namprd11.prod.outlook.com>
From: CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>
Date: Thu, 28 May 2020 21:26:25 +0200
Message-ID: <CALypLp_KPCv-qvMJn3qdgOevc+6XH1gEq4kHtFPwB7dcZFLGiw@mail.gmail.com>
To: "Bernie Volz (volz)" <volz@cisco.com>
Cc: "Eric Vyncke (evyncke)" <evyncke@cisco.com>, Samita Chakrabarti <samitac.ietf@gmail.com>, "draft-ietf-dhc-mac-assign@ietf.org" <draft-ietf-dhc-mac-assign@ietf.org>, "dhc-chairs@ietf.org" <dhc-chairs@ietf.org>, "dhcwg@ietf.org" <dhcwg@ietf.org>, Ian Farrer <ianfarrer@gmx.com>
Content-Type: multipart/alternative; boundary="000000000000ef85d705a6ba4e30"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/y2HquSV5_xcrFlTHWp3MT7HjZTQ>
Subject: Re: [dhcwg] [Iot-directorate] Iotdir last call partial review of draft-ietf-dhc-mac-assign-06
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: Thu, 28 May 2020 19:26:46 -0000

Hi,

Apologies for the belated response. Please see inline below for some
comments on the IEEE aspect.

On Tue, May 26, 2020 at 10:47 PM Bernie Volz (volz) <volz@cisco.com> wrote:

> Hum ... I never seemed to have received the original email -
> https://mailarchive.ietf.org/arch/msg/iot-directorate/AlkuS7PgeTwQStM9eFsf4gbOhSw
> .
>
> Some comments below (BV>).
>
> ---
> I took a quick glance at the draft from IoT point of view (only partial
> review ).
>
> Section 4.2 talks about the IoT use case as Direct Client Mode -- where
> they
> talk about cheap devices which may not have unique UUID associated with it.
>
> Note that a client that operates as above that does not have a
>    globally unique link-layer address on any of its interfaces MUST NOT
>    use a link-layer based DUID (DHCP Unique Identifier), i.e., DUID-LLT
>    or DUID-LL.  For more details, refer to Section 11 of [RFC8415].
>
> 1. However,  it is not clear what  source initial link-layer address
> should be
> used by these devices. should it point to section 6? will that suffice?
>
> BV> There are two different issues here. One is the DUID this device would
> use for DHCPv6 - we were just pointing out here that these devices must not
> use Link Layer based DUIDs (hence, they should use DUID-EN or DUID-UUID).
> In terms of the "initial link-layer address", I'm not sure that a reference
> to section 6 (I assume of the dhc-mac-assign draft) would be useful? In
> section 4.2, we already say "Upon first boot, the device uses a  temporary
> address, as described in [IEEE-802.11-02-109r0], to send initial DHCP
> packets to available DHCP server", so I'm not sure what is missing?
>
> 2. Moreover,  how safe the mechanism would be if the Security section says
> that
> mechanism defined in this draft may be used by a bad actor ?
>
> BV> I'm also not sure what would be needed here? I guess we could point
> out that randomly selecting an initial mac-address and trusting a DHCPv6
> server to assign an address is very insecure? But that's pretty much
> covered by https://tools.ietf.org/html/rfc8415#section-22. Perhaps more
> clarity on what should be added would help?
>
> 3. It appears to me the mechanisms are designed for VMs behind an
> hypervisor
> and then IoT usages are added. My concerns are two fold for challenged low
> capability IoT devices -- 1) will they be able to handle the complicated
> option
> processing described here? 2) How to mitigate the security vulnerability
> for
> IoT devices as direct clients?  (The security section does not talk about
> mitigation)
>
> Should there be a simpler option processing structure without TLV option
> processing ( i,e a fixed structure part + then TLV part for optional
> information]?
>
> BV> The TLV structure is what DHCPv6 is based on. I'm not really sure that
> this is that complicated and if it is ... this is OPTIONAL - a IOT device
> could consider using it; of course, if it really is low end perhaps it is
> not the best technique for it? The IEEE was also working on a specification
> for doing link-layer address assignment and theirs (when available) would
> most likely be at a much lower layer in the "stack" and may be better
> optimized for the IOT case (and may also cover the initial allocation issue
> that exists with DHCPv6). So the IOT case was indeed not the first
> priority, as that likely would be better accommodated by IEEE.
>
> BV> I don't know if Carlos might have some more data on the IEEE work, as
> my contacts at IEEE seem to have dried up.
>

[Carlos] From what I understand IEEE is working on some mechanisms, as
Bernie has mentioned, and also referencing this draft as one of the
possible solutions. I can try to ask about more details to one colleague
that participates in IEEE.

Carlos


>
> - Bernie
>
>
> -----Original Message-----
> From: Éric Vyncke via Datatracker <noreply@ietf.org>
> Sent: Saturday, May 23, 2020 2:55 AM
> To: The IESG <iesg@ietf.org>
> Cc: draft-ietf-dhc-mac-assign@ietf.org; dhc-chairs@ietf.org;
> dhcwg@ietf.org; Tomek Mrugalski <tomasz.mrugalski@gmail.com>om>; Ian Farrer <
> ianfarrer@gmx.com>gt;; ianfarrer@gmx.com; samitac.ietf@gmail.com
> Subject: Éric Vyncke's Yes on draft-ietf-dhc-mac-assign-06: (with COMMENT)
>
> Éric Vyncke has entered the following ballot position for
> draft-ietf-dhc-mac-assign-06: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dhc-mac-assign/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you for this useful and easy to read document.
>
> Please also address the IoT Directorate review by Samita Chakrabarti:
>
> https://datatracker.ietf.org/doc/review-ietf-dhc-mac-assign-06-iotdir-lc-chakrabarti-2020-05-11/
>
> Regards
>
> -éric
>
>
>
>