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

From: Vincent Roca <[email-masked]>
Date: Fri, 25 Jun 2010 13:06:02 +0200

Dear All,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

IMHO current proposal generates additional security threats,
as explained below:

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

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

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

** Section 7:
Finally, I have the feeling that the text describing the two attacks
in first paragraph (i.e. (1) pretend to be the legitimate server by
fooling the switch, and (2) simply send RA packets) should be
improved. The authors may say explicitly they consider two ND attacks
(in order to show that an attack is feasible and easy if no counter
measure is taken), and then describe them in specific bullets. The
current description of (1) also says that this attack can be used
to "tell the hosts to send their traffic somewhere else." I agree but
we need to focus here on attacks that target DNS, not the client
routing part. It adds some confusion to the text

** Section 5.3.1 "Procedure of DNS configuration"
In the DNS option processing, it's probably worth mentioning that
the RDNSS/DNSSL lifetime entries MUST be carefully checked.
Otherwise an attacker can easily send RA with very short lifetimes
to make legitimate DNS entries quickly timeout in a client and
replace them with his own entries that point to a corrupted
DNS server. This raises another question: can an existing entry
be revised before its expiration? In current text, I read:
  "If the DNS options are valid, the host SHOULD copy the values of
   the options into the DNS Repository and the Resolver
   Repository..."
Copy is automatic once the option is validated. It's perhaps too
permissive.

** Section 5.3.1 "Procedure of DNS configuration"
It is said that:
  "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 can keep some DNS options from RA and some from DHCP..."
Well, this strategy is a little bit strange. Why should it be so and
not something else? If the use of solution 1 is more secure than
solution 2, then the document should say that solution 1 is
RECOMMENDED. This is not the case for the moment.

Also what happens if several ND servers send RA with different DNS
options (e.g. one is sent by a valid ND server and the other one
by the attacker)? This is not considered in the above paragraph.

I hope these comments will be useful in improving the document.
Best regards,

    Vincent

---

From: Jari Arkko <[email-masked]>
Date: Sat, 26 Jun 2010 12:36:06 +0300

Vincent,

Thank you for your review!

I have some comments on the issues that you raise below as well as some 

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

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

> 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
[email-masked]
https://mailman.mit.edu/mailman/listinfo/secdir

---

From: Jaehoon Jeong <[email-masked]>
Date: Sat, 26 Jun 2010 21:29:03 -0600

Hi Vincent,
I updated the security considerations section with Jari's suggest text as follows.

   Also, this attack can send redirects that tell the hosts to send their traffic somewhere else.
   The malicious node can send unsolicited RA or Neighbor Advertisement
   (NA) replies, answer RS or Neighbor Solicitation (NS) requests, etc.
   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
   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.

The revised I-D is located at the following link:
http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/draft-ietf-6man-dns-options-bis-04.txt

The difference between 03-version and 04-version is located:
http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/wdiff%20draft-ietf-6man-dns-options-bis-03_txt%20draft-ietf-6man-dns-options-bis-04_txt.htm

I believe that Jari addressed your questions and comments.

Could you confirm whether this update is fine with you?

Thanks.

Best Regards,
Paul

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]] 
Sent: Saturday, June 26, 2010 4:36 AM
To: Vincent Roca
Cc: Jaehoon Jeong; [email-masked]; [email-masked]; IESG; 6man Chairs
Subject: Re: SecDir review of draft-ietf-6man-dns-options-bis-03

Vincent,

OLD:

Jari

---

From: Bob Hinden <[email-masked]>
Date: Sat, 26 Jun 2010 06:02:40 -0400

Jari,

Your suggested text looks good to me.

Thanks,
Bob

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

> I have some comments on the issues that you raise below as well as some suggested new text:
> 
> 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:
> 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:
> 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: