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

["Mr. Jaehoon Paul Jeong" <[e-mail]>]

Hi Fernando,
I tried to address your comments in the following draft:
https://tools.ietf.org/html/draft-ietf-6man-rdnss-rfc6106bis-08

Could you double-check whether your comments are resolved well or not?

Also, I put my answers inline with =>.

If you have some unclear parts, please let me clarify them.

Thanks.

Paul


On Wed, Feb 24, 2016 at 7:03 AM, Fernando Gont <[e-mail]>
wrote:

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

>
> * 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/?
>
>  => Agree.

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

>
> * 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".
>
>  => Augmented.

>
> * 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?
>
>  => I prefer to use DNS Repository because Recursive DNS Server List
      seems to represent only DNS Server List without DNS Search List.

>
> * 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?
>
>  => DNS Repository is used by ND and Resolver Repository is used by DNS
Resolver.

>
> * 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.
>
>  => Done.

>
> * 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?
>
>  => Agree. I replaced "any network" with "the network".

>
> * 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.
>
>  => Reflected.

>
>
> * 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?
>
>  => Yes, I mean local configuration option. I augmented the text with
"local configuration option".

>
> * 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?
>
>  => The total is three. I clarifed the text.

>
> * 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.
>
>  => Agree. I added the above I-D as a reference and augment the text to
address this fact.

>
> * 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)
>
>  => Different DNS options. I reflected the text.

>
> * 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.
>
>  => I added a solution RFC6731 that is based on DHCP. I augmented the
text with this solution.

>
> * 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?
>
>  => This is an implementation issue, so the current text does not prevent
your approach
      from being used. If you have some better text for me, please let me
know.

>
> * 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"
>
>  => I augmented the text such that a DNS name from DNSSL option uses
      an RDNSS for name resolution, which is advertised by the same RA
message.

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

 => I removed "independently of ND" for clear meaning.

>
>

> * 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.
>
>  => I replaced "RECOMMENDED" with "MAY" such that SEND can be used as a
candidate
  mitigation solution.

>
>
> ** 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.
>
>  => I mentioned RFC 6106 after RFC 5006.

>
> * 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.
>
>  => Done.

>
> * 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/
>
>  => Done.

>
> * 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/
>
>  => Done.

>
> * 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).
>
>  => Done.

>
> * Appendix A, page 17:
>
> Please remove this appendix. Such changelog is in 6106, already.
>
>  => Done.

>
> * 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 [..].
>
>  => Done. I clarified this in Expiration-time field in Section 6.1.
    ...
    Note that the DNS information for the RDNSS and DNSSL options need not
    be dropped if the expiry of the RA router lifetime happens.  This is
because
    these options have their own lifetime values.
    ...

Thanks.

Best Regards,
Paul


Thanks!
>
> Best regards,
> --
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>



-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan University
Office: [phone]
Email: [e-mail], [e-mail]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>