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

Bob Hinden <> Sat, 26 June 2010 10:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 097853A6900 for <>; Sat, 26 Jun 2010 03:02:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.855
X-Spam-Status: No, score=-3.855 tagged_above=-999 required=5 tests=[AWL=1.256, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Bn4nbOlXOy4f for <>; Sat, 26 Jun 2010 03:02:42 -0700 (PDT)
Received: from (PCH.MIT.EDU []) by (Postfix) with ESMTP id 05DB13A67EB for <>; Sat, 26 Jun 2010 03:02:41 -0700 (PDT)
Received: from ( []) by (8.13.6/8.12.8) with ESMTP id o5QA2p3T021084 for <>; Sat, 26 Jun 2010 06:02:51 -0400
Received: from (MAILHUB-DMZ-2.MIT.EDU []) by (8.13.6/8.12.8) with ESMTP id o5QA2lHo021081 for <>; Sat, 26 Jun 2010 06:02:47 -0400
Received: from (DMZ-MAILSEC-SCANNER-3.MIT.EDU []) by (8.13.8/8.9.2) with ESMTP id o5QA0337011687 for <>; Sat, 26 Jun 2010 06:02:47 -0400
X-AuditID: 1209190e-b7b33ae000000a01-24-4c25d046a9a3
Received: from ( []) by (Symantec Brightmail Gateway) with SMTP id 5B.EE.02561.740D52C4; Sat, 26 Jun 2010 06:02:47 -0400 (EDT)
Received: by wwa36 with SMTP id 36so2269874wwa.36 for <>; Sat, 26 Jun 2010 03:02:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=x359I3w+Lo8pG/yVqqBmrs2qfDPbtGaJKaZTCXNHfkY=; b=nmvFIHNpGwy/NRoF1Da7PcahibZ2EToYsS0YFE5qRxMrKk8FfcK48gb+nJTbOUvQXB E7ySw0RAlDdCrxdkkOIChJgISuqYFD48AMr7u9uZujVO63wJ20pveWrILsFF/HrOg+nW o3v6cPjTnViX8NXgCtCDwSVkEc8gdIISAhJW0=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=hSHmWnNgJFYZM/qfJFtQVR6aLhkNJ4wjDhDe+VbTNujaWbJH9VWoJPlnXC8P5H0zQn Pswhc2P4ovUmNU7D9uYHYfoeG17f8ZaF8OcEtuqYmo/RDbl2cyJS6tGFmBaZhOU+IB/7 nL2InOz903VBjMDyMSycyhVI1bvlx7j2ZItAk=
Received: by with SMTP id s58mr6009529wel.60.1277546566545; Sat, 26 Jun 2010 03:02:46 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id l70sm2012419weq.0.2010. (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 26 Jun 2010 03:02:45 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1078)
From: Bob Hinden <>
In-Reply-To: <>
Date: Sat, 26 Jun 2010 06:02:40 -0400
Message-Id: <>
References: <> <> <>
To: Jari Arkko <>
X-Mailer: Apple Mail (2.1078)
X-Brightmail-Tracker: AAAAAxTf0JkU4KD1FOCzGw==
X-MIME-Autoconverted: from quoted-printable to 8bit by id o5QA2lHo021081
X-Mailman-Version: 2.1.6
Precedence: list
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 28 Jun 2010 09:50:31 -0700
Cc: 6man Chairs <>, "" <>, Bob Hinden <>, IESG <>, Jaehoon Jeong <>, "" <>
Subject: Re: [secdir] SecDir review of draft-ietf-6man-dns-options-bis-03
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 26 Jun 2010 10:02:44 -0000


Your suggested text looks good to me.


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