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

[Suresh Krishnan <[e-mail]>]

Hi Steven,
   Thanks a lot for your comments. Please find responses inline.

On 07/21/2015 03:57 PM, Steven Barth wrote:
> Hi everyone,
>
> as promised few comments on the DHCPv6 support draft. This is based on roughly
> reading it 1-2 times and not meant to be conclusive in any way. Also I'm not a
> dhc expert, though I have implemented a DHCPv6 client, server and relay myself.
>
>
>
> 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.

>
>
> 5 refers to RFC3791 in key-hash and digital-signature options but 3791 is
> not part of references.

Will add the reference.

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

>
> Also where may your container option be present? Only on the top-level?
> Also inside IA_NA/IA_PD? Inside IAAddr / IAPrefix?
>
> Also in which DHCPv6 messages may your container appear?
...
> 7.1 merely specifies to send ORO etc. in SOLICIT, but not in REQUEST, RENEW etc.
> whereas 7.3 says OPTION_PVD must not be sent if ORO is absent in request

Will add text about the messages that can carry this option.

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

> Some additional stuff related to routers forwarding this kind of information from
> to clients (e.g. your coffee shop example in 8). In general this should applies to CPEs,
> as specified in RFC 7084, especially if they themselves got the information using
> DHCPv6 from an ISP, but not necessarily. Again disclaimer: this list is not conclusive:
>
> Since you don't restrict options inside your container, it may originally contain options
> e.g. FQDN which may only be directed at the specific receiving router but not hosts behind
> it (e.g. the hotspot got the PVD TLVs via DHCPV6 itself). Furthermore the container may
> contain options which are specified to not be sent to clients unless explicitly asked for
> in an ORO. In both instances the "coffee shop router" would need to dynamically remove
> options from the container which will inevitably invalidate the signature of the container.
>
> Also given the "coffee shop router" is supposed to hand out addresses from different PVDs
> and "tag" them appropriately: How is it supposed to do that with just a container which
> SHOULD contain a signature?

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.


> It certainly cannot place IAAddrs or IAPrefixes inside containers since it doesn't have
> the key (there are more and even more severe issues with trying to use containers for IA_Xs
> or IAAdress / IAPrefix but I will skip them for the sake of simplicity for now).
>
> Also, if a hotspot / CER / etc. asks (e.g. an ISP) for PVD information that does
> not necessarily mean that all the hosts behind said router will understand PVD information
> so that router requires that it also gets "legacy" information for "legacy" hosts being
> not PVD-aware OR it needs some guidance to construct that information from data within
> the PVD containers it got.

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.

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

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

Thanks
Suresh