[mif] MIF draft issues

[Steven Barth <[e-mail]>]

As requested in the DT meeting, here is a summary of the issues and from
my reviews of the 3 "core drafts".

To be honest I'm totally put off by the lack of responsiveness from all
draft authors and will probably not do any more reviews here if there
isn't a significant improvement on this matter.


Cheers,

Steven


*** Conceptual (apply to all 3) ***

1. Lack of metadata
Neither draft defines any kind of metadata or seems to consider any
addition of it. Currently only opaque identifiers are used which must be
previously acquired via other means to understand a PVD, i.e. it is not
possible to convey:
* if the PVD offers intenet access or not
* if use of the PVD is metered or not
* general constraints of using the PVD
* even a human readable name


*** mpvd-id ***

It is not clear why this multitude of types is needed. If it is kept
there should be some guidance on why it is not possible to simply use
one unique type format like FQDN or a reasonably small unique
fixed-length ID based on e.g. a PEN or IPv6-prefix assigned to the PVD
owner followed by a small localy significant ID.

1+3. "Any source that does not provide either guaranteed or
probabilistic uniqueness is probably not a good candidate for
identifying provisioning domains." - I don't see how type "UTF-8 string"
fits this definition.

Abstract: the abstract claims the document "describes several methods of
generating identification information for provisioning them". However I
can't find that anywhere, I can only find a TLV-definition.

3: It is unclear what the actual format for the specified id-types is,
at least for some of them, e.g. is the UUID in binary format or
string-representation? FQDN is unclear as well, RFC1035 never mentions
this abbreviation and also given it would be clear it still doesn't say
if it uses the textual or label sequence representation?

4: Security Considerations do not apply at all. Your abstract says:
"This document describes several methods of generating
identification information for provisioning them and a format for
carrying such identification in configuration protocols."
however your security considerations explain attacks on (2 specific)
protocols the TLV might be used in instead of security implications of
using different types of identifiers e.g. like security considerations
of UUID in RFC4122

5: IANA Section lacks policy for further allocations (see RFC5226)

3: "The configuration protocol used and its extensions are
meant for that purpose [I-D.ietf-mif-mpvd-dhcp-support]
[I-D.ietf-mif-mpvd-ndp-support]." - This sentence does not parse.



*** ndp-support ***

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.


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

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



*** dhcp-support ***

0. This draft cannot be freely implemented in open source software.

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.

7. Contradicting requirements language
#1: "The PVD container option SHOULD contain at most one (i.e. zero or
one) OPTION_PVD_AUTH."
#2: "If present, the OPTION_PVD_AUTH option MUST be the last option
inside the OPTION_PVD option."
#1 implies I could choose to send more than one OPTION_PVD_AUTH (by not
following the SOHULD) however #2 implies there can only be 0 or 1.

8. Missing normative reference to RFC 3971 (see Section 5).

9. Client and Server Behavior inconsistent
Section 7.1 only instructs client to send an ORO in SOLICIT messages,
however in Section 7.3. servers expect it to be sent (only?) in request
messages.

10. Security concept seems mostly redundant
Since addresses or prefixes are expected to be part of most PVD
containers, DHCPv6 servers need to modify PVD containers in nearly all
cases (by including IA_NA, IAPD, IAAddr, IAPrefix, ... options).
Therefore - aside for very special cases - the DHCPv6 server would need
the private key for signing in any case so plain DHCPv6 authentication
could be used in the first place.