Re: [mif] MIF draft issues

[Jouni Korhonen <[e-mail]>]

Thanks for resending -  that was needed ;) I have finally ended my 
marathon travels and will get back to these comments asap.

- Jouni

11/5/2015, 2:32 PM, Steven Barth kirjoitti:
> Sorry resending, message got garbled.
>
>
> On 05.11.2015 21:45, Jouni Korhonen wrote:
>
>>> *** 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.
>
> Well, ICMPv6 option.
>
>
>
>>
>>> 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.
>
> I know that RFC. It is mentioned once in the intro of your draft, but that
> doesn't really help here. Anyway even if there would be a proper
> reference to Section 5 here: I guess your intention is that all the TLVs
> inside the container only "apply" to that PVD for some obscure definition
> of apply. As someone who has implemented one or two RFCs, I think that
> is much too vague to result in anything remotely interoperable.
>
> Let's simply say I get a RFC 4191 RIO. Now quoting that RFC
> "Then as the host processes Route Information Options in the Router
> Advertisement message body, it updates its routing table for each such
> option."
>
> Now what happens if that thing is in a PVD_CO? I still update my routing
> table? I suddenly need one routing table per PVD? (Note RFC 7556
> doesn't explain routing anywhere).
>
> The same is true for most RA options that could possibly be enclosed.
>
>
>
>>
>>>
>>> 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.
>
> So since there is no defined state machine or similar this "mechanism"
> is there to... provide un-interoperability? I mean clearly since there are
> no requirements here I can only use that if I control both the router
> and the client, e.g. for piggibagging obscure proprietary behavior into it.
>
>
>>
>>> 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.
>>
>
> Please reread my paragraph above, it is unclear what the difference is
> between a top-level PVD_ID and a PVD_CO with S=0 so an unsigned
> container in an RS and / or why both seem to be allowed.
>
>
>>>
>>> 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.
>
> Okay, so the intention is basically that if the router signs a PVD_CO,
> hosts that do not support authentication cannot use the PVD
> information even if they don't care about the signature.
>
> I do not particularly like that, but if that was your intention please
> write it out in the draft.
>
>
>
>>
>>>
>>> 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...
> Well, what's the point of specifying this authentication then if you
> leave it open to attacks?
>
>>
>>> 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?
>
> Well the scope is different, what it tells me is that the RA wasn't
> replayed. However the one authenticating the RA could have "sniffed"
> a foreign PVD container somewhere and just inserted it into its RA.
> The result is, you have a known-unreplayed RA from person A with a
> replayed PVD_CO of person B.
>
>
>
>>
>>> 7. It is unclear how TLVs are enclosed in the PVD_CO
>>
>> TLV?
> ICMPv6 option
>>
>>> 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
>>     ...
>
> Okay so if it "marks the start" then the intention is all options are put
> on the top-level? But how does that "encapsulate options?"
> My main problem is that your PVD_CO seems to be defined as a
> "closed" option (in the diagram, which seems to be the source for the
> on-the-wire-encoding) without any variable length fields anywhere so
> it is unknown where and how someone could "encapsulate" options
> into it, which btw. should be explained somewhere what you mean
> by that term exactly.
>
>
>
>>
>> Also, there is no "place" for other NDP options inside PVD_CO. For
>> clarity refer Appendix A.
>>
>
>  From the example in your Appendix it seems to be that there is an
> undefined variable field at the end of your PVD_CO where options
> are just dumped in. If that is the intention, then please specify that.
>
>
>
>>> 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.
>>
>
> I guess this should be noted in an
> Applicability section.
>
>
>>> 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.
>>
>
> Well obvious choices are e.g. to use EdDSA.
>
> Also there should be an applicability section somewhere that deals with
> this. Say I have 2 different authenticated PVDs that are secured
> with a 4096-bit RSA key and want to use SeND on top of that (or 3
> PVD_COs with SeND) then even the PVD_CO "headers" might exceed
> my MTU. Guidance on how to avoid that is missing.
>
>