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

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 26 May 2020 20:47:19 +0000

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.

- Bernie

-----Original Message-----
From: Éric Vyncke via Datatracker <[email-masked]> 
Sent: Saturday, May 23, 2020 2:55 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Tomek Mrugalski <[email-masked]>; Ian Farrer <[email-masked]>; [email-masked]; [email-masked]
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

---

From: "Chakrabarti, Samita" <[email-masked]>
Date: Thu, 28 May 2020 12:41:58 -0400

+ 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) <[email-masked]> 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=
> .
>
> 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.

> 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.

> 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
> Cc: [email-masked]; [email-masked];
> [email-masked]; Tomek Mrugalski <[email-masked]>; Ian Farrer <
> [email-masked]>; [email-masked]; [email-masked]
> 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=
> 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=
>
>
>
> 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
>
>
>
>

---

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Thu, 28 May 2020 21:26:25 +0200

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) <[email-masked]> wrote:

> https://mailarchive.ietf.org/arch/msg/iot-directorate/AlkuS7PgeTwQStM9eFsf4gbOhSw
> .
>
> covered by https://tools.ietf.org/html/rfc8415#section-22. Perhaps more
> clarity on what should be added would help?
>

[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

---

From: "Chakrabarti, Samita" <[email-masked]>
Date: Thu, 28 May 2020 12:45:11 -0400

With corrected  list of additional recipients...

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

>> 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.
>
>
>> 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.
>>
>>
>> [email-masked]; Tomek Mrugalski <[email-masked]>; Ian Farrer
>> <[email-masked]>; [email-masked]; [email-masked]

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 29 May 2020 11:08:46 +0000

Hi:

Regarding:

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 <[email-masked]> wrote:

On Thu, May 28, 2020 at 12:41 PM Chakrabarti, Samita <[email-masked]<mailto:[email-masked]>> 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).

On Tue, May 26, 2020 at 4:47 PM Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> 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= .

---

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.

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.

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.

Best regards,

-Samita

- Bernie

-----Original Message-----
From: Éric Vyncke via Datatracker <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, May 23, 2020 2:55 AM
To: The IESG <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Tomek Mrugalski <[email-masked]<mailto:[email-masked]>>; Ian Farrer <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Éric Vyncke's Yes on draft-ietf-dhc-mac-assign-06: (with COMMENT)

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.

Regards

-éric