Re: [mif] MIF draft issues

[Steven Barth <[e-mail]>]

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.