Draft: draft-ietf-dhc-bcmc-options-02.txt (and -01) Reviewer: Elwyn Davies Date: Friday 7/1/2005 9:20 AM CST Summary: This document is certainly not ready for publication. Indeed it may (still) be fundamentally flawed. Review Comments: 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.