Re: [mif] MIF draft issues

[Steven Barth <[e-mail]>]

>> *** 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.
Okay, so as a host I can send an RS with PVD IDs in it, but since it is
unspecified I do not know if or how the router would react. Your draft
also doesn't mandate for hosts when or when not to solicit other than
"when it wants" so the router can make no assumptions as well.

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... > >> 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? I apologize, ICMPv6 options...

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