Subject: [dhcwg] draft-ietf-dhc-dhcpv6-opt-netboot-07

From: Alfred Hönes <[email-masked]>
Date: Tue, 22 Dec 2009 14:47:56 +0100 (MEZ)

Hello again,
I have studied the most recent DHCPv6 Netboot draft,
draft-ietf-dhc-dhcpv6-opt-netboot-07, from scratch and have
one serious concern, one security considerations issue,
and a few editorials to mention.

(1) Major issue:
  Confusion about URIs, IRIs, and URLs, and appropriate charsets.

The draft is inconsistent in the use of "URL" vs. "URI".
If it really wants to use URIs, it should use the more modern
term, and not "URL".
Per STD 66 (RFC 3986) URIs per definition are tied to the US-ASCII
charset.  You specify UTF-8 for the "boot-file-url" field.
That does not make sense.  Even if you have an IRI (represented in
UTF-8), it would have to be converted to US-ASCII, according to
RFC 3987, before it can be handed out as a URI (or "URL").
If you really want to use IRIs instead (PS so far, subject to
revision), you can stay with UTF-8, but **please** refrain from
calling them "URL", and rename all fields and code point identifiers
to clearly say so.
For IRIs, there's no such term like "IRL"; this might be interpreted
as RFC 3987 envisioning that, for the foreseeable future, an IRI
intended to be specifically used as *locators* would have to be
transformed into a URI to be called "URL".

Arguably, there is value in emphasizing that the URI/IRI passed in
the Boot URI/IRI Option must be a resource _locator_, i.e. directly
resolvable to a protocol and a network object addressable and
accessible via that protocol; but if you want UTF-8 and hence IRIs,
the language needs to be changed, e.g.:
  an URL to a boot file  -->  an IRI directly resolving to a boot file

The most striking examples of inconsistency are ...
in the 1st para of Section 3.1,
                              vvvvv
|  This option consists of an UTF-8 string.  It is sent by the server to
|  inform the client about an URL to a boot file.
                              ^^^
and in the field explanation near the end of that section,

|  boot-file-url     This UTF-8 string is the URL for the boot file, as
|                    defined in [RFC3986].  The string is not NUL-
                     terminated.

STD 66, [RFC3986], specifies US-ASCII for URLs/URIs, not UTF-8.

(2)  Issue: Unrealistic text in Security Considerations

Section 7, in its last paragraph, contains an allusion to HTTPs usage.
Is that, realistically, an option in a Boot ROM environment???
Serious use of HTTPS includes certificate and certificate path
validation, online CRL lookup, or OCSP or SCVP usage, etc.
Where should the necessary trust anchors come from at the Boot ROM
level?
(And also please note that RFC 2817 is _not_ related to HTTPS;
 it describes the inband protocol mechanism to "upgrade" to TLS
 after establishing a HTTP connection, as it is done for POP, IMAP,
 NETCONF, etc., and would be preferred by the management of the
 Port Numbers registry, which in the future will no more admit
 registering a distinct port number for the same protocol/service
 over TLS, as did RFC 2818 for HTTPS.)

More realistically, physical network security or link-layer crypto
might be an option for specific deployments, and that should perhaps
be spelled out in the draft.
In some environments, the TCP MD5 option (RFC 2385) or its possible
successor discussed in TCPM (TCP-AO, the TCP Authentication Option)
with preconfigured static keys may be a perspective for integrity
protection of the boot file download in certain scenarios where
link-level crypto is not available.

(3) General textual issue: length field descriptions

There seems to be textual confusion between the length of a field
and the (overall) length of a DHCP option, with much verbiage added
with the apparent intent to clarify the (IMO) improper terms used.
The length field of a DHCPv6 Option generally specifies the length
ot the option value.  If the option value consists of a single data
field, the shortmost and most precise phrase possible would be to
simply say so for the length.  Using positive language enumerating
what is included seems to be much more clear and preferable over
using "subtractive" notion.

(3a)  in Section 3.1

|  option-len        Length of the Boot File URL option in octets (not
|                    including the size of the option-code and option-
|                    len fields).
---
|  option-len        Length of the boot-file-url in octets.

(Or substitute "boot-file-uri" or "boot-file-iri" as appropriate
based on the resolution for item (1) above.)

(3b)  in Section 3.2

|  option-len        Length of the Boot File Parameters option in octets
|                    (not including the size of the option-code and
|                    option-len fields).
---
|  option-len        Cumulative length of the boot file parameters and
|                    their length fields, in octets.

(3c)  in Section 3.3

Please also not that the specific designation of the field from the
diagram should be used for clarity!

|  option-len          Length of the "processor architecture type" field
|                      in octets (not including the option-code and
|                      option-len fields).  It MUST be an even number
                       greater than zero.  See [RFC4578] section 2.1 for
                       details.
---
|  option-len          Length of the "Architecture Types" field in
|                      octets.  It MUST be an even number greater than
                       zero.  See [RFC4578] section 2.1 for details.

(4)  more editorial nits

(4a)  Section 1, 3rd para

missing article:

|                 ... configuration files from central server, ...
---
|                 ... configuration files from a central server, ...

(4b)  Section 3.3, 2nd-to-last para -- singular/plural issues

   The client can use this option to send a list of supported
   architecture types to the server, so the server can decide which boot
|  file should be provided to the client.  If a clients supports more
        vvv                     v             ^       ^
|  than one pre-boot environments (for example both, 32-bit and 64-bit
   executables), the most preferred architecture type MUST be listed as
   first item, followed by the others with descending priority.
