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

["Bernie Volz (volz)" <[e-mail]>]

Hi:

Regarding:

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.

My point was that:
1) I am not sure what needs a reference?
2) Saying in section 4.2 see section 4.2 is kind of silly?

I am trying to address your comment but am not clear on what the issue is to make an appropriate change. Thanks.

- Bernie

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


With corrected  list of additional recipients...

On Thu, May 28, 2020 at 12:41 PM Chakrabarti, Samita <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>
Sent: Saturday, May 23, 2020 2:55 AM
To: The IESG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Tomek Mrugalski <[e-mail]<mailto:[e-mail]>>; Ian Farrer <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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