Re: [mif] MIF draft issues

Steven,

Thanks for the comments. See inline.

11/4/2015, 4:43 AM, Steven Barth kirjoitti:
> 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

Huh?? Anyway, I'll be unresponsive till "ndp-support" part of this mail.

> 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

Explain what you mean by TLV in the context of this draft? This 
word/acronym is not used in the draft.

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

I would advice to read RFC7556 Section 5. This draft mainly concerns the 
transport of the PVD related configuration information.

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

    ..
    with IPv6 RA messages.  However, if a host wants to solicit
    information for a specific provisioning domain it can include the PVD
    identity option into an RS message ..

So it is a hint to a router that someone is interested in a specific 
PVD. I do not think we need to define the implementation details on this 
part further. The router is free to react to the hint as it wishes.

> draft does not place an such requirements on hosts. The draft also does.

The draft also does what?

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

                                                       ...include the PVD
    identity option into an RS message and use the PVD container to sign
    the PVD identity option.

So, the difference should be clear. If you want to sign the idenitity -> 
put it inside PVD_CO with S=1.

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

Hmm seems I missed this from previous comments. If one does not 
understand the used security -> skip the PVD_CO. I'll add this 
clarification.

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

Fair point. I will clarify.

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

    ...
    information.  This specification does not define a replay protection
    solution.  Rather it is assumed that if replay protection is...

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

And replay protecting whole RA would be somehow worse than just 
protecting PVD_CO?

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

TLV?

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

    The PVD container option (PVD_CO) is used to mark the start of the
    configuration options that belong to the explicitly identified
    provisioning domain.  The PVD container option MUST encapsulate
    ...

Also, there is no "place" for other NDP options inside PVD_CO. For 
clarity refer Appendix A.

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

Yes. An unfortunate side effect.

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

Yes. An unfotunate side effect. We are open for more compact solutions.

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

Ack. Will fix.

- jouni

>
>
>
> *** 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.
>
> _______________________________________________
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listinfo/mif
>