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

[Steven Barth <[e-mail]>]

>
>> 3 SHOULD contain exactly one still allows more than one PVD_AUTH vs.
>> "MUST be the last option inside PVD" in 5
>
> It does not allow more than one. The options are 1 or 0 depending on 
> whether the option was requested in the ORO. If it occurs, it needs to 
> be the last option inside the PVD.
No, it does not say that, there are 3 locations where it says something
about it. One is in 3 which says "SHOULD contain exactly one" and in 5
it says "SHOULD contain at most one" and then again in the next sentence
it says "PVD_AUTH option MUST be the last option". So you actually
managed to contradict yourself 2 times about the same thing.

>> 6 specifies that ANY options may be encapsulated. This is awkward, e.g., what
>> would be the meaning of e.g. a Status or a Reconfigure-Accept option within
>> that container, more general what happens to options explicitly defined to be
>> on some level and / or having a specific meaning there?
> I think it is very difficult to find a good answer here. At the other 
> end of the spectrum we can list the options that are allowed. This has a 
> different set of isues. As I see it, there are three possible options
>
> a) Allow all legal DHCPv6 options to be inside the PVD. Expect 
> reasonable use of options by admins.
>
> b) List all the allowed options in the document.
>
> c) Maintain an extensible (e.g. IANA) registry of the options allowed 
> inside the PVD container
>
> Each of these comes with a different set of pros and cons. We can pick a 
> direction based on what the wg thinks.
There are certainly more options, you could also blacklist options
or describe characteristics of TLVs you want / don't want to be
encaps'ed (e.g. ones that authenticate the DHCPv6 packet).
dhc might want to provide guidance here?

>
>> 8 mentions the use of timestamps to avoid replay attacks, though DHCPv6 is usually
>> used to bootstrap network connectivity and thus at this point devices (especially
>> embedded ones) may not have an accurate wallclock yet. This is especially interesting
>> since DHCPv6 itself may carry NTP server addresses to use.
> Right. This is a real issue that is not specific to mif. The same 
> problem occurs when we need to do DNSSEC validation for the NTP servers 
> provided (as DNSSEC validation requires clock sync).
As far as I know NTP does not depend on DNS at all, you can use it just over IP
and RFC 4075 specifies exactly that for DHCPv6.


> Let me clarify something before we go further. The OPTION_PVD_AUTH will 
> be sent only if it is in the ORO.If the CPE does not request this, it 
> will not get a signed PVD option. It is free to split up the contained 
> options however it wishes. For the homenet use case, I think it would be 
> best not to request the OPTION_PVD_AUTH as it is likely that there is no 
> need to ensure the integrity of the container
I couldn't find that mentioned in the draft.


In any case there is also another big issue here:
A client usually makes one IA_NA request and expects to get
all addresses (from all PVDs?) in that single IA. So you have a severe
scoping issue: You only have one PVD container per PVD-ID, so you need
to duplicate the IA_NA (header) across multiple containers. This is
bad because now you have IA_NAs with duplicate IDs, duplicate
T1 and T2 values and the client must "reassemble" them from different
PVD containers.


> Yes. This is a tough cookie. In the NDP based solution we had a much 
> easier way to do this. We created the option so that legacy clients will 
> just skip over the PVD "container" and look at the options they understand.
It doesn't save you the duplication though, it just makes it explicit
that in the RA case you always have to provide legacy in addition.


> A good way to solve this would be for the DHCPv6 server to send the 
> configuration info outside the container for further distribution to 
> legacy clients along with the info inside the container for the PVD 
> aware clients. Unfortunately, there is no way to request the server to 
> do this with the current ORO mechanism
It might not cover 100% of cases but the presence of an IA_PD
request might be an indicator here that you are dealing with
a router which has clients behind it.


>
> Would some guidance of this form be useful?
>
> "Clients that request the OPTION_PVD with the intention of 
> redistributing configuration information to other clients (e.g. CPE 
> routers) SHOULD NOT request the OPTION_PVD_AUTH in the ORO. This allows 
> them to send out a subset of the received options to their clients and 
> also allows them to support PVD unaware clients by sending out the 
> options without PVD information."
I don't see how the PVD_AUTH plays into the legacy clients, since
you are not encrypting a router can always take out options from
the PVDs and put them into top-level, however there should be
guidance as to when and how that results in useful output, i.e.
if I just take out a random PVDs RDNSS which might only resolve
a certain set of zones and a legacy client tries to use it for internet
connectivity bad things happen.



Cheers,

Steven