---
   The client can use this option to send a list of supported
   architecture types to the server, so the server can decide which boot
|  file should be provided to the client.  If a client supports more
|  than one pre-boot environment (for example both, 32-bit and 64-bit
   executables), the most preferred architecture type MUST be listed as
   first item, followed by the others with descending priority.

(4c)  Section 3.4

Please expand the acronym "UEFI" on first use.

Isn't UNDI and this option very much vendor specific for a specific
kind of processor architecture?  Therefore, the first sentence,

|  The Client Network Interface Identifier option is sent by a DHCP
|  client to a DHCP server to provide information about its level of
|  Universal Network Device Interface (UNDI) support (see also [PXE21]
|  and [UEFI23]).

seems to express the need to send this option in too strong language.
How about (and changing from passive to active voice as well, as
recommended by the RFC style guide):

|  If the client supports the Universal Network Device Interface (UNDI)
|  (see [PXE21] and [UEFI23]), it may send the Client Network Interface
|  Identifier option to a DHCP server to provide information about its
|  level of UNDI support.

(maybe s/may/MAY/ )

(4d)  Section 5, 1st para -- missing article

                                                    [...]  Please note
   that for IPv6, this supersedes [RFC906] which recommended to use TFTP
|  for downloading (see [RFC3617] for TFTP URL definition).
---
                                                    [...]  Please note
   that for IPv6, this supersedes [RFC906] which recommended to use TFTP
|  for downloading (see [RFC3617] for the TFTP URI definition).
                                      ^^^^       ^
or:
                                                    [...]  Please note
   that for IPv6, this supersedes [RFC906] which recommended to use TFTP
|  for downloading (see [RFC3617] for the 'tftp' URI definition).
                                      ^^^^^^^^^^   ^

(4e)  Section 5, 2nd para

Note that it has turned out to be convenient to enclose URI Scheme
names in single quotes, because they frequently occur in document
titles and headlines, which often get quoted and thereby enclosed
in double quotes; thus, syntax confilcts with nested double-quotes
can be avoided easily.
Furhter, anecdotal evidence has shown that presenting text that
apparently pretends the trailing colon to be part of a URI Scheme
name has caused trouble.  RFC 3986 makes it clear that the colon is
_not_ part of the URI Scheme name.

Therefore, I suggest to change:

|  When using iSCSI for booting, the "iscsi:"-URI is formed as defined
   in [RFC4173].  [...]
---
|  When using iSCSI for booting, the 'iscsi' URI is formed as defined
   in [RFC4173].  [...]

(4f)  general: detailed citations

Please enhance the language and readability by switching from
terse  "[RFCxxxx] section zz"  style to  "Section zz of [RFCxxxx]".

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Thomas Huth <[email-masked]>
Date: Sun, 27 Dec 2009 12:14:00 +0100

Hello Alfred!

Sorry for the late reply, but I got a lot of holiday stress
recently ... ;-)

> If it really wants to use URIs, it should use the more modern

Actually we really mean URL, not URI, since IMHO it does not make too much
sense to boot from a URN.

> charset.  You specify UTF-8 for the "boot-file-url" field.

That's also what I've originally thought and we had this in an older
version of our draft, but Ted Lemon told us to use UTF-8 instead:

http://www.ietf.org/mail-archive/web/dhcwg/current/msg10165.html

Ted, any comments on this?

> calling them "URL", and rename all fields and code point identifiers

I think we should not use IRIs here. I guess most firmware implementations
do not have a full blown i18n implementation and if I've got RFC3987 right,
HTTP also does not work well with IRIs:

"On the other hand, in the HTTP protocol [RFC2616], the Request URI is
defined
 as a URI, which means that direct use of IRIs is not allowed in HTTP
requests."

So I think we should stay with URLs in our draft.,

> Where should the necessary trust anchors come from at the Boot ROM

I think this is just a matter of firmware implementation. If somebody has
really need for this, it can be implemented in firmware, too.>
And IIRC, HTTPS for booting has been suggested by someone at the IETF 74
meeting in San Francisco, so there seems to be real interest in this topic
(I wasn't there at that meeting, so maybe one of the attendees can say
something about this? Vincent?)

> using "subtractive" notion.

Ok... I thought some explicit words might help here to make it easier to
read, but if people prefer it more condensed, that's fine for me, too. So
has anybody else any thoughts on this?

> (4)  more editorial nits
[...]

Ok, thanks for spotting these! I will correct them with the next update.

Mit freundlichen Grüßen / Kind regards,
   Thomas Huth
                                                                           
    IBM Deutschland                 Vorsitzender des Aufsichtsrats:        
    Research & Development GmbH     Martin Jetter                          
    Schönaicher Str. 220            Geschäftsführung: Dirk Wittkopp        
    71032 Böblingen                 Sitz der Gesellschaft: Böblingen       
    Tel.: +49-7031-16-2183          Registergericht: Amtsgericht           
                                    Stuttgart, HRB 243294

---

From: Ted Lemon <[email-masked]>
Date: Sun, 27 Dec 2009 11:17:41 -0500

> Ted, any comments on this?

I think going against the RFC is a bad idea.   I agreed to UTF8 because someone proposed it and it sounded right.   What I would do is make sure that this RFC isn't being revised now to allow UTF8.   Lisa Dusseault would probably know one way or the other.   If it's not being revised, go with the current spec.   If it is being revised, and now specifies UTF8, go with that.

> has anybody else any thoughts on this?

Less is more.   :')