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

[Behcet Sarikaya <[e-mail]>]

I did not see any comments on -ndp-support draft.
Maybe it should have been named ra-support.

Behcet

On Wed, Jul 22, 2015 at 4:08 PM, Steven Barth <[e-mail]> wrote:
>
>
>>
>>> 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
>
> _______________________________________________
> mif mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mif