Re: 6MAN Working group last call: draft-ietf-6man-rdnss-rfc6106bis

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

Hi Tassos,
Thanks for your comments.
I put my answers inline below with "=>".

On Fri, Mar 18, 2016 at 6:38 PM, Tassos Chatzithomaoglou <[e-mail]
> wrote:

> [e-mail] wrote on 18/3/2016 10:44 πμ:
> > Paul,
> >
> >> I took a look at the draft of
> https://www.ietf.org/id/draft-ietf-v6ops-dhcpv6-slaac-problem-06.txt.
> >>
> >> From Case 4 (all RA flags are set, that is, M=1, A=1, O=1) in A.2.2,
> >> Fedora 21 and Centos 7 let the DNS of the RAs have higher priority, but
> >> MAC OS-X lets the DNS of DHCPv6 have higher priority.
> >> In the current implementations, there is no consistency to handle RDNSS
> options from RA and DHCPv6.
> >>
> >> Thus, I suggest the following text with the preference for DHCPv6
> because
> >> there is no a stong rationale, but there must be somehow a guidance to
> handle this case:
> >>
> >> The DNS options from Router Advertisements and DHCP SHOULD be
> >> stored into the DNS Repository and Resolver Repository so that
> >> information from DHCP appears there first and therefore takes
> >> precedence. This document recommends that the DNS information
> >> from DHCP should have higher priority than that of RA for
> >> DNS queries to handle the case of the coexistence of RA and DHCP.
> >>
> >> If anyone does not object this text, I will revise the draft with it.
> > I would prefer this document focused solely on specifying the RA DNS
> options, and did not stray into more general configuration complexity.
> >
> > getting information from multiple sources is a more general problem in
> IPv6, and I don't want us to "solve" (if that's possible) that problem in
> this document.
> >
> > "the less you say, the less likely you are to say something wrong". ;-)
> >
> > Best regards,
> > Ole
> >
> So we leave the DHCP/RA preference choice to the implementers?
>
 => Since this issue  is not standardized yet, we will leave it to the
implementers.


>
> Something else that doesn't seem ok to me.
> > However, the security of these RA options for DNS configuration does
> >    not affect ND protocol security [RFC4861].  This is because learning
> >    DNS information via the RA options cannot be worse than learning bad
> >    router information via the RA options.  Therefore, the vulnerability
> >    of ND is not worse and is a subset of the attacks that any node
> >    attached to a LAN can do.
>
> I do not agree with the statement "learning DNS information via the RA
> options cannot be worse than learning bad router information via the RA
> options".
> I believe that bad router exploitation is at a local level, while bad
> DNS exploitation is at a global level. So while the origin of the attack
> can be the same (a node attached to the LAN), the easiness/effectiveness
> of the attack can be greater in the case of DNS.
>
>  => By the invalid RDNSS addresses, the DNS query messages from
      IPv6 hosts can be generated and sent toward those addresses over the
link
      to which the hosts are attached. However, in the aspect of IPv6
hosts,
      the vulnerability level for ND service seems still the same.


>
> Also, i have spotted a few more places for further clarification:
>
> > Step (c): For each RDNSS address, if it already exists in the DNS
> >       Server List, then...
>
> Step (c): For each RDNSS address, if it already exists in the DNS
>       Server List and the RDNSS option's Lifetime field is not set to
> zero, then....
>
>  => This clarification looks good. I will reflect this in the revision.


> > Step (d): For each RDNSS address, if it does not exist in the DNS
> >       Server List, register the RDNSS address and Lifetime with the DNS
> >       Server List and then insert the RDNSS address in front of the
> >       Resolver Repository.
>
> ...and then insert the RDNSS address as the first one in the Resolver
> Repository.
>
>   => This clarification looks good, too. I will reflect this in the
revision.


 Thanks.

 Best Regards,
 Paul


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