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

[Bob Hinden <[e-mail]>]

Jari,

Your suggested text looks good to me.

Thanks,
Bob


On Jun 26, 2010, at 5:36 AM, Jari Arkko wrote:

> Vincent,
> 
> Thank you for your review!
> 
> I have some comments on the issues that you raise below as well as some suggested new text:
> 
>> ** Section 7 "Security considerations"
>> I don't share all the ideas of the authors. If I understand the point
>> of view, the authors say that the situation is not worse than before,
>> without these DNS options.
>>  "...learning DNS information via the RA options cannot be worse than
>>   learning bad router information via the RA options."
>> 
>> Well, it depends on the security level we consider...
>> >From the point of view of the ND protocol itself, I agree. But from
>> the end user point of view, the situation is quite different, since
>> sending forged packets (for instance) and controlling which DNS server
>> is trusted by the client opens the way to, for instance, fishing
>> attacks. This attack enables an attacker to make a client use a
>> compromised DNS server that behaves perfectly except for one particular
>> DNS query. If the attacker can send an email to this client, then many
>> things can happen. This attack could be launched e.g. during next IETF
>> plenary ;-). The attacker knows the email off all participants, so if
>> he can control their DNS configuration as well, many things may
>> happen... IMHO a serious threat is introduced by this document that
>> needs to be seriously discussed.
>>  
> 
> I agree that in general the ability to redirect specific traffic instead of all traffic is an interesting attack. However, in this case the specific attack already exists in plain ND. If you want to redirect DNS server traffic to a malicious node, this can be done not just with RA DNS options, but also with ICMP Redirects or unsolicited Neighbor Advertisements.
> 
>> ** 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).
> 
>> ** 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.
> 
> All this being said I also re-read the Security Considerations section, and was not super happy with it myself. I would suggest the following change:
> 
> OLD:
> Also, an attacker could configure a host to send out
> an RA with a fraudulent RDNSS address, which is presumably an easier
> avenue of attack than becoming a rogue router and having to process
> all traffic for the subnet. It is necessary to disable the RA RDNSS
> option or DNSSL option in both routers and clients administratively
> to avoid this problem. All of this can be done independently of
> implementing ND. Therefore, it can be claimed that the RA options
> for RDNSS and DNSSL has vulnerabilities similar to those existing in
> unauthenticated DHCPv6.
> NEW:
> Also, an attacker could send
> an RA with a fraudulent RDNSS address, which is presumably an easier
> avenue of attack than becoming a rogue router and having to process
> all traffic for the subnet. 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 RDNS 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.
> 
> Jari
> 


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