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

[Jari Arkko <[e-mail]>]

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