Last Call Review of draft-ietf-mipshop-mos-dhcp-options-
review-ietf-mipshop-mos-dhcp-options-secdir-lc-schoenwaelder-2009-04-24-00

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The document defines DHCP options to discover mobility servers. I have
some general questions and some security specific questions plus a few
editorial nits.

General:

a) You define "Mobility Services" but in the definition of "Mobility
   Server" you refer to "Mobility Support Services". Are the terms
   "Mobility Services" and "Mobility Support Services" the same? If
   yes, choose one and stick to it. If not, a definition is likely
   needed to explain the difference.

b) The document spells out that multiple IP addresses in a DHCP MoS
   option are processed in order of preference. Should the document
   also state explicitly how multiple DHCP MoS options are to be
   processed? One might assume that multiple DHCP MoS options are
   processed in decreasing order of preference as well but I think
   this is not spelled out.

c) I am not a DHCP / DHCPv6 person and thus this question might be
   just show my ignorance - but anyway: Can the new options be used 
   in mixed IPv4/IPv6 environments? Can I obtain IPv4 addresses of
   Mobility Servers from a DHCPv6 server? Can I obtain IPv6 addresses
   of Mobility Servers from a DHCP server?

Security:

d) I think the security considerations should mention that the
   resolution of DNS names itself is a risk unless DNS security is
   applied, perhaps with an explicit pointer to the security
   considerations in <draft-ietf-mipshop-mos-dns-discovery-04>.

e) The text recommends the use of the DHCP authentication option
   [RFC3118] or the use of link layer security. And then the third
   paragraphs starts with "This will also protect the denial of
   service attacks to DHCP servers". There are three questions here:

   - What is "This" refering to? Do both the DHCP authentication
     option and link layer security protect against DoS attacks? Or
     does "This" refer to link layer security only?

   - The security services provided by RFC3118 and link layer security
     are likely not the same. (The RFC3118 option provides me with
     trust that I am talking to the right server while link layer
     security likely only provides me trust that I talked to some
     server on the right link layer endpoint.

   - I find link layer security somewhat opaque since I am not sure
     what precisely this stands for. I understand that it will be not
     a good idea to list link layer specific things here but perhaps
     spelling out which security services a working link layer
     security technology must provide would help.

   My recommendation is to rewrite the security considerations so that
   the text discusses in one paragraph the usage of RFC3118 and then
   in a subsequent paragraph the usage of link layer security
   mechanisms.  Right now, the discussion jumps between these two
   options making it more difficult for me to understand the
   statements being made.

Editorial:

- Items (1) and (2) should be moved from the abstract to the end of
  the introduction. This way, the acronyms are introduced before they
  are used.

- p1: 'a list IP' -> 'a list of IP'

- P2: 'an mobile' -> 'a mobile'

- p2: 'set of different services' -> 'set of services'

- p11: '(as defined in [RFC2131]' -> '(as defined in [RFC2131])'

- p12: '(as defined in [RFC2131]' -> '(as defined in [RFC2131])'

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <

http://www.jacobs-university.de/

>