Subject: Re: [dhcwg] SLAAC and DDNS

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 02 Mar 2009 11:54:01 -0500

At 06:07 28/02/2009, Ralph Droms wrote:
>I think we could use a little DNS expertise in this conversation.  The
>thread (it's not terribly long) starts at:
>
>http://www.ietf.org/mail-archive/web/dhcwg/current/msg09635.html
>
>What are your thoughts on using DHCPv6 Information-Request to update
>DNS RRs for a host that uses SLAAC?

It is real important from DNS perspective that people be clear if
the updates being requested are in the reverse tree or in a zone that
is in "forward" tree.

A random DHCP server SHOULD/MUST NOT be allowed to update in a any random
zone.
If a client wants to update its "home" name AAAA/A records it SHOULD
have a TSIG or SIG(0) relationship with its home DNS master (full stop).

The issue here is how to make it easier to create these security
relationships and maintain them.

I have been thinking about how to make this easier.
Assumption #1:
         default scope for updates of TSIG/SIG(O) transactions
         based on the name of the secret/key. (this needs to be defined)

Assumption #2:
         Trust gets established while client is on home network or 
out-of-band.

Assumption #3:
         This should be no harder than SSH trust establishment.

Outline of proposed protocol : TSIG
Client issues a TKEY request for client defined TSIG secret,
Server accepts or rejects based on its policy.
Both parties must treat this secret as a long term secret.
Based on the name of the secret the client is given authority to update a
single name in zone.
Example: client asks for TSIG with name of nn.client_name.zone
where nn is a version number.
All dynamic updates from this key are allowed to update only the
corresponding name and possibly service names below the name.

Outline of protocol: SIG(0)
Client generates an public key and has it inserted into the 'home'
zone as KEY RR.
The client signs all updates with SIG(0) and server accepts updates
to the same name as used to sign the update.

>- Ralph
>
>On Feb 27, 2009, at 11:01 AM 2/27/09, <[email-masked]> 
><[email-masked] > wrote:
>
>>There has been some discussions on the ISC DHCP mailing list about
>>folks wanting to perform DDNS in an environment where clients are
>>doing stateless address auto-config.  One solution offered is that
>>the client perform the update after it gets the DNS server(s) and
>>domain(s) from a stateless DHCPv6 server.
>>
>>I think the only drawback to this solution is that doing DDNS
>>updates from the client makes it difficult to secure the updates
>>using TSIG, for example.  Distributing the TSIG key(s) to the
>>clients is really not an option in most cases.

http://www.ietf.org/rfc/rfc2930.txt section 4.5 is the way to go and
it is not that hard to implement.
The main issue is that the client SHOULD only start this
process when on the home network.
Section 4.4 could also work but it is putting work in the wrong place,
as the server has less of a knowledge if the particular device is going
to be "mobile" or static. The server could have the policy that any
dynamic update without TSIG or SIG(0) will start a TKEY exchange before
it is accepted, but the clients need to be aware that the TKEY exchange
can start in an answer packet that rejects the dynamic update.

Buy using client assigned TSIG it requires the client to start the 
process, which is
where the burden of effort should be IMHO.

>>  However, there is
>>tremendous benefit to supporting DDNS in a SLAAC (stateless address
>>auto-config) environment.  One option would be to require client to
>>put their FQDN option in the Info-Request message sent to a
>>stateless DHCPv6 server.  The source address of the Info-Request
>>message is the client's SLAAC address, so the stateless DHCPv6
>>server would know the IP, and if the FQDN option were included, it
>>would have enough information to update both the AAAA and PTR
>>records.  The problem here is that a stateless DHCPv6 server will
>>not know when the records should be removed from DNS, but stale
>>records could be cleaned via some other "scavenging" mechanism.
>>
>>Is there any interest in this approach?  If so, I would consider
>>writing a draft to include the FQDN option in Info-Request messages.

Most DNS servers in the forward tree will not accept updates from random
entities, thus the approach is doomed.
With the approach proposed above there is no need to "scavenge" 
records as the client
can only update a single name, and in theory it can delete the 
records before it turns
off. The client that is jumping between networks (or just renumbering)
MUST remember or discover what the current registration is before 
issuing a new
dynamic update to the home DNS server and delete the old records as 
appropriate.

DNS server can have the policy that it will delete any updated RRset 
that is older than
x hours/days, forcing client to issue refresh updates each time it gets new
lease or ever so often.

         Olafur

---

From: Ralph Droms <[email-masked]>
Date: Thu, 12 Mar 2009 06:41:40 -0400

inline...

> have a TSIG or SIG(0) relationship with its home DNS master (full  

Point taken.  The DHCP service in Starbucks has no trust relationship  
with the DNS service at cisco.com.

What about the common case in which a host is attached to its "home"  
network; i.e., a network for which the DHCP service belongs to the  
same administrative domain and the DNS service for the host's domain?

And, what about the reverse zone?  Is it OK for the DHCP service in  
Starbucks to update the PTR record that belongs to Starbucks based on  
the contents of the DHCP message exchange?  Otherwise, there needs to  
be some kind of trust relationship between the host and the Starbucks  
DNS service that will be hard to scale.

> to the same name as used to sign the update.

These solutions all seem to be in DNS space.  Are any of them under  
development?

- Ralph

>> On Feb 27, 2009, at 11:01 AM 2/27/09, <[email-masked]> <[email-masked] 
>>  > wrote:
>>
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 16 Mar 2009 14:06:56 -0400

>same administrative domain and the DNS service for the host's domain?

Then it is not "random DHCP server" :-) and hopefully there is
trust relationship between the DNS and DHCP server.

>DNS service that will be hard to scale.

Yes, the reverse tree there should belong to the ISP operating
that hotspot and it can do what ever it wants:
         put in a "static" dyn-name
         put in a name supplied by the dhcp client
         not have reverse tree entry

>These solutions all seem to be in DNS space.  Are any of them under

Microsoft has a solution based on GSSAPI that works quite well
there needs to be more work done by DNS people to enable automated security
handshakes
         Olafur