[Iot-directorate] Iotdir last call partial review of draft-ietf-dhc-mac-assign-06
Samita Chakrabarti via Datatracker <noreply@ietf.org> Mon, 11 May 2020 17:30 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: iot-directorate@ietf.org
Delivered-To: iot-directorate@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0AC3A0B00; Mon, 11 May 2020 10:30:28 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Samita Chakrabarti via Datatracker <noreply@ietf.org>
To: iot-directorate@ietf.org
Cc: draft-ietf-dhc-mac-assign.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.129.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <158921822799.18848.1656291944788002906@ietfa.amsl.com>
Reply-To: Samita Chakrabarti <samitac.ietf@gmail.com>
Date: Mon, 11 May 2020 10:30:28 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-directorate/AlkuS7PgeTwQStM9eFsf4gbOhSw>
Subject: [Iot-directorate] Iotdir last call partial review of draft-ietf-dhc-mac-assign-06
X-BeenThere: iot-directorate@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Mailing list for the IoT Directorate Members <iot-directorate.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iot-directorate>, <mailto:iot-directorate-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iot-directorate/>
List-Post: <mailto:iot-directorate@ietf.org>
List-Help: <mailto:iot-directorate-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iot-directorate>, <mailto:iot-directorate-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 May 2020 17:30:29 -0000
Review is partially done. Another assignment may be needed to complete it. Reviewer: Samita Chakrabarti Review result: Almost Ready I took a quick glance at the draft from IoT point of view (only partial review ). Section 4.2 talks about the IoT usecase 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? 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 ? 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]?
- [Iot-directorate] Iotdir last call partial review… Samita Chakrabarti via Datatracker