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

From: Sheng Jiang <[email-masked]>
Date: Fri, 09 Dec 2011 06:49:58 +0000

Hi, Ran,

Thanks for your comments. They are quite helpful. See our replies in lines.

Sheng & Bing

> -----Original Message-----
> From: Ran Atkinson [mailto:[email-masked]]
> Sent: Friday, December 09, 2011 12:20 AM
> To: Brian E Carpenter
> Cc: Sheng Jiang; Randall Atkinson
> Subject: draft-liu-6renum-gap-analysis-03
> 
> Hi,
> 
> 
> The above I-D in part says in Section 6.1:
> > For DNS records update, most sites will achieve it by
> > maintaining a DNS zone file and loading this file into the
> > site's DNS server(s).  Synchronization between host renumbering
> > and the updating of its A6 or AAAA record is hard. [RFC5887]
> > mentioned that an alternative is to use Secure Dynamic DNS
> > Update [RFC3007], in which a host informs its own DNS server
> > when it receives a new address.
> 
> That description is really only true for sites that
> are using BIND as their DNS server on a UNIX server,
> including Linux.
> 
> That description, however, is NOT accurate for the
> many sites that are using a Microsoft Windows Server
> for their DNS service or are using an Apple MacOS X
> Server for their DNS service.  Many many enterprises
> use the Microsoft Windows Server for their DNS services;
> a smaller number, but still a non-trivial number,
> are using the Apple MacOS X Server for their DNS
> service.
> 
> So the quoted text above is NOT *generally* true,
> and ought to be edited and corrected either to cover
> the several different deployment models or to provide
> a description that is generally true.

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.

We do not have much knowledge for Microsoft DNS or Apple DNS. Could you point out the details how they are different from our description? If the differences are magnificent, we'd like to update our description. :)
 
> > Secure Dynamic DNS Update has been widely supported by the major
> > DNS systems, but it hasn't been widely deployed, especially in
> > the host. Current practices mainly involve the DHCP servers
> > which act as clients to request the DNS server to update
> > relevant records. Normal hosts are not suitable to do this
> > mainly because of the complexity of key management issues
> > inherited from secure DNS mechanisms.
> 
> Cricket Liu appears to disagree about the deployment claim
> above.  His O'Reilly book "DNS & BIND" reports that Microsoft
> Windows server will silently (i.e. no human involved)
> ENABLE Dynamic DNS Update in a number of situations
> (e.g. when that server has both DHCP and DNS services
> enabled or when "Active Directory" (sic) is enabled).
> 
> The combination of Microsoft Server (with DHCP and DNS
> services enabled or "Active Directory" (sic) enabled)
> with a set of Microsoft Windows clients actually is
> quite common around the world in enterprise networks.
> 
> So the claim that Secure Dynamic DNS Update is not widely
> deployed seems incorrect -- primarily because many sites
> have deployed it without realising they have done so.
> 
> I would urge that the quoted text above be edited
> with respect to that claim.

We will contact Cricket Liu for the detail (do you have his email address?) and how common this is. We will update our text accordingly.
 
> 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.
 
> 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.

Best regards,

Sheng
 
> Yours,
> Ran

---

From: Ran Atkinson <[email-masked]>
Date: Fri, 9 Dec 2011 07:55:19 -0500

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.

> 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.

> 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

---

From: Mark Andrews <[email-masked]>
Date: Sat, 10 Dec 2011 09:45:30 +1100

In message <[email-masked]>, Ran Atkinson write
> in an enterprise scenario.

Windows uses GSS-TSIG to secure the updates.

Mac OS uses TSIG to secure the updates.  You turn it on via sharing
presumable as Apple decided that you only need this if you need to
reach the machine by name.

> that the Security Considerations are known to be deficient.

With Windows you add the machine to the domain.  This is a
one off procedure and the last time I did it this it needed
a domain administrators password if my memory is correct.

Initial registration doesn't necessarially need to be standardised.
It can be ad-hoc.  Log into a web page and it can return a TSIG 
which is configured into the nameserver and the client machine.

That's done all the time to secure zone transfers.

What need to be standardised is what goes on the wire and that
was done years ago.  The rest really is implementation detail.

> _______________________________________________
> renum mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/renum
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Dec 2011 09:11:35 +1300

> In message <[email-masked]>, Ran Atkinson write

...

>> that the Security Considerations are known to be deficient.

Right, but the question is what can we say about key management
that is specific to enterprise renumbering? We can explain the
problem, but this is presumably not the WG where a solution should
be developed.

> was done years ago.  The rest really is implementation detail.

Really? It seems to me that the Windows solution will only work for
a Microsoft shop, not for a heterogeneous enterprise network.

   Brian

---

From: Mark Andrews <[email-masked]>
Date: Wed, 14 Dec 2011 12:43:22 +1100

> a Microsoft shop, not for a heterogeneous enterprise network.

If you really want a mechanism to do this then something like
this will work:

If the machine does not already have a configured TSIG (RFC 2845)
it will generate a one time public/private key pair and send the
public key along with a request for a TSIG to update the forward
zone in a DHCP request.  The DHCP server will make a TKEY (RFC 2930)
request, on behalf of the client, using its credentials to the DNS
server and return the resulting TSIG key to the client encrypting
the TSIG option response using the public key in the request.  The
returned TSIG key should be stored in non-volatile memory.

The DHCP server operates as the secure introducer to the DNS server.

One would probably want to signal if the TSIG request is for globally
or locally unique name and be able to request both.  This will allow
the host to update multiple namespaces by using the different TSIGs
Different DHCP server credentials could be used to signal this or
we could specify a TKEY option.

ULA/RFC 1918 would be private addresses and would only be addded to
the local name space.

We can do something similar for PPP.

Security considerations:

If the DHCP option is responded to by a rogue server the worst is
a denial of service attack.

The DHCP server can pretend to be the DHCP client as it has seen
the TSIG material.

---

From: "Leo Liu(bing)" <[email-masked]>
Date: Wed, 14 Dec 2011 03:03:29 +0000

Hi, Ran

Thanks for your comments. See replies inline please.

> Sent: Friday, December 09, 2011 8:55 PM
> To: Sheng Jiang
> Cc: Brian E Carpenter; Leo Liu(bing); [email-masked]
> Subject: Re: draft-liu-6renum-gap-analysis-03
> 
> 

[Bing] Our company also uses Microsoft, I think we need a brief investigation on whether it is quite common, then we can update the draft accordingly. 

> because everything is behind a common server GUI.
[Bing] If it is true, I think we can add something like "if you deploy Microsoft/apple, the DDNS issue is much easier" after the relevant gap analysis. The gap itself is still meaningful, since it is a real problem if we didn't deploy the integrated solutions like ms/apple.

> in an enterprise scenario.
[Bing] I searched his book online, but it seems it's not easy to get one in China, hope there could be Chinese version in the future :)
We can seek other relevant books/materials.

> I did.  It is not nearly clear enough.
[Bing] We can add more description.