Subject: Re: [dhcwg] Review request: draft-ietf-dhc-dhcpv6-lwm2m-bootstrap-options

From: Srinivasa Rao Nalluri <[email-masked]>
Date: Mon, 8 Jan 2018 15:09:25 +0000

Hi Hannes,

Hope you are doing good. 
As discussed during IETF-99, did you get chance to rethink in this regard?

Regards
Srinivas

-----Original Message-----
From: Srinivasa Rao Nalluri 
Sent: Friday, October 13, 2017 11:33 AM
To: 'Hannes Tschofenig'; Ari Keränen
Subject: RE: Review request: draft-ietf-dhc-dhcpv6-lwm2m-bootstrap-options

Hi Hannes,

I am further thinking on this security issue you mentioned. 

Today we have several other servers who's details are shared to DHCP clients as DHCP options. For example Network Time Protocol server, default WWW server and domain name server. 

The issue you mentioned exists in use cases related above mentioned servers and operators are solving issue by deploying DHCP snooping or DHCP relay agents. Maybe LWM2M use case is more sensitive when compare with other scenarios but it can still be secured provided service provider is taking care of it.

Question is what if service provider is not deploying DHCP relay or snooping. I agree there is issue in such case but it becomes deployment problem and we can say service provider is compromised.

By background I am not security expert, but my understanding is  we are talking about an existing problem that is solved for other similar use cases.

Thanks
Srinivas

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Wednesday, September 27, 2017 1:46 PM
To: Srinivasa Rao Nalluri; Ari Keränen
Subject: RE: Review request: draft-ietf-dhc-dhcpv6-lwm2m-bootstrap-options

I think the challenge is to design something that is independent of some other security mechanisms outside the device. Currently, there is no solution in the document that provide this and I fear that in practice this security will not work since those who deploy the solution are not necessarily aware of the tradeoffs.

I fear that your proposal right now causes more security problems then it solves. I will think about can be done about this.

Ciao
Hannes

-----Original Message-----
From: Srinivasa Rao Nalluri [mailto:[email-masked]]
Sent: 25 September 2017 19:25
To: Hannes Tschofenig; Ari Keränen
Subject: RE: Review request: draft-ietf-dhc-dhcpv6-lwm2m-bootstrap-options

Hi Hannes,

Irrespective of what device it is, we can assume all devices are connected to IP network. It is service provider responsibility to provide below mentioned secure deployment mechanisms.
Most importantly, like any other DHCP options, these DHCP options mentioned in current draft are NOT mandatory. Server supplies them only when device requested them in DHCP discover message AND same is configured on DHCP server. If device is not requesting OR DHCP server is not configured with option information, device can always fallback to existing mechanisms to know URI and certificate.

So, service provider has an option of choosing what they want.

Regards
Srinivas

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]]
Sent: Monday, September 25, 2017 10:37 PM
To: Srinivasa Rao Nalluri; Ari Keränen
Subject: RE: Review request: draft-ietf-dhc-dhcpv6-lwm2m-bootstrap-options

Sent a bit too quickly.

The problem is that the IoT device does not known anything about the network environment it sits in. DHCP also offers pretty much no practical security functionality.
So, introducing DHCP for such a security sensitive task sounds like an built-in mechanism for hijacking IoT devices.

-----Original Message-----
From: Hannes Tschofenig
Sent: 25 September 2017 19:05
To: 'Srinivasa Rao Nalluri'; Ari Keränen
Subject: RE: Review request: draft-ietf-dhc-dhcpv6-lwm2m-bootstrap-options

The problem is that the

-----Original Message-----
From: Srinivasa Rao Nalluri [mailto:[email-masked]]
Sent: 25 September 2017 18:21
To: Hannes Tschofenig; Ari Keränen
Subject: RE: Review request: draft-ietf-dhc-dhcpv6-lwm2m-bootstrap-options

Hi Hannes,

Thank you for quick review and question.

Issue you mentioned is valid when DHCP offer from rogue DHCP server is accepted by DHCP client. Today this is generic issue for any DHCP offering. So, it is important to accept DHCP offer from trusted DHCP servers.

