re: [dhcwg] dhc WG last call on "Domain Suffix Option for DHCPv6"

["CTO YAN Renxiang" <[e-mail]>]

Please see inline.

>  In your previous mail you wrote:
> 
>    I am still wondering about the issue of security. I want to say some
>    extra words to clarify.
> 
>    Suppose a case where some home devices connecte to access network
>    through a home gateway, and home gateway includes an embedding DHCP
>    server, DNS server, and DHCP client (which used to get IPv6 prefix and
>    "domain suffix" from access gateway, i.e. BRAS).
> 
> => you should split the update issue into direct tree and reverse tree updates:
>  - for the direct tree there is no need at all to use a "domain
>    suffix" related to the ISP, so the home network can (should!) be
>    made autonomous and obviously the DHPC client on the home gateway
>    can only use the "domain prefix" for the name of its interface to
>    the ISP... a very marginal issue.
>  - for the reverse tree its base can be derived from the delegated
>    prefix so I don't understand what is the "domain suffix" for
>    in this context.
> So I can't see any security issue.
> 
>    The DNS update security issues may exist in the following 
> procedures:
>    
>    (1) DHCP server in home gateway perform DNS update to 
> local DNS server
> 
> => what is the local DNS server?

Local DNS server is the DNS server in home gateway.  

> 
>    for home devices using FQDNv6 option. The security issues has been
>    mentioned in FQDNv6 option, as follows,
>      
>       Unauthenticated updates to the DNS can lead to 
> tremendous confusion,
>       through malicious attack or through inadvertent 
> misconfiguration.
>       Administrators should be wary of permitting unsecured 
> DNS updates to
>       zones which are exposed to the global Internet.  Both 
> DHCPv6 clients
>       and servers SHOULD use some form of update request origin
>       authentication procedure (e.g., Secure DNS Dynamic 
> Update [10]) when
>       performing DNS updates.
>    
> => but the FQDNv6 option has nothing to do with dynamic DNS updates
> so this text should be removed.

I meant FQDNv6 option is used to update DNS with the associated AAAA and PTR RRs
for DHCPv6 clients.

> 
>    (2) In order to "link" two DNS server, home gateway's DNS 
> server and Up-level DNS server,
> 
> => why do you want to link them? Delegation of prefixes and delegation
> of direct domains have only in common the word "delegation"!

I am not expert in DNS, I meant to said, to make hosts in home network be accessed
using Domain name from outside network, we need to add a NS record in ISP's DNS
server for the DNS server in home gateway.

 
>    home gateway need to perform DNS update to up-level
>    DNS server by adding a NS record in it. There DOES exist 
> security issue
>    here. This can be solved using different way. I prefer it 
> piggybacked by
>    DHCP session between home gateway and access node, beacuse 
> DHCP session
>    is secure, home gateway should be authenticated before (or 
> along with)
>    initating DHCP session.
>    
> => two (other) comments:
>  - you can't create a zone with a dynamic DNS update
>  - DHCP is not the right tool to perform any authentication in this
>    context, the authentication is done by the NAS and DHCP 
> relies on this
>    using a mix of:
>     draft-ietf-dhc-v6-relay-radius-01.txt
>     draft-salowey-radext-delegated-prefix-01.txt
>     draft-droms-dhc-dhcpv6-agentopt-delegate-00.txt

Thanks, I'll digest these draft. I believe it's helpful for me in writing another draft on 
how to use the domain suffix option.

Anyway, I think the "DNS update" issues is resolved by now. I'll update the draft and
request for another WGLC.


> Regards
> 
> [e-mail]
> 

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg