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

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

Hi Fernando and Ole,
I believe that I have addresses all of the comments from 6man WG with the
following revision:
https://tools.ietf.org/html/draft-ietf-6man-rdnss-rfc6106bis-12

Could you review it and make it forward from WGLC?

Thanks.

Paul


On Mon, Mar 21, 2016 at 9:41 PM, Mr. Jaehoon Paul Jeong <
[e-mail]> wrote:

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



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