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

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

Return-Path: <Francis.Dupont@fdupont.fr>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 3EE21131C82 for <dhcwg@ietfa.amsl.com>; Wed, 19 Jul 2017 03:42:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id QjOcovF5d9cM for <dhcwg@ietfa.amsl.com>; Wed, 19 Jul 2017 03:42:43 -0700 (PDT)
Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0257131C77 for <dhcwg@ietf.org>; Wed, 19 Jul 2017 03:42:42 -0700 (PDT)
Received: from givry.fdupont.fr (localhost [IPv6:::1]) by givry.fdupont.fr (8.14.7/8.14.7) with ESMTP id v6JAQ8Wx034118 for <dhcwg@ietf.org>; Wed, 19 Jul 2017 12:26:08 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr)
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
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Jul 2017 10:42:44 -0000

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

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 (*)



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