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

[Steven Barth <[e-mail]>]

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

Section 5 defines what TLVs can and cannot be enclosed, however it is
unclear how any enclosed TLVs are treated or whether and in what respect
they are treated differently from if they would occur on the top-level.
To be more concrete, what should a PVD-aware node do if it receives e.g.
a PIO with A=1 inside a PVD_CO? Assign an address, perform DAD and then
use it at will as defined in RFC 4862 ('Initially, an address is
"preferred", meaning that its use in arbitrary communication is
unrestricted.'). If all PVD SLAAC addresses are unrestricted what is the
point of the exercise of the container? Supposedly similar things could
be said about RDNSS, DNS-Search or other enclosed PVD types as well.

2. The solicitation mechanism using RS seems underspecified.

It is not mentioned how the router should react to receiving a PVD CO /
ID (e.g., include PVD-information only in the specific reply, or in all
subsequent unsolicited RAs for an undefined period of time, ...). This
is unclear esp. considering that hosts do not send RS regularly and the
draft does not place an such requirements on hosts. The draft also does.

Also it is unclear what the semantic difference between an RS with a
PVD_ID inside a PVD_CO (with S=0) and an RS with a PVD_ID is and if
there is none, what the reasoning for this redundancy is.

3. Hosts not supporting security cannot use secured PVD information.

The length of the fields "Key Hash" and "Digital Signature" depend on
the meaning of the field "Name Type" and are thus unskippable in general.

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

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. However nonces do not seem
particularly effective for unsolicited RAs and timestamps rely on
accurate wall-clocks on both server and client side which is not mentioned.
Also the suggested use of SeND would not provide replay protection for
the PVD_CO however only for the whole RA being secured.

7. It is unclear how TLVs are enclosed in the PVD_CO

The PVD_CO definition does not mention where TLVs are enclosed, i.e.,
before or after either Header, Key Hash, Digital Signature, Padding etc.


Miscellaneous Stuff:

* General Design is very space-intensive.

Notably for support of both PVD-aware and unaware nodes enclosed TLVs
need to occur both inside and outside of the container. Also if some
enclosed TLVs apply to multiple PVDs they will be duplicated in
different containers.

In addition in-band security and signatures can easily increase the size
of the overall messages very much, especially since RSA is the only
defined scheme.

* "The PVD identity option (PVD_ID) is used to explicitly _identity_ a
   provisioning domain."



Cheers,

Steven