Subject: [dhcwg] Fwd: Gen-Art Review: draft-ietf-dhc-bcmc-options-02 (and 01)

From: Stig Venaas <[email-masked]>
Date: Mon, 12 Sep 2005 21:02:48 +0200

Here is Elwyn's review. Much of this has been addressed. There are
a number of questions that are not necessarily issues. It does
discuss multiple fqdns which is one of the outstanding issues to
be discussed.

Stig

----- Forwarded message from Elwyn Davies <[email-masked]> -----
Date: Fri, 01 Jul 2005 15:19:46 +0100
From: Elwyn Davies <[email-masked]>
Subject: Gen-Art Review: draft-ietf-dhc-bcmc-options-02 (and 01)
[...]

Background for those on the CC list, who may be unaware of GenART:
GenART is the Area Review Team for the General Area of the IETF.  We
advise the General Area Director (i.e. the IETF/IESG chair) by
providing more in depth reviews than he could do himself of documents
that come up for final decision in IESG telechat.  I was selected
as the GenART member to review this document.  Below is my review,
which was written specifically with an eye to the GenART process, but
since I believe that it will be useful to have these comments more
widely distributed, others outside the GenART group are being copied.

[Note:  I produced a review of version -01 for the IETF last call.  I had 
just finished this and was about to submit it on a just-in-time basis for 
the end of last call ;-), when I gathered that a new version -02 has been 
produced and is on the IESG agenda for 7 July 2005.  So the main review was 
of v01:  I have added some notes about v02.  Essentially my conclusions are 
unchanged, but the details are a little different, in that some problems 
have been fixed but the fixes have introduced some new problems, and not all 
the old problems were fixed.]

Document: draft-ietf-dhc-bcmc-options-02.txt
Intended Status: Proposed Standard
Shepherding AD: Margaret Wasserman
Review Trigger: IESG Telechat 7/7/05

Summary for version -02:
This document is certainly not ready for publication.  Indeed it may (still) 
be fundamentally flawed:

Two questions need to be answered regarding the new version:
- My question to v01, as to whether this is fundamentally flawed, remains on 
the
table (Does it need multiple domain names or can it just use multiple
SRV records for the one wireless access domain - in which case do we
really need DHCP(v6) options at all?).. the authors need to explain why
multiple domain names are needed because I couldn't tell from the BCSMS
document and the wording seems to imply one domain would be enough.
- As a result of the update, 2 DHCP code points are needed: Is there enough 
DHCP option space available for this request to get 2 code points, rather 
than the one which was RFC3361 got?

Detailed review for v02:

The editorial state of the document (apart from s5) is much improved after 
Margaret Wasserman's review.  The majority of my comments are substantive, 
and so I didn't separate out the few editorial nits.

s1: The acronyms 3GPP, 3GPP2 and OMA need expansion.

Abstract/s1/s2: These sections imply that the options have wider application 
than the main focus which is 3GPP2. Whilst it is true that 3GPP  is also 
considering broadcast services, I can find no evidence that either 3GPP or 
OMA are actively considering the use of DHCP options as part of their 
configuration process.  Maybe the implications of wider applicability need 
to be toned down a little.

[S4.1/4.3 etc: Clearly the 'enc' problem and the compression problems 
idwentified for v01 have gone away as the document now stands.]

s4.1: The example at the end of 4.1 is now differently broken: the length 
byte
for the second 'example' component is at the end of the structure rather
than between the 0 for the end of the first domain name and the 'e' for
the start of example.

s4.1/4.2:  ' Use of multiple domain names is not meant to replace the SRV 
records, but rather to allow a single DHCP/DHCPv6 server to indicate the 
broadcast controllers in the access provider's network.'   This sentence has 
been adapted from a similar sentence in RFC3319 and RFC3361 - 'Use of 
multiple domain names is not meant to replace NAPTR and SRV records, but 
rather to allow a single DHCP server to indicate outbound proxy servers 
operated by multiple providers.'  I am unclear about why multiple domain 
names would be needed for '*the* access provider's network'.  This needs 
better explanation - and if it can't be provided then maybe this work is not 
needed at all: multiple SRV records would provide all that is needed perhaps.

s4.5/4.6: Now that there are two separate options for IPv4, all the stuff in 
4.5
and 4.6 which just talks about v6 needs to be duplicated for v4.

