Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers
draft-ietf-dhc-bcmc-options-05

[Note]: 'Two open issues in the WG;  (1) multiple domain names for SRV, and (2) should we include fqdn?  Need to make sure that these are resolved before advancing.' added by Margaret Wasserman

[Ballot discuss]
Extracts from Gen-ART review by Elwyn Davies:

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

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

[Ballot comment]
I received the folloing comments from the Ops directorate by Pekka Savola:

  BCMCS Control Server Domain Name List: Identical content as in
  Section 4.1

... while 4.1 had:

  The general format of the BCMCS Controller Domain list option for
  DHCPv4 is as follows:



          Code  Len  FQDN(s) of BCMCS Controller
        +-----+-----+-----+-----+-----+-----+-----+--
        | TBD1|  n  |  s1 |  s2 |  s3 |  s4 | s5  |  ...
        +-----+-----+-----+-----+-----+-----+-----+--

==> it seems obvious but I guess one could take the "Identical
content" statement literally and include also the Code and Len bytes
to the domain name list part?  Shouldn't be an issue for those with
brains turned on. Not sure if this could use a wording tweak or not.

    |                                                              |
    |    BCMCS Control server-1 address (IPv6 address)          |

==> the right spacing before '|' should be fixed

  An attacker may change information of the BCMCS Controller in packets
  that are in-tranist from DHCP server to the MN, if integrity

==> s/tranist/transit/

[Ballot discuss]
I received the following comments from the Ops directorate by Pekka Savola that needs to be addressed:

substantial
-----------

  +----+----+----+----+----+----+----+----+----+----+----+
  |TBD1| 26 | 7  | 'e'| 'x'| 'a'| 'm'| 'p'| 'l'| 'e'|  3 |
  +----+----+----+----+----+----+----+----+----+----+----+
  +----+----+----+----+----+----+----+----+----+----+----+
  |'c' | 'o'| 'm'|  0 | 'e'| 'x'| 'a'| 'm'| 'p'| 'l'| 'e'|
  +----+----+----+----+----+----+----+----+----+----+----+
  +----+----+----+----+----+----+
  | 3  | 'n'| 'e'| 't'|  0 |  7 |
  +----+----+----+----+----+----+

==> is the example encoding correct?  Based on the description, I
thought it should have been:

  +----+----+----+----+----+----+----+----+----+----+----+
  |TBD1| 26 | 7  | 'e'| 'x'| 'a'| 'm'| 'p'| 'l'| 'e'|  3 |
  +----+----+----+----+----+----+----+----+----+----+----+
  +----+----+----+----+----+----+----+----+----+----+----+
  |'c' | 'o'| 'm'|  0 | 7  |' e'| 'x'| 'a'| 'm'| 'p'| 'l'|
  +----+----+----+----+----+----+----+----+----+----+----+
  +----+----+----+----+----+----+
  |'e' | 3  | 'n'| 'e'| 't'|  0 |
  +----+----+----+----+----+----+

...


  If the length of the domain list exceeds the maximum permissible
  length within a single option (254 octets), then the domain list MUST
  be represented in the DHCPv4 message as specified in [RFC3396] .

==> is this really needed?  Is there really a perceived usage case
where the list would be longer than that?  This seems to be just
inviting a case which is not implemented or tested, and will break
when used.  I'd suggest forbidding the long options for simplicity
unless there exists an appropriate usage case for them..

  If a client receives both the BCMCS Controller Domain Name List and
  IPv6 Address options, it SHOULD use the Domain Name List option.  In
  this case, the client MAY use the BCMCS Controller IPv6 Address
  option only if the servers in the BCMCS Controller Domain Name List
  can not be resolved or reached.
==> is it clear which level of normativeness you mean with the use of
'MAY' in this context?  Did you mean, "In this case, the client MUST
NOT use the ... unless the servers in ..." ?  Using MUST NOT or SHOULD
NOT seems clearer, because 'MAY' in this context can be interpreted
differently.

6.  IANA Considerations
[...]
  The DHCP options should be registered in
  http://www.iana.org/assignments/bootp-dhcp-extensions

  The DHCPv6 options should be registered in
  http://www.iana.org/assignments/dhcpv6-parameters

==> (these would probably be removed by the RFC-editor, but..) I think
it's inappropriate to include this kind of URLs in an RFC.  I'd
suggest removing these two paragraphs; I'd hope that IANA can find the
right registries without this guidance :)

[Note]: 'Please review the -02 version.  It was submitted Wednesday 06/29, but hadn''t shown up in the archive when I added this to the agenda.' added by Margaret Wasserman

