Review of draft-ietf-6man-rdnss-rfc6106bis-06

[Fernando Gont <[e-mail]>]

Folks,

Below you'll find a detailed review of this document. (I would be great
if, besides the authors, other folks could comment on the technical
issues raised below)


** Technical **

* Section 1, page 3:
> Most Internet services are
>    identified by using a DNS name.  The two RA options defined in this
>    document provide the DNS information needed for an IPv6 host to reach
>    Internet services.

I'd not use the term "services" here, but rather use "names" in the
first instance, and possible "servers" in the second one.


* Section 1, page 3:
> For instance, locally defined name
>    spaces would not be available to the host if it were to run its own
>    name server software directly connected to the global DNS.

s/name server software/recursive name server/?


* Section 1, page 3:
>  The DNS information can also be provided through DHCP [RFC3315]
> [RFC3736][RFC3646].

s/DHCP/DHCPv6/


* Section 3, page 4:
> 
>    o  Recursive DNS Server (RDNSS): Server that provides a recursive DNS
>       resolution service for translating domain names into IP addresses
>       as defined in [RFC1034] and [RFC1035].

Not sure if you should augment this definition, as e.g. resolving PTR
records is not about "mapping names into IP addresses".


* Section 3, page 5:
> 
>    o  DNS Repository: Two data structures for managing DNS Configuration
>       Information in the IPv6 protocol stack in addition to Neighbor
>       Cache and Destination Cache for Neighbor Discovery [RFC4861].  The
>       first data structure is the DNS Server List for RDNSS addresses
>       and the second is the DNS Search List for DNS search domain names.

Maybe call this structure "Recursive DNS Server List" instead?


* Section 3, page 5:
> 
>    o  DNS Repository: Two data structures for managing DNS Configuration
>       Information in the IPv6 protocol stack in addition to Neighbor
>       Cache and Destination Cache for Neighbor Discovery [RFC4861].  The
>       first data structure is the DNS Server List for RDNSS addresses
>       and the second is the DNS Search List for DNS search domain names.
> 
>    o  Resolver Repository: Configuration repository with RDNSS addresses
>       and a DNS Search List that a DNS resolver on the host uses for DNS
>       name resolution; for example, the Unix resolver file (i.e., /etc/
>       resolv.conf) and Windows registry.


The difference between these two is not clear. Is the only difference
that the later is maintained in persistent storage, or what?


* Section 4, page 5:
> 
>    This document standardizes the ND option called the RDNSS option
>    defined in [RFC5006] that contains the addresses of recursive DNS
>    servers.

This text is confusing. Advice: Do not mention RFC5006 other than in the
intro.


* Section 4, page 5:
>  The
>    RA options for RDNSS and DNSSL can be used on any network that
>    supports the use of ND.

mmm... isn't ND mandatory, anyway?


* Section 5.3.1, page 8:
>    o  The validity of DNS options is checked with the Length field; that
>       is, the value of the Length field in the RDNSS option is greater
>       than or equal to the minimum value (3), and the value of the
>       Length field in the DNSSL option is greater than or equal to the
>       minimum value (2).

The RDNSS option should have an additional validation check:
(Length -1) % 2 == 0

Additionally, you should validate the addresses: e.g., they should be
unicast addresses.



* Section 5.3.1, page 9:
> Unless explicitly specified for
>    the discovery mechanism, the exact number of addresses and domain
>    names to keep is a matter of local policy and implementation choice.

Are you referring to some local configuration option, or something else?


* Section 5.3.1, page 9:
> However, the ability to store at least three RDNSS addresses (or
>    DNSSL domain names) from at least two different sources is
>    RECOMMENDED.

If there are two sources, this would mean e.g., a total of 6 addresses?
Or a total of three?


* Section 5.3.2, page 9:
> Therefore,
>    the network administrator needs to configure DNS options in multiple
>    sources in order to prevent such problems from happening.

As per draft-ietf-v6ops-dhcpv6-slaac-problem, this may not be enough.


