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

From: Steven Barth <[email-masked]>
Date: Tue, 21 Jul 2015 21:57:00 +0200

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

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

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?

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

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.

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

Cheers,

Steven

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 22 Jul 2015 13:13:48 +0000

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

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

Will add the reference.

> 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 in which DHCPv6 messages may your container appear?
...
> 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.

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

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

> 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

---

From: Steven Barth <[email-masked]>
Date: Wed, 22 Jul 2015 23:08:59 +0200

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

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

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

> be sent only if it is in the ORO.If the CPE does not request this, it 
> 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.

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

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

> 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

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 23 Jul 2015 03:54:35 -0500

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 <[email-masked]> wrote:
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif