Subject: [dhcwg] DHCP and DHCPv6 options for LWM2M services

From: Srinivasa Rao Nalluri <[email-masked]>
Date: Mon, 9 Jan 2017 07:00:00 +0000

Hi,

Considering growing popularity of Internet of Things and relevant protocols like LWM2M/CoAP/MQTT, we in Ericsson see need for new DHCP options to make LWM2M service deployment easy and flexible.

Light weight machine to machine (LWM2M) protocol is used to manage end device life cycle in machine to machine communication scenarios.
LWM2M device bootstrap is an optional life cycle phase for devices to  get needed information when starting up for first time.  Information
gathered during bootstrapping might include management server details  and security certificates required to establish connectivity with
management server.  Information required to connect with bootstrap  server might be hard coded during device manufacturing phase.

Hard coding configuration by device manufacturer forces device  operator to use same configuration as hard coded.  It is possible
that reachability information of bootstrap server that is hard coded may be outdated and boot strap server reachability might fail during
first use of device.  In such cases connectivity with bootstrap server is possible only through device software upgrade.

So, we see need to introduce two options to support LWM2M server URL and LWM2M server certificate that validates public key provided by LWM2M server. Thus bootstrap related information can be gathered by LWM2M client during DHCP/DHCPv6 negotiation phase. Draft available at below link describes details.

https://www.ietf.org/internet-drafts/draft-nalluri-dhc-dhcpv6-lwm2m-bootstrap-options-01.txt

This draft considers options for both DHCP and DHCPv6.

I would like this draft to be considered by DHC working group as work item. Please contact me for any further details.

With Regards
Srinivasa Rao Nalluri
Ericssion
India

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Jan 2017 09:21:02 -0500

How would this be validated?

> On Jan 9, 2017, at 2:00 AM, Srinivasa Rao Nalluri <[email-masked]> wrote:
> 
> Hi,
>  
> https://www.ietf.org/internet-drafts/draft-nalluri-dhc-dhcpv6-lwm2m-bootstrap-options-01.txt <https://www.ietf.org/internet-drafts/draft-nalluri-dhc-dhcpv6-lwm2m-bootstrap-options-01.txt>
>  
> _______________________________________________
> dhcwg mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dhcwg <https://www.ietf.org/mailman/listinfo/dhcwg>

---

From: Srinivasa Rao Nalluri <[email-masked]>
Date: Tue, 10 Jan 2017 03:58:07 +0000

Hello Ted Lemon,

If I understand correct, you are asking how certificate supplied through DHCP option is validated.

The certificate supplied through DHCP option is not validated but it can be used to validate certificate offered by LWM2M server during LWM2M bootstrapping phase.

Instead of hardcoding root certificate in device by manufacturer, we are proposing to obtain same through DHCP option.

In case I misunderstood your question, please elaborate same.

With Regards
Srinivas

From: Ted Lemon [mailto:[email-masked]]
Sent: Monday, January 09, 2017 7:51 PM
To: Srinivasa Rao Nalluri
Cc: [email-masked]; Ari Keränen; Jan Melen; Jaime Jiménez; Amit Gupta X
Subject: Re: [dhcwg] DHCP and DHCPv6 options for LWM2M services

On Jan 9, 2017, at 2:00 AM, Srinivasa Rao Nalluri <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

With Regards
Srinivasa Rao Nalluri
Ericssion
India
_______________________________________________
dhcwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Simon Hobson <[email-masked]>
Date: Tue, 10 Jan 2017 08:06:52 +0000

> Instead of hardcoding root certificate in device by manufacturer, we are proposing to obtain same through DHCP option.

I can see the use case, but now you validating the information being provided ... using a certificate provided by an untrusted source.
Thus, if someone has enough access to redirect your devices to use their server, they probably have enough access to provide the fake certificate to make their server trusted. I'm assuming this is what Ted was alluring to.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 10 Jan 2017 16:25:22 +0000

