[mif] Second Review: draft-ietf-mif-mpvd-dhcp-support

[Steven Barth <[e-mail]>]

As for the NDP-support draft:

Thanks for the updated version, here is a second review of the draft. I
intentionally did not look at my first review notes so there might be
duplicates. Feel free to ignore them if they are invalid.


1. It is unclear what to do with enclosed TLVs

The reasoning is similar to the NDP TLVs in the other draft: The draft
defines what TLVs can be enclosed but not how the enclosing affects the
meaning of the TLVs, e.g. is an enclosed RDNSS-TLV or an IAAddr still
generally applicable for all purposes and if not how is the meaning
changed specifically?

This is especially problematic since the draft does not disallow any
TLVs from being inside the container, see also 2.

2. It is unclear how this draft interacts with the Identity Association
state machines defined in RFC3315

i.e. how are IAs and addresses and prefixes actually enclosed here. The
draft needs to specify clearly what happens to identity associations /
address assignments and how they are associated to PVDs especially
taking into account the possibility of having multiple IAs (e.g. IA_NA
and IA_PD) or addresses from different PVDs in the same IA. See also 3.

3. It is unclear where the PVD container option can occur.

Is it restricted to only occur on the top-level or can it occur also
inside other containers (e.g. Identity Associations), if the latter is
true, how does it affect what options can be enclosed in it.

4. Signature calculation is unclear.

The signature generation defined in RFC 3971 includes several other
components (e.g. a CGA message type tag, a kind of pseudoheader, etc.)
besides the actual NDP message being signed. It is unclear if your
signature mechanism uses the same header fields or if the intention was
just to use a plain RSASSA-PKCS1-v1_5 over the PVD container.

5. Mandatory to implement security seems outdated.

The use of SHA-1 as only mandatory hash for key identification and as
only defined hash for signatures seems a bit outdated these days
especially in the light of recent advancements in its cryptanalysis.

This seems especially problematic since there does not seem to be a way
to signal the use of a different signature algorithm.

6. Replay Protection seems not adequately addressed.

No specific mechanism is defined. It is suggested to use either
timestamps or a nonce of an undefined format.
Also the suggested use of DHCPv6 AUTH would not provide replay
protection for the PVD container but for the whole DHCPv6 message being
secured.