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

[Hui Deng <[e-mail]>]

Hello all, 
 
Steven sent this, by some chance, it was not shown up in our list, so I cc here
 
From: Steven Barth <[e-mail]>To: [e-mail]: Date: Tue, 21 Jul 2015 21:55:49 +0200Subject: Comments on draft-ietf-mif-mpvd-dhcp-support-01Hi everyone,as promised few comments on the DHCPv6 support draft. This is based on roughlyreading it 1-2 times and not meant to be conclusive in any way. Also I'm not adhc 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 55 refers to RFC3791 in key-hash and digital-signature options but 3791 isnot part of references.6 specifies that ANY options may be encapsulated. This is awkward, e.g., whatwould be the meaning of e.g. a Status or a Reconfigure-Accept option withinthat container, more general what happens to options explicitly defined to beon 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 request8 mentions the use of timestamps to avoid replay attacks, though DHCPv6 is usuallyused to bootstrap network connectivity and thus at this point devices (especiallyembedded ones) may not have an accurate wallclock yet. This is especially interestingsince DHCPv6 itself may carry NTP server addresses to use.Some additional stuff related to routers forwarding this kind of information fromto 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 usingDHCPv6 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 optionse.g. FQDN which may only be directed at the specific receiving router but not hosts behindit (e.g. the hotspot got the PVD TLVs via DHCPV6 itself). Furthermore the container maycontain options which are specified to not be sent to clients unless explicitly asked forin an ORO. In both instances the "coffee shop router" would need to dynamically removeoptions 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 PVDsand "tag" them appropriately: How is it supposed to do that with just a container whichSHOULD contain a signature?It certainly cannot place IAAddrs or IAPrefixes inside containers since it doesn't havethe key (there are more and even more severe issues with trying to use containers for IA_Xsor 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 doesnot necessarily mean that all the hosts behind said router will understand PVD informationso that router requires that it also gets "legacy" information for "legacy" hosts beingnot PVD-aware OR it needs some guidance to construct that information from data withinthe PVD containers it got.Cheers,Steven