Re: [secdir] SecDir review of draft-ietf-6man-dns-options-bis-03

[Vincent Roca <[e-mail]>]

Dear authors,

Thanks for your prompt reply. A few additional comments
(it's my role ;-))

** new "Security Considerations" section says:
>    This attack
>    is similar to Neighbor Discovery attacks that use Redirect or
>    Neighbor Advertisement messages to redirect traffic to individual
>    addresses to malicious parties.  In general, the attacks related to
>    RDNSS and DNSSL are similar to both Neighbor Discovery attacks and
>    attacks against unauthenticated DHCP, as both can be used for both
>    "wholesale" traffic redirection and more specific attacks.
>   
You're right, other attacks are possible that lead to
the same result. ND and unauthenticated DHCP are
such possibilities. However, IMHO this is not a sufficient
reason not to RECOMMEND a security solution for RA.
Indeed, if ND / DHCP are made robust but nothing is done
for RA, then the threat remains.

So the updated text does not fully satisfies me, even if
the new paragraph is more clear than the old one.

>> ** Section 7:
>> Another point... the authors explain than network devices like
>> switches can be configured in such a way to disable ND/DHCP from
>> some ports.  That's great and I agree it helps preventing attacks.
>> However this is limited to wired networks. Nothing is said concerning
>> ND configurations in wireless networks. The situation is rather
>> different since any host can issue ND/DHCP traffic as if it were a
>> legitimate server if I understand correctly. The document MUST
>> include this kind of discussion.
>>   
>>     
> But this is generic issue with spoofing RAs and I am not sure it is the 
> task of this document to specify the solutions. One solution exists in 
> SEND (RFC 3791).
>   
Once again I agree. You don't have to specify technical
solutions. However you need to provide a good security
analysis, perhaps inherited from that of the base RA
document for the generic RA threats, with some text
describing the additional threats added by the proposed
extensions. And since security solutions exist elsewhere
(SEND), you should recommend their use. That's your
responsibility.

>> ** Section 7:
>> Yet another remark: SEND is listed as one potential solution to
>> add signatures in ND packets issued from servers.
>> I don't know SEND at all, so may be my remarks are flawed (but in
>> that case the text should be at least clarified).
>> - Shouldn't the use of SEND be RECOMMENDED as a solution to
>> mitigate attacks? Current document is not clear.
>> - Does SEND enable an authentication of the sender (the document
>> only mentions integrity protection)? If there's no sender
>> authentication, then I agree that the added value of SEND would be
>> limited. I'd like the authors to clarify this as well.
>>   
>>     
> The details are in RFC 3791 and its companion documents. SEND does 
> enable a host to verify that the sender of an RA is actually a router 
> authorized to act as a router.
>   

The text in your proposed I-D update does not
reflect this. Can you add it? Being able to authenticate
the sender is as important as being able to check the
packet integrity.

** I'm coming back to a comment I made earlier
and that has not been answered.

In the updated I-D, section 5.3.1, I read:

  "In the case where the DNS options of RDNSS and DNSSL can be obtained
   from multiple sources, such as RA and DHCP, the IPv6 host SHOULD keep
   some DNS options from all sources. "

I don't see (but I read very quickly so I may have missed
something) that secured RA/RDNSS/DNSSL messages
be prefered in the choice. If some RA use SEND, they must
be preferred over others.

I hope my comments are useful.
Cheers,

    Vincent

_______________________________________________
secdir mailing list
[e-mail]
https://mailman.mit.edu/mailman/listinfo/secdir