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

Yes. I will be reviewing evrything and preparing the proto writeup no later
than tomorrow.

Thanks!
Fernando

El 7/4/2016 9:59, "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
escribió:

> 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 <
> jaehoon.paul@gmail.com> 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 <
>> achatz@forthnet.gr> wrote:
>>
>>> otroan@employees.org 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
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>>
>>
>>
>> --
>> ===========================
>> Mr. Jaehoon (Paul) Jeong, Ph.D.
>> Assistant Professor
>> Department of Software
>> Sungkyunkwan University
>> Office: +82-31-299-4957
>> Email: jaehoon.paul@gmail.com, pauljeong@skku.edu
>> 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: +82-31-299-4957
> Email: jaehoon.paul@gmail.com, pauljeong@skku.edu
> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
> <http://cpslab.skku.edu/people-jaehoon-jeong.php>
>