Re: [mif] Comments on draft-ietf-mif-mpvd-ndp-support

Hi Steve,

Thanks for the review. See my intial comments inline:

7/22/2015, 1:23 AM, Steven Barth kirjoitti:
> Hello everyone,
>
> some probably non-conclusive comments on the NDP-support draft.
>
> 3 "However, including a PVD container or identity
>     options inside a Router Solicitation (RS) NDP messages is also
>     possible (actually, in this way a host can solicit for information
>     from a specific provisioning domain)."
>
> This is awkward. Foremost, hosts only send RSs when they change links
> and also replies to RS may be multicasted to all hosts on the links
> (and often in practice still are).

And what is the issue in that case if all others on the same link see 
what you are asking for?

> In any case I don't see the point of adding the container to the RS and / or
> maybe the Identity. This is just plain ambiguous.

Could you open more the "plain ambiguous" part? Ambiguous how to 
implement or how/when to use? If you have a better wording in mind I am 
happy to see it & incorporate it.

> 3 "The PVD container MUST NOT be fragmented i.e., should the
>     IPv6 packet be fragmented, the PVD container and the accompanying PVD
>     identity MUST both be inside the same fragment."
>
> The i.e. makes it ambiguous. Now MUST the whole container NOT be fragmented or
> MUST every fragment have a PVD Identity or only the first one?

Again, what is ambiguous here? The container must not be fragmented. If 
the ipv6 packet itself is fragmented the container has to be as a whole 
in one of those fragment. If you have a better wording in mind I am 
happy to see it & incorporate it.

>
>
> 3 S-bit: Could this not just be encoded as "Name Type" = 0?

It could. The reason why that is not the case now is that we use RFC6487 
name type registry here are currently value 0 is reserved and therefore 
overloading its meaning in this I-D could be a bit risky.

> 3 "Name Type": I find it peculiar that the name type is selectable but not
> the signature algorithm (at least to my understanding).

Algorithms that are directly mapped to name types are listed in RFC6487.

>
> 3 "Key Hash": Since this doesn't have a length field a client not understanding
> the name type cannot interpret anything in the container even if it does not
> want to check the signature. I'm not sure if this is intended.

Ok. This is a good point. I'll look into this. My earlier assumption was 
that if security is in place and the host does not understand the name 
type -> skip the entire container. But I think we may need to address 
the case where the end host just does not care i.e. "approve exception" 
that is very typical when surfing web and ignoring expired certificates..

> 3 "This MAY imply adding
>     padding zero octets to the tail of the PVD container option until the
>     alignment requirement has been met"
>
> A MAY padding seems awkward and actually ambiguous. (This also applies to
> 4 to a lesser degree)

Care to explain more what is ambiguous? You may end up doing padding but 
not in all cases. If you have a better wording in mind I am happy to see 
it & incorporate it.

> 4 Is it useful that PVD ID is a separate TLV if a container MUST have exactly 1 in it
> and the stand-alone use (e.g. in RS) is probably questionable?

Until the RS piece is resolved a separate option is imho justified.

> 6 Again as for dhcpv6, timestamps may not be ready for checking at the point
> where RAs are evaluated since these are essentially bootstrap protocol and
> not all devices do have RTCs or unauthenticated NTP server options may be used
> to tamper with wallclock settings.

I assume you are now in Section 6?  It says "..some replay protection 
mechanism such as a.. This specification does not define a replay 
protection solution.."

I understand the point that timestamp may not answer the replay 
protection issue but this I-D is not also relying on it either. I am 
happy to remove the "..such as.." part if that is contentious.

>
> 9 RFC 3971 is in informative references but since you use it as source for
> your signature algorithm should it not be normative?

Hmm.. good point. However, we do not want to mandate entire RFC3971 but 
only parts of it. I wonder how to express that in the 
normative/informative references.

- Jouni

>
>
>
>
> Cheers,
>
> Steven
>
> _______________________________________________
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listinfo/mif
>