Re: [renum] draft-liu-6renum-gap-analysis-03

[Ran Atkinson <[e-mail]>]

On 09  Dec 2011, at 01:49 , Sheng Jiang wrote:
> Yes, our statement above is mainly based on BIND implementations.
> We think most of DNS servers are BIND-based, 80% and above
> (unverified estimation). So, Bind itself is the majority.

BIND is quite common with ISPs and content providers, 
but Microsoft Server might well be the majority for 
*enterprise* sites.  Since this document is focused 
on renumbering situations, Microsoft Server's DNS 
might well be the majority for the renumbering situation.

Unlike UNIX deployments of BIND, which stand alone, 
Microsoft reportedly has fully integrated DNS with 
other services (e.g. DHCP, Windows Work groups) inside 
the Microsoft Windows Server.  

So reports say that there is no "flat file" with DNS entries.
Reportedly, there is also no "loading of the DNS entries".  
Instead, there is full integration of DNS with the 
other services, and things are GUI-based and systemic
for the whole deployment.

I'm told that Apple's MacOS X Server takes a very
similar approach to Microsoft Windows Server, with
integration and a GUI front-end for the whole deployment.
Apple apparently does use BIND code behind-the-scenes,
but system administrators never interact with BIND
directly and again there are no "flat files" to load
because everything is behind a common server GUI.

> We will contact Cricket Liu for the detail and
> how common this is. We will update our text accordingly.

Why not start first by reading his book (which is quite clear) ?
It is a published O'Reilly book and should be readily available.

According to the book, Microsoft Windows Server automatically
enables Dynamic DNS Update between the Windows clients and
the Windows server in a number of situations.  So deployment
of Dynamic DNS UPdate is proportional to deployments of
Microsoft Windows server, which ought to be pretty common
in an enterprise scenario.

>> In Section 10, the above draft in part says:
>>> In the LAN, Secure DHCPv6 ([I-D.ietf-dhc-secure-dhcpv6]) or
>>> SeND ([RFC3971], Secure Neighbor Discovery) deployment
>>> may need to validate prefixes.
>> 
>> 
>> If one thinks that configuring keys for Secure Dynamic
>> DNS Update is difficult or challenging, then it is
>> unavoidable to conclude that neither Secure DHCPv6
>> nor SEND are actually deployable at present.
>> 
>> I think the problems with key management deserve their
>> own subsection in Section 10 -- as a category of "gap"
>> that ought to be addressed.  That new subsection ought
>> to note the operational issues with key provisioning
>> and key management for Secure Dynamic DNS Update
>> (at least for non-MS nodes) and equally or more so
>> for Secure DHCPv6 and SEND.  One would hope these
>> would not fall into the "unsolvable gap" category,
>> but in any event these gaps do need to be clearly
>> documented.
> 
> The key management is a complicated issue. It is worth
> a separated draft. It is relevant. However, we don't
> think it is a renumbering specific issue.  We will add
> some new text for it. But we would like to leave it out of scope.

I do not think that ignoring the issue or declaring it
out-of-scope is a legitimate position to take for this
document.

IETF rules require that ALL documents must fully address
Security Considerations *within their own document*.

Ignoring that topic -- or shunting it off to other
documents -- will result in a Last Call objection from me 
and possibly others on the very solid technical grounds
that the Security Considerations are known to be deficient.

>> Similarly, there is a practical operational "gap" in
>> that we have no way to automatically update ACLs during
>> a renumbering event.  This also needs to be documented
>> as a gap.
> 
> We did list ACL as part of filter, see Section 6.3.

I did.  It is not nearly clear enough.  

More text is needed -- and since it is a Security 
Consideration it also needs to be referenced in the 
Security Considerations section of the document.

Last, it is very very rude and offensive to take any 
private email and post it to any public mailing list
without prior permission of the author -- as you
have done today.  

Yours,

Ran