[dhcwg] about draft-nalluri-dhc-dhcpv6-lwm2m-bootstrap-options-02.txt

Francis Dupont <Francis.Dupont@fdupont.fr> Wed, 19 July 2017 10:42 UTC

Message-Id: <201707191026.v6JAQ8Wx034118@givry.fdupont.fr>
From: Francis Dupont <Francis.Dupont@fdupont.fr>
To: dhcwg@ietf.org
Date: Wed, 19 Jul 2017 12:26:08 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/UlG6XbGcF5UzHC4Riemp8uM6QoM>
Subject: [dhcwg] about draft-nalluri-dhc-dhcpv6-lwm2m-bootstrap-options-02.txt
Precedence: list

I red draft-nalluri-dhc-dhcpv6-lwm2m-bootstrap-options-02.txt
(it is in the agenda this afternnon) and I found two loose
references to RFC 7296 (IKEv2) section 3.6 (CERT payload).

I have two concerns about this:
 - certificates can be very large, at least larger than a DHCPv4 option
  can carry

 - as IKEv2 is over UDP too this problem is addressed in RFC 7296 by
  allowing many different "encodings" (currently 15 in the IANA
  registry).

So I am afraid authors just took a good text about certificate transport
(BTW I'd pick the same one so my concern is not about the choice)
but missed to add an additional statement about application.

I propose:
 - add something about the encoding byte so nobody will forget to read
  RFC 7296 and for instance put a X.509 certificate as the whole content

 - make a few encodings mandatory to support (*)

Thanks

Francis.Dupont@fdupont.fr

PS (*): if it makes sense in environments where LWM2M is/will be deployed
I highly recommend the hash and URL formats. BTW they were introduced
in IKEv2 so in RFC 7296 a notify was added to indicate support.
This is no necessary for this I-D and of course it avoids large
payload problems (it was designed with this goal).

[dhcwg] about draft-nalluri-dhc-dhcpv6-lwm2m-boot… Francis Dupont