Last Call Review of draft-ietf-mipshop-mos-dhcp-options-
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
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?
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.
- Items (1) and (2) should be moved from the abstract to the end of
the introduction. This way, the acronyms are introduced before they
- 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])'
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany
Fax: +49 421 200 3103 <