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

[Steven Barth <[e-mail]>]

I resent it and it went through. See https://mailarchive.ietf.org/arch/msg/mif/bcfrumt2vd-YU2lUL-IKSWSqt0c
It seems my subscription wasn't 100% through the first time I sent, sorry about that.


Am 22.07.2015 um 09:13 schrieb Hui Deng:
> 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]
> Cc: 
> Date: Tue, 21 Jul 2015 21:55:49 +0200
> Subject: Comments on draft-ietf-mif-mpvd-dhcp-support-01
> 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