IANA Last Call Comments:
Upon approval the IANA will assign the following option codes:

  1.  Broadcast Service Controller Domain Name list (section 4.1)

  2.  OPTION_BCMCS_SERVER_D (section 4.2)

  3.  Broadcast Service Controller IPv4 address option (section 4.3)

  4.  OPTION_BCMCS_SERVER_A (section 4.4)

  The DHCP options should be registered in
  http://www.iana.org/assignments/bootp-dhcp-extensions

  The DHCPv6 options should be registered in
  http://www.iana.org/assignments/dhcpv6-parameters

Do we understand it correctly that items 1 and 3 are for DHCP and items 2 and 4 are for DHCPv6?  Please confirm.

Sent AD review comments to the WG:

General Comments:

The editorial level of this document is not very high.  There are
several places where there are tense conflicts and/or strange wording.
I've marked some of them below, but not all of them.  It might be good
to have someone take a quick editing pass at this document while you
are making changes to address my other comments below.  That would
likely speed up other parts of the process.

Ralph and Stig, this document seems to violate the I-D guidelines in
several places (lines over 80 characters, use of non-example domain
names).  Could you please do a nits check and send the violations to
the authors.  I've marked the violations that I notice, but I may not
have caught all of them.  It would be good if the next version
complies with the I-D guidelines.  See:

http://www.ietf.org/ietf/1id-guidelines.html

Some of the issues I've marked below may be the result of a quick
merger of the IPv4 document and the IPv6 document.  There are places
where the document says IPv4-specific or IPv6-specific things where it
isn't clear to me why the text would not apply to the other version.
Also, there is duplication of text in some places.

Specific Comments (marked with >>):

Abstract

  This document defines new options for Broadcast and Multicast Service
  controller discovery in an IP network.  Broadcast service is being
  developed for 3G wireless networks.  Users of the service interact

>> You need to expand the 3G acronym and make it clearer to which 3G
  networks you are referring.  Maybe "third generation (3G) cellular
  telephone networks" ?

  with a controller in the network to derive informations that are

>> s/informations that are/information that is

>> Does the user (a human being) really interact with the server?
  Or is the interaction handled automatically by the MN or MT
  device?

  required to receive broadcast service.  Dynamic Host Configuration
  Protocol can be used to configure the controller IPv4 addresses or
  fully qualified domain names in the user's devices.  This document
  defines the related options and option codes.

>> I think that you mean that DHCPv4 or DHCPv6 may be used to configure
>> a user's device to access a particular broadcast controller.  However
>> the sentence is ambiguous, as it could also mean that DHCP is used
>> to configure the IPv4 address of the broadcast controller _and_ to
>> configure the broadcast controller's domain name on the user's
>> device. 
>>
>> Why just an IPv4 address or domain name?  What about an IPv6 address?

  While DHCP offers necessary mechanisms for device configuration, it
  lacks the information elements required to configure a mobile device
  to support BCMCS.  This memo is an effort to define the extensions
  needed for DHCP to provide necessary configuration information to a
  mobile device in a BCMCS network.

>> s/this memo is an effort to define/this memo defines

  DHCP is being used in 3GPP2, for example, to assist with the
  discovery of the BCMCS Controller in a mobile operators IP network.

>> s/mobile operators/mobile operator's

  The BCMCS includes a controller component that is responsible for
  managing the service via interaction with the users and other network
  entities.

>> Does the BCMCS really interact with the users?  Or with the mobile
>> terminal, for instance?  We have several documents in the IETF
>> context that describe the 3GPP architecture, and it might make sense
>> to use more precise terminology from that architecture here.  If
>> the terminology differs between 3GPP and 3GPP2, then a terminology
>> section might be called for in this draft, so that more precise
>> terms can be used.

  In order to allow the users to discover the broadcast controllers,
  the clients request for appropriate option codes from the DHCP
  servers using Parameter Request List option.  The DHCP servers need
  to return the corresponding configuration options that carry either
  broadcast and multicast service controller's IP address or fully
  qualified domain name based on configuration.  The motivation for
  this document is to define the necessary options and option codes.

>> s/The motivation for this document is to define/This document defines/

  The user interacts with the Controller to request for
  broadcast/multicast program information from the network (e.g.,

>> s/to request for/to request

  scheduled time, multicast IP address, port numbers).  The User may
  also be authenticated by the Controller while downloading the
  relevant program security related information (such as encryption
  key).  These interactions happen via HTTP and XML.  There may be more
  than one controller in the network.  The user should discover the
  appropriate controller to request the relevant program information.
  For details of Broadcast and Multicast Service operation in 3GPP2,
  see [BCMCS].

>> What do you mean by "the user should discover the appropriate
>> controller to request the relevant program information"?  Does
>> the actual user (a human being) get a list of broadcast controllers
>> to choose from?  How would he/she be expected to make that choice?

4.  Broadcast Service Controller Options

  This section defines the configuration option for the controller of
  Broadcast Service.  The Configuration Option contains the IPv4
  address or of the IPv4 address or the fully qualified domain names of
  the broadcast service controller.

>> "the IPv4 address or of the IPv4 address" ??

  Clients MUST support compression according to the encoding in Section
  4.1.4 of "Domain Names - Implementation And Specification [RFC1035].

  Since the domain names are supposed to be different domains,
  compression will likely have little effect, however. 

>> Why make it a MUST to support something that will have little effect?

  The DHCP option for this encoding has the following format:


          Code  Len  FQDN(s) of Broadcast Controller
        +-----+-----+-----+-----+-----+-----+-----+--
        | TBD |  n  |  s1 |  s2 |  s3 |  s4 | s5  |  ...
        +-----+-----+-----+-----+-----+-----+-----+--


  An example case when two controller domain names e.g.
  bcmc1.carrier1.com, bcmc2.carrier1.com are returned without compression will be:

>> You need to eliminate lines over 80 characters long.

>> You need to use the correct example domain names (i.e. example.com)
  in examples.  See RFC 2606.  Use of other domain names as examples
  is not allowed in RFCs.

4.3  Broadcast Service Controller IPv4 Address Option

  If the 'enc' byte has a value of 1, the encoding byte is followed by
  a list of IPv4 addresses indicating broadcast controller IPv4
  addresses. 

>> What is the 'enc' byte?  And is this a DHCPv4 or DHCPv6 option?

  The controllers MUST be listed in order of preference.
  Its minimum length is 5, and the length MUST be a multiple of 4 plus
  one.  The DHCP option for this encoding has the following format:

>> Why would the minimum length by 5?  Why would the length be a
  multiple of 4 plus one?  Are you talking about the value of
  "len" or the overall length of the option?  I may be somewhat
  confused, but I think that "len" will be a multiple of four
  and that the overall length will be a multiple of four plus
  two.

4.4  Broadcast Service Controller IPv6 Address Option

  This DHCPv6 option MUST carry one or more 128-bit IPv6 address(es) of
  the Broadcast Service Controller in a operators network.

>> Apparently there is an option for IPv6 addresses, so why isn't it
  mentioned in the abstract and introduction?

5.  Consideration for Client Operation for DHCPv6

  A client MAY request either or both of the Broadcast Service
  Controller Domain Name List and the IPv6 Address options in the
  Options Request Option (ORO) as described in [RFC3315].

  If a client receives both the Broadcast Service Controller Domain
  Name List and IPv6 Address options, it SHOULD use the Domain Name
  List option.  In this case, the client MAY use the Broadcast Service
  Controller IPv6 Address option only if, no server in the Broadcast
  Service Controller Domain Name List can be resolved or reached.

>> s/only if, no/only if no/

>> This wording is strange WRT the RFC 2119 language.  If you should
  do something, it is odd to say that you MAY do something else
  "only if" some other condition...  Are you trying to say that
  the client MUST use the Domain List Option unless no server in
  the Brodcast Service Controller Domain Name list can be resolve
  or reached?  Or are you trying to leave open the possibility that
  the client might decide to use the IP addresses instead of the
  domain names in some other case?

>> Is there a reason why this is only a consideration for DHCPv6
  clients?

6.  Consideration for Server Operation

[..]

  Client sends in ORO    Domain Name List        IPv6 Address List
  __________________________________________________________________

  Neither option          SHOULD                  MAY
  Domain Name List        MUST                    MAY
  IPv6 Address            MAY                    MUST
  Both options            SHOULD                  MAY

>> Is this intended only to be considerations for DHCPv6 servers?
  What do DHCPv4 servers do in these cases?  Is it really the case
  that DHCPv6 servers SHOULD send the Domain Name List option when it
  isn't requested by the client?  Why?

7.  Security Considerations

  The security considerations in the base DHCP specs [RFC2131] and
  [RFC3315] apply.  An attacker may change information of the Broadcast
  Service Controller in packets that are in-tranist from DHCP server to
  the MN, if integrity protection is not in place.  In that event, the
  user of the Broadcast service may be diverted to a rogue broadcast
  service controller.  In the absence of a mutual authentication
  procedure between MN and the Broadcast controller, the MN may receive
  wrong or fraudulent information about Broadcast Service.

>> So what is required to prevent this?  Is implementation of specific
  security features a MUST for this specification?  Or is it presumed
  to be safe to use this option in networks with certain properties?

8.  IANA Considerations

  The option code for Broadcast Service Controller options MUST be
  assigned by IANA.

>> I think that there are four option codes that need to be assigned,
  and you should be specific about what they are.  You also need to
  specify the registries in which they should be assigned.

10  Normative References

  [BCMCS]    3GPP2, www.3gpp2.org, "X.S0022, Broadcast and Multicast
              Service in  cdma2000 Wireless IP Network.", February 2005.

>> I can't find this document.  Both X.S0021 and X.S0023 are listed on
  the web site, but not X.S0022.  Where do I find it?