Maybe if seDHCPv6 is used, this could resolve some issues ... though of course, there is still the question of how to trust the seDHCPv6 certificate!

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Simon Hobson
Sent: Tuesday, January 10, 2017 3:07 AM
To: [email-masked]
Subject: Re: [dhcwg] DHCP and DHCPv6 options for LWM2M services

[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Jan 2017 12:01:10 -0500

> Thus, if someone has enough access to redirect your devices to use their server, they probably have enough access to provide the fake certificate to make their server trusted. I'm assuming this is…

Yes, this is exactly what I was alluring to.   :)

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 12 Jan 2017 14:08:10 +0000

Hi:

A couple of (I think) additional comments on this draft:

1.       It be best to use DHCPv4 and DHCPv6 (and use DHCP for when you are specifically referring to both)? For example, it helps to be clear that an option is a v4 vs v6 option.

2.       For the DHCPv4 , you don't need the sequence number in the OPTION_LWM2M_SERVER_CERTIFICATE option and much of the text below. DHCPv4 already supports LONG options (more than 255 bytes of data) - see RFC 3396 - Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4). You just need to say that this option uses this encoding.

   Maximum possible value of DHCP "option-len" is 255.  LWM2M-server-
   certificate MAY be of length more than 255.  To accommodate larger
   certificate, it SHOULD be possible to include multiple
   OPTION_LWM2M_SERVER_CERTIFICATE options in same DHCP message.  DHCP
   server SHOULD be capable of including multiple
   OPTION_LWM2M_SERVER_CERTIFICATE options in same message.
   Certificates larger than 255 byte SHOULD be fragmented and adjusted
   in minimum possible number of OPTION_LWM2M_SERVER_CERTIFICATE
   options.  Each OPTION_LWM2M_SERVER_CERTIFICATE option is tagged with
   a sequence number which can be used by DHCP client to reassemble
   received certificate

-          Bernie

---

From: Srinivasa Rao Nalluri <[email-masked]>
Date: Thu, 12 Jan 2017 16:04:32 +0000

Hi Bernie Volz,

Thanks for your review and comments.
#1 In genera in other documents 'DHCP' is used to indicate DHCP for IPv4 networks and 'DHCPv6' is used to indicate DHCP for IPv6 networks. Anyhow what you said makes sense  and looks clear way. I will consider for next version.

#2 I will consider this for next version.

Thanks & Regards
Srinivas

From: Bernie Volz (volz) [mailto:[email-masked]]
Sent: Thursday, January 12, 2017 7:38 PM
To: Srinivasa Rao Nalluri; [email-masked]
Cc: Ari Keränen; Jan Melen; Jaime Jiménez; Amit Gupta X
Subject: RE: DHCP and DHCPv6 options for LWM2M services

Hi:

-          Bernie

---

From: Srinivasa Rao Nalluri <[email-masked]>
Date: Fri, 13 Jan 2017 06:45:55 +0000

Hi,

To add more on certificate validation....

Idea is to trust your DHCP server to give valid certificate. Otherwise we have risk.
In TLS/PKI frame work there is no way to validate root certificate. That remains same with our proposal.

In TLS root certificates are generally not exchanged using any protocol. So risk is less.

Our proposal is trade-off between flexibility and risk

With regards
Srinivasa Rao Nalluri

From: Srinivasa Rao Nalluri
Sent: Tuesday, January 10, 2017 9:28 AM
To: 'Ted Lemon'
Cc: [email-masked]; Ari Keränen; Jan Melen; Jaime Jiménez; Amit Gupta X
Subject: RE: [dhcwg] DHCP and DHCPv6 options for LWM2M services

Hello Ted Lemon,

With Regards
Srinivas

Cc: [email-masked]<mailto:[email-masked]>; Ari Keränen; Jan Melen; Jaime Jiménez; Amit Gupta X

Hi,

With Regards
Srinivasa Rao Nalluri
Ericssion
India

---

From: Ted Lemon <[email-masked]>
Date: Fri, 13 Jan 2017 09:33:02 -0500

> Idea is to trust your DHCP server to give valid certificate. Otherwise we have risk.

Right, but on what basis do you trust the DHCP server?   There is no authentication, and no pre-established trust relationship if there were authentication.