Question is, what is trusted DHCP server? Any DHCP server that is controlled and configured by service provider can be considered trusted. As you know, by nature DHCP discovery messages are broadcast and in base DHCP protocol there is no mechanism to control them reaching unwanted DHCP servers in L2 network. This problem can be solved in different ways in network deployment. For example,

- Make sure there is L2 switch between DHCP client and server(maybe on or close to access node) and DHCP snooping function running on it. Make sure DHCP server(s) is reachable through one trusted switch port. Use firewall to filter all DHCP server messages on all other ports.

-Install DHCP relay agent (or proxy) on access node so that broad cast messages are terminated and unicast request are sent to preconfigured DHCP servers.

As these DHCP servers which are reachable through above means are controlled by service provider I don’t see any significant risk. These mechanisms are today implemented in network gateways (For example, PGW in 4G core and Broadband Network Gateway in fixed access )

I did not mention above text in draft considering it as deployment explanation. If you think it make sense we can include this in security section of draft.

With Regards
Srinivas

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]]
Sent: Monday, September 25, 2017 4:01 PM
To: Srinivasa Rao Nalluri; Ari Keränen
Subject: RE: Review request: draft-ietf-dhc-dhcpv6-lwm2m-bootstrap-options

Hi Srinivas,

How do you prevent that an attacker sets up a DHCP server and points to his or her LwM2M bootstrap server and thereby takes full control of the IoT device?

Ciao
Hannes

-----Original Message-----
From: Srinivasa Rao Nalluri [mailto:[email-masked]]
Sent: 25 September 2017 12:19
To: Hannes Tschofenig; Ari Keränen
Subject: RE: Review request: draft-ietf-dhc-dhcpv6-lwm2m-bootstrap-options

Hi Hannes,

We have 2 options proposed in this draft

1)  Option to get bootstrap server URI
2) LWM2M bootstrap server and certificate that validates the key presented by server.

Theses option are proposed to get bootstrap server URI and server certificate dynamically rather than hard coding or statically configuring in device. This option is useful incase bootstrap server URI or certificate is changed by the time device is first bootstrapped or by the time re-bootstrapped. In such case, having dynamic option to get LWM2M bootstrap server information helps in avoiding reconfiguration and manual action.

in this scenario, It is important to trust the DHCP server. In particular certificate option SHOULD be used only when we receive from trusted network/DHCP server.

I can correlate this with several similar use cases like  DNS server and NTP server which are fetched using DHCP.

With Regards
Srinivas

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]]
Sent: Monday, September 25, 2017 3:26 PM
To: Ari Keränen
Cc: Srinivasa Rao Nalluri
Subject: RE: Review request: draft-ietf-dhc-dhcpv6-lwm2m-bootstrap-options

Hi Ari, Hi Srinivas,

Thanks for the introduction.

Srinivas can you say something about the motivation behind the idea of introducing this DHCP option for use with LwM2M.

Ciao
Hannes

-----Original Message-----
From: Ari Keränen [mailto:[email-masked]]
Sent: 25 September 2017 11:51
To: Hannes Tschofenig
Cc: Srinivasa Rao Nalluri
Subject: Re: Review request: draft-ietf-dhc-dhcpv6-lwm2m-bootstrap-options

Hi Hannes,

Sorry I'm a bit late with this, but you had some questions on the security aspects of the LwM2M DHCPv6 options draft. My colleague Srinivas (Cc'd) is the author of the draft.

Srinivas, Hannes is one of the key drivers of the LwM2M specification work in OMA and also author/driver of whole bunch of security (and other) work at the IETF. Please work with Hannes to make sure the security aspects are properly covered by the draft.

Thanks,
Ari

> On 31 Aug 2017, at 8.57, Ari Keränen <[email-masked]> wrote:
>
> IoT Directorate,
>
> We received a review request for "DHCPv6 Options for LWM2M bootstrap information" draft from the DHC WG:
> https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-lwm2m-bootstrap-options
>
> Please volunteer for review, especially if you are familiar with LWM2M protocol (but others are welcome too).
>
>
> Thanks,
> Ari
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.