Mark Andrews <marka@isc.org> writes:
That said it is possible to completely automate the secure assignment of PTR records. It is also possible to completely automate the secure delegation of the reverse name space. See http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00
I like that. I'd really like to see CPE vendors implementing it. AFAICT, it is perfectly possible to apply that on top of the idea you had about letting TCP clients update their own key. CPEs supporting the DHCPv6 option will use that, while the others still have the ability to add a KEY record from a TCP client in the deletated prefix. As long as you let TSIG signed updates trump anything and do not allow unsigned updates if there is a KEY, then these should work just fine together. But I believe the draft could use a couple of clarifications to avoid interpretation bugs: CPE generates DHCPv6 Prefix Delegation [RFC3633] request which includes a KEY-RDATA option (code point TBA) which contains a the rdata of a DNS KEY record containing a RSASHA256 key using the public components of the previously generated RSA key pair. Is this new DHCPv6 option to be placed under OPTION_IA_PD, or is it a "top level" option? I.e. will it be possible to set different keys for (the theoretical) multi-prefix requests? We've already seen confusion wrt placement of the OPTION_DNS_SERVERS, so it is important to explicitly state where such options, which may be considered local to part of the DHCPv6 message, belong. I do know that RFC3315 is clear on the default: Unless otherwise noted, each option may appear only in the options area of a DHCP message and may appear only once. But experience with OPTION_DNS_SERVERS has shown that this is not enough. Pleace be explicit about where in the packet any new DHCPv6 options belong. CPE device generates DNS UPDATE [RFC2136] which delegates the reverse name space to itself and others if they have been configured. The CPE uses SIG(0) [RFC2931] to sign the request with owner name matching the reverse of the delegated prefix. This could use a few examples and clarifications wrt the owner name. I interpret it as: IA_PD = 2001:db8:1::/48 => owner name = 1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa But what about for example IA_PD = 2001:db8:2:4::/62 ? Are you going to add multiple owner names, or should there be some rule here allowing multiple delegations with a single owner name for PD on non-nibble boundaries? For example IA_PD = 2001:db8:2:4::/62 => owner name = 4.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa allowed to update: 4.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa 5.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa 6.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa 7.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa (not that I would ever consider delegating prefixes on anything but nibble boundaries, but someone else might - and the draft should consider this possibility) Bjørn