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

["Chakrabarti, Samita" <[e-mail]>]

With corrected  list of additional recipients...

On Thu, May 28, 2020 at 12:41 PM Chakrabarti, Samita <
[e-mail]> wrote:

> + 6lo chairs
>
> Hi Bernie,
> Thanks for the response. I had done some quick partial review  while
> waiting for the full review from Jaime (CC'ed).
>
> Please see in-line below.
>
> On Tue, May 26, 2020 at 4:47 PM Bernie Volz (volz) <[e-mail]> wrote:
>
>> Hum ... I never seemed to have received the original email -
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_iot-2Ddirectorate_AlkuS7PgeTwQStM9eFsf4gbOhSw&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=pWMzx7FsqijEJPyfMBfn-HJss-wVVTf0K5y-cxCTXL8&m=MhwqZQxZSi5uQwLINvhNLxro2iGUmpklZPKzXPeZAYo&s=Wk5IuQiP3TbFfVur_rB-lr9gRarH4Vm7VtQy6hAYlFM&e=
>> .
>>
>> 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?
>>
>> Document author would be the best person to decide where to point back
> to. If section 4.2 is where the reader should point to, please add a
> reference to that section. That will really help with the readability.
> Section 6 was a random suggestive question.
>
>
>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8415-23section-2D22&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=pWMzx7FsqijEJPyfMBfn-HJss-wVVTf0K5y-cxCTXL8&m=MhwqZQxZSi5uQwLINvhNLxro2iGUmpklZPKzXPeZAYo&s=E48ssN8G2VhyyeP8Bb8GAH-sg8e__ROhYmOBLR0n2p8&e=
>> . Perhaps more clarity on what should be added would help?
>>
>>
> Yes, more clarity and some suggestion for the IoT devices would help. For
> example, if there are suggestions that this solution could be used in a
> restrictive environment only, that would be helpful. An IoT security expert
> can help provide a suggestion or text here to mitigate possible threats for
> IoT devices, in case of low power and low capacity IoT devices.
>
> 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.
>>
>>
> Understood.  Perhaps a few sentences (as explained above) may be fine, so
> that implementors will be able to make appropriate choices. I agree
> additional mechanism for IoT devices may not be worthwhile. Large things
> (IoT devices) can certainly use the  DHCP mechanism and the additional
> changes specified here. However, I would like 6lo chairs'  comments and
> their advice on this.
>
>
>
>> 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.
>>
>>
>
> Best regards,
>
> -Samita
>
>
> - Bernie
>>
>>
>> -----Original Message-----
>> From: Éric Vyncke via Datatracker <[e-mail]>
>> Sent: Saturday, May 23, 2020 2:55 AM
>> To: The IESG <[e-mail]>
>> Cc: [e-mail]; [e-mail];
>> [e-mail]; Tomek Mrugalski <[e-mail]>; Ian Farrer
>> <[e-mail]>; [e-mail]; [e-mail]
>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=pWMzx7FsqijEJPyfMBfn-HJss-wVVTf0K5y-cxCTXL8&m=MhwqZQxZSi5uQwLINvhNLxro2iGUmpklZPKzXPeZAYo&s=FCX6F-uLWppM7EFaOFeIuFVExP49DNs7oDdbvBF82Zg&e=
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Ddhc-2Dmac-2Dassign_&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=pWMzx7FsqijEJPyfMBfn-HJss-wVVTf0K5y-cxCTXL8&m=MhwqZQxZSi5uQwLINvhNLxro2iGUmpklZPKzXPeZAYo&s=lJ6Hibrd0Y5o1Yn5wyMq1jBmYasSghT5Cun8ozP9h2o&e=
>>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> Thank you for this useful and easy to read document.
>>
>> Please also address the IoT Directorate review by Samita Chakrabarti:
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_review-2Dietf-2Ddhc-2Dmac-2Dassign-2D06-2Diotdir-2Dlc-2Dchakrabarti-2D2020-2D05-2D11_&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=pWMzx7FsqijEJPyfMBfn-HJss-wVVTf0K5y-cxCTXL8&m=MhwqZQxZSi5uQwLINvhNLxro2iGUmpklZPKzXPeZAYo&s=TQmeA0UlP9-u3LNCN4qZWv_DYUV_hatkOEGmptCHraM&e=
>>
>> Regards
>>
>> -éric
>>
>>
>>
>>