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

Vincent Roca <> Sat, 03 July 2010 13:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 276513A6844 for <>; Sat, 3 Jul 2010 06:03:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.204
X-Spam-Status: No, score=-4.204 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6SLB3xn0DtiA for <>; Sat, 3 Jul 2010 06:03:56 -0700 (PDT)
Received: from (PCH.MIT.EDU []) by (Postfix) with ESMTP id 121373A67FC for <>; Sat, 3 Jul 2010 06:03:55 -0700 (PDT)
Received: from ( []) by (8.13.6/8.12.8) with ESMTP id o63D46od014430 for <>; Sat, 3 Jul 2010 09:04:06 -0400
Received: from (MAILHUB-DMZ-2.MIT.EDU []) by (8.13.6/8.12.8) with ESMTP id o63D44TU014427 for <>; Sat, 3 Jul 2010 09:04:04 -0400
Received: from (DMZ-MAILSEC-SCANNER-7.MIT.EDU []) by (8.13.8/8.9.2) with ESMTP id o63D43SA001633 for <>; Sat, 3 Jul 2010 09:04:04 -0400
X-AuditID: 12074424-b7b63ae000000a0b-78-4c2f35439c2d
Received: from ( []) by (Symantec Brightmail Gateway) with SMTP id 58.F7.02571.3453F2C4; Sat, 3 Jul 2010 09:04:03 -0400 (EDT)
X-IronPort-AV: E=Sophos;i="4.53,530,1272837600"; d="scan'208";a="62666158"
Received: from (HELO macbook-pro-de-roca.local) ([]) by with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 03 Jul 2010 15:04:01 +0200
Message-ID: <>
Date: Sat, 03 Jul 2010 15:04:01 +0200
From: Vincent Roca <>
Organization: INRIA
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv: Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Jaehoon Jeong <>
References: <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.0.1
X-Brightmail-Tracker: AAAAAhTzSz4U9B3E
X-Mailman-Version: 2.1.6
Precedence: list
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: 6man Chairs <>, "" <>, Jari Arkko <>, IESG <>, "" <>
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, 03 Jul 2010 13:03:57 -0000

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

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


secdir mailing list