* Section 5.3.2, page 9:
> Therefore,
>    the network administrator needs to configure DNS options in multiple
>    sources in order to prevent such problems from happening.

You mean configure *the same* info in all sources, or something else?
(it's not clear)


* Section 5.3.2, page 9:
> 
>    Second, if different DNS information is provided on different network
>    interfaces, this can lead to inconsistent behavior.  The IETF is
>    working on solving this problem for both DNS and other information
>    obtained by multiple interfaces [MIF-PROBLEM][MIF-PRACTICE].

Without checking [MIF-PROBLEM][MIF-PRACTICE], how about mitigating this
issue a bit by maintaining per-interface configuration -- e.g., if you
receive DNS information in each of your interfaces, you keep such info
on a per-interface basis rather than on a global/system-wide basis.


* Section 6, pages 9-10
>    For the
>    synchronization, an implementation where ND works in the kernel
>    should provide a write operation for updating DNS information from
>    the kernel to the Resolver Repository.

Why not just have a lib/syscall that allows you to read it from
userspace, rather than have the kernel write to userspace?


* Section 6.1, page 10:
>    o  DNSSL domain name for DNS Search List: DNS suffix domain names,
>       which are used to perform DNS query searches for short,
>       unqualified domain names in the network advertising the DNSSL
>       option.

What if you receive the RDNSS on one interface, and the DNSSL on
another? -- put another way, not sure what you mean by "in the network
advertising the DNSSL option"


* Section 7.1, page 13:
> Therefore, the vulnerability
>    of ND is not worse and is a subset of the attacks that any node
>    attached to a LAN can do independently of ND.

Not sure what you mean by "...independently of ND".



* Section 7.2, page 14:
Here you're making recommendations with RFC2119. I recommend you don't.

One one hand, SEND is extremely hard to deploy (if at all possible). A
number of popular OSes don't support it, it requires a PKI, etc., etc.

Besides, all these are operational mitigations, and your document is a
Std Track document.

So my recommendation would be: discuss possible mitigations, reference
the appropriate RFCs, but do not make any RFC2119 recommendations about
this.




** Editorial **

* Section 1, page 3:
>    The purpose of this document is to standardize an IPv6 Router
>    Advertisement (RA) option for DNS Recursive Server Addresses used for
>    the DNS name resolution in IPv6 hosts.  This RA option was originally
>    specified in an earlier Experimental specification [RFC5006]. 

You should note that it was later published as Std Track in RFC6106 --
this is not explicitly noted otherwise.


* Section 1, page 3:
>    Neighbor Discovery (ND) for IP version 6 and IPv6 stateless address
>    autoconfiguration 

Please capitalize SLAAC  -- each word, and then add the acronymn.


* Section 1.2, page 4:
> 
>    Two protocols exist to configure the DNS information on a host, the
>    Router Advertisement options described in this document and the
>    DHCPv6 options described in [RFC3646].

s/described/specified/


* Section 3, page 4:
>    This document uses the terminology described in [RFC4861] and
>    [RFC4862].  In addition, four new terms are defined below:

s/described/defined/


* Section 6.1, page 10:
> When Expiration-time becomes less than the current system
>       time, this entry is regarded as expired.

Probably just me being pedantic, but I'd phrase it as "when the current
time becomes larger than..." (it's the current time that changes, rather
than the expiration time).


* Appendix A, page 17:

Please remove this appendix. Such changelog is in 6106, already.


* Appendix B, page 18:
> 
>    o  The lifetimes of RDNSS and DNSSL options are decoupled from Router
>       Lifetime.  An RA router lifetime of zero does not cause the RDNSS
>       and DNSSL options to be considered invalid because these options
>       have their own lifetime values.  Thus, due to the expiry of the RA
>       router lifetime, the lists in the RDNSS and DNSSL options are not
>       guaranteed to be reachable at any point in time.

While you have removed the corresponding text, I think this deserves a
clarification in the body of the document. i.e., clarify that the DNS
info need not be dropped if [..].

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492