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

[Steven Barth <[e-mail]>]

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