s4.6: A reference to s3.1 or RFC1035 might also help regarding encoding of 
domain names and comparisons.

s5: At least: s/applies/apply/, s/spec/specification/, s/in-transist/in 
transit/, s/&/and/
Personally I would redraft this section:
This document does not introduce any new security concerns beyond those 
specified in the basic DHCP [RFC2131] and DHCPv6 [RFC3315] specifications.  
In the absence of  message integrity protection for these options,  an 
attacker could modify the option values to frustrate or divert requests for 
broadcast service.

===============================================
Document: draft-ietf-dhc-bcmc-options-01.txt
Intended Status: Proposed Standard
Review Trigger: IETF Last Call, ending 30/6/05

Summary for v01:
This document is not ready for publication or submission to the IESG: It may 
possibly be fundamentally flawed!  The draft proposes to define two options 
each for DHCP and DHCPv6.  The options and  formats, I discovered after a 
little ferreting, are essentially the same as those defined in RFC 3361 and 
RFC3319 which define options to specify FQDNs or IP addresses for SIP 
servers.  This is clearly a good idea since the idea is to provide FQDNs or 
IP addresses for locating 3GPP2 broadcast servers.

The possibly fundamental point is that I really do not understand why the 
options need to allow for multiple domain names at all!  The document talks 
about controllers in 'the wireless access provider's [singular - my comment] 
network' - it needs to be explained why multiple domain names are needed: 
the specifications which were used to provide the layouts talk about 
accesing SIP proxies in multiple providers, but here we are talking about a 
single provider network apparently.  I may have misunderstood what is going 
on, but I think better explanation is needed:  if in fact we are just 
talking about multiple controllers in one domain then surely all that are 
needed are multiple SRV records??

[These next two paragraphs have been fixed in v02]
Assuming that multiple domain names are actually needed, there are still 
some problems:
Unfortunately, in copying particularly from RFC3361, it appears that the 
authors have not fully grasped what was going on, i.e. that in order to save 
on DHCP option numbers (which are a relatively scarce resource) the two 
possible encodings of the server locations (FQDN, IP Address) are selected 
by an 'enc' byte in a single option type.  This draft propagates the 'enc' 
bit idea but doesn't explain it properly and then asks for two separate DHCP 
option numbers from IANA.  Also the domain name example for DHCP omits the 
enc byte altogether!

It also appears that the implementation of Margaret Wasserman's AD comments 
on v00 of the draft has actually broken the proposal.  Margaret commented 
that it was not terribly sensible specifying a MUST implement for a 
compression facility for FQDNs (in the DHCP IPv4 case) that was then 
explicitly stated to offer little real prospect of saving space (in the 
particular circumstances of this option).  However, the change that has been 
drafted, states that the *client* MAY implement the compression option.  I 
would assume that the MAY should apply to the server - the client MUST 
continue to support it if there is a chance that the server MAY unless some 
sort of option negotiation is specified.  Also, there is a degree of 
uncertainty (inherited from RFC3319) as to whether the IPv6 case also allows 
for RFC1035 compression.

Another revision is needed to sort out these problems before the draft 
proceeds to the IESG.

Detailed Review:
============
The editorial state of the document (apart from s5) is much improved after 
Margaret Wasserman's review.  The majority of my comments are substantive, 
and so I didn't separate out the few editorial nits.

s1: The acronyms 3GPP, 3GPP2 and OMA need expansion.

Abstract/s1/s2: These sections imply that the options have wider application 
than the main focus which is 3GPP2. Whilst it is true that 3GPP  is also 
considering broadcast services, I can find no evidence that either 3GPP or 
OMA are actively considering the use of DHCP options as part of their 
configuration process.  Maybe the implications of wider applicability need 
to be toned down a little.

s4:  The basic layout for the options and significant amounts of  
descriptive text have been lifted from the corresponding work for specifying 
SIP server locations in RFC3361 (for IPv4) and RFC3319 (for IPv6).  This is 
entirely sensible since the aims are largely similar.  Indeed I did at one 
point wonder if a whole lot of text could be saved by just referencing these 
RFCs and giving new names and codepoints, but there are a few differences 
which make it slightly awkquard, and it would create an inappropraite 
dependency.  Unfortunately the 'lifting' has not worked as well as it ought, 
particularly in respect of IPv4.

s4.1/4.3/6:  In RFC3361, it is implicitly acknowledged (and RFC3319 states 
that IPv6 doesn't have the same problem) that DHCP option code points are 
now a scarce resource.  In order to minimise the number of new code points 
requested, RFC3361 includes an 'enc' byte in a single option to distinguish 
the case where the servers are located by FQDNs from the case of IP 
addresses.  This draft perpetuates the use of the enc byte but does not 
explain why it is used and then compounds the problem by asking for two DHCP 
option numbers in s6, and not linking the the specifications of the two 
options in s4. This needs fixing up, presumably by *really* duplicating what 
is defined in RFC3361.

s4.1: The example encoding at the end of the section doesn't match the 
specification - the 'enc' byte is missing!!!

s4.1: As mentioned in Magaret Wasserman's AD review, requiring support of a 
compression capability (from RFC1035) that is unlikely to actually provide 
any reduction in data volume seems a little silly.  Unfortunately the fix 
that has been applied between v00 and v01 of this draft is broken.  The MAY 
needs to apply to the server side which will be generating the option field. 
If compression is available and not negotiated, the client side MUST support 
it. The compression business has been propagated from RFC3361 where it is a 
required feature, although again it is acknowledged that it is unlikely to 
provide much saving.  [Presumably there was some idea in the minds of the 
authors that allowing compression might allow code to be used unchanged from 
DNS servers.]  I would suggest that this draft should be changed as follows 
(see also next comment):
- for s4.1: Do not say anything about clients or servers.  Just specify that 
RFC1035 compression MAY be used in the list of domain names. (or 
alternatively say that it MUST NOT be used)
- for s4.5:  If RFC1035 compression is allowed at all, say clients MUST 
support it.
- for s4.6: If RFC1035 compression is allowed at all, say servers MAY 
support it.

s4.2: As with RFC3319, the use of RFC1035 compression is not mentioned one 
way or the other for the DHCPv6 case.   Presumably  the implication for 
RFC3319 is that compression  MUST NOT be used, since s3.1 of RFC1035 doesn't 
talk about compression.  Since RFC1035 compression is mentioned in this 
draft for IPv4, it should be made absolutely clear whether it is or is not 
available for IPv6. Overall, IMO it would appear sensible to just drop the 
idea of compression from both DHCP and DHCPv6!

s4.1/s4.2:  The common text about using the domain names to do SRV lookups, 
etc would be better placed in the client considerations section (or maybe a 
separate section on the interpretation of multiple domain names).

s4.1/4.2:  ' Use of multiple domain names is not meant to replace the SRV 
records, but rather to allow a single DHCP/DHCPv6 server to indicate the 
broadcast controllers in the access provider's network.'   This sentence has 
been adapted from a similar sentence in RFC3319 and RFC3361 - 'Use of 
multiple domain names is not meant to replace NAPTR and SRV records, but 
rather to allow a single DHCP server to indicate outbound proxy servers 
operated by multiple providers.'  I am unclear about why multiple domain 
names would be needed for '*the* access provider's network'.  This needs 
better explanation - and if it can't be provided then maybe this work is not 
needed at all: multiple SRV records would provide all that is needed perhaps.

s4.2: s/Boradcast/Broadcast/

s4.4: Since s4.2 specifies constraints on the length of the DHCP option, it 
would be appropriate to specify similar constraints for the DHCPv6 option  
(ie. at least one address, multiples of 16 plus base).

s4.5/s4.6: (knock on from the mix up over one or two DHCP options):   
Nothing is said here about how servers and clients handle the two different 
DHCP cases: The text from the last paragraph of s3 of RFC3319 needs to be 
reproduced in this document, assuming the intention is to ask for one DHCP 
option.  If two DHCP options are asked for the text for DHCPv6 needs to be 
expanded to cover the DHCP case as well.

s5: At least: s/applies/apply/, s/spec/specification/, s/in-transist/in 
transit/
Personally I would redraft this section:
This document does not introduce any new security concerns beyond those 
specified in the basic DHCP [RFC2131] and DHCPv6 [RFC3315] specifications.  
In the absence of  message integrity protection for these options,  an 
attacker could modify the option values to frustrate or divert requests for 
broadcast service.
----- End forwarded message -----

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg