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

Vincent Roca <vincent.roca@inrialpes.fr> Thu, 22 July 2010 12:37 UTC

Return-Path: <secdir-bounces@mit.edu>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AAAF3A68B9 for <secdir@core3.amsl.com>; Thu, 22 Jul 2010 05:37:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.563
X-Spam-Level:
X-Spam-Status: No, score=-6.563 tagged_above=-999 required=5 tests=[AWL=-0.314, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMd9ODpFkcqi for <secdir@core3.amsl.com>; Thu, 22 Jul 2010 05:37:12 -0700 (PDT)
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id DA4693A67EA for <secdir@ietf.org>; Thu, 22 Jul 2010 05:37:00 -0700 (PDT)
Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o6MCbGZW030670 for <secdir@ietf.org>; Thu, 22 Jul 2010 08:37:16 -0400
Received: from mailhub-dmz-4.mit.edu (MAILHUB-DMZ-4.MIT.EDU [18.7.62.38]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o6MCbCCQ030657 for <secdir@PCH.mit.edu>; Thu, 22 Jul 2010 08:37:13 -0400
Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by mailhub-dmz-4.mit.edu (8.13.8/8.9.2) with ESMTP id o6MCb26n031938 for <secdir@mit.edu>; Thu, 22 Jul 2010 08:37:12 -0400
X-AuditID: 1209190d-b7c82ae000000a16-a6-4c483b787589
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by dmz-mailsec-scanner-2.mit.edu (Symantec Brightmail Gateway) with SMTP id 79.B6.02582.97B384C4; Thu, 22 Jul 2010 08:37:14 -0400 (EDT)
X-IronPort-AV: E=Sophos;i="4.55,243,1278280800"; d="scan'208";a="64270214"
Received: from zmbs1.inria.fr ([128.93.142.14]) by mail1-relais-roc.national.inria.fr with ESMTP; 22 Jul 2010 14:37:10 +0200
Date: Thu, 22 Jul 2010 14:36:08 +0200
From: Vincent Roca <vincent.roca@inrialpes.fr>
To: Jaehoon Jeong <pjeong@Brocade.com>
Message-ID: <1655704977.54.1279802168445.JavaMail.root@zmbs1.inria.fr>
In-Reply-To: <F3BA781F50E6CF40BE424085EA902DE397EBE715A0@BRM-EXCH-3.corp.brocade.com>
MIME-Version: 1.0
X-Originating-IP: [194.199.24.116]
X-Mailer: Zimbra 6.0.7_GA_2470.RHEL5_64 (ZimbraWebClient - SAF3 (Mac)/6.0.7_GA_2470.RHEL5_64)
X-Brightmail-Tracker: AAAAAhVGFDQVRuR3
X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id o6MCbCCQ030657
X-BeenThere: secdir@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: secdir-bounces@mit.edu
Errors-To: secdir-bounces@mit.edu
Cc: 6man Chairs <6man-chairs@tools.ietf.org>, Tony Cheneau <tony.cheneau@it-sudparis.eu>, secdir@mit.edu, Jari Arkko <jari.arkko@piuha.net>, IESG <iesg@ietf.org>, draft-ietf-6man-dns-options-bis all <draft-ietf-6man-dns-options-bis.all@tools.ietf.org>
Subject: Re: [secdir] SecDir review of draft-ietf-6man-dns-options-bis-03
X-BeenThere: secdir@ietf.org
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Jul 2010 12:37:14 -0000

Hello Paul,

I'm okay with the new text :-)
I've just found a  typo (section 7, 2nd line): s/secuity/security/

Regards,

   Vincent


----- Original Message -----
> From: "Jaehoon Jeong" <pjeong@Brocade.com>
> To: "Vincent Roca" <vincent.roca@inrialpes.fr>
> Cc: "draft-ietf-6man-dns-options-bis all" <draft-ietf-6man-dns-options-bis.all@tools.ietf.org>, secdir@mit.edu, "IESG"
> <iesg@ietf.org>, "6man Chairs" <6man-chairs@tools.ietf.org>, "Jari Arkko" <jari.arkko@piuha.net>, "Tony Cheneau"
> <tony.cheneau@it-sudparis.eu>
> Sent: Thursday, July 22, 2010 12:53:38 AM
> Subject: RE: SecDir review of draft-ietf-6man-dns-options-bis-03
> Hi Vincent,
> I updated the document according to your guidelines as follows:
> - The new ID:
> http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/draft-ietf-6man-dns-options-bis-07.txt
> 
> - Difference between 06-version and 07-version:
> http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/wdiff%20draft-ietf-6man-dns-options-bis-06_txt%20draft-ietf-6man-dns-options-bis-07_txt.htm
> 
> Tony Cheneau provided the text about DNS option authorization as
> below:
> -----------------------------------------------------------------------
> I agree that currently SEND does not provide any mechanism
> to indicate if a router can or cannot insert RDNSS and DNSSL options.
> However, I think the document draft-ietf-csi-send-cert-05 could help
> with that issue. The section 7 of the document describes
> Extended Key Usage for the certificate deployed in SEND.
> While it currently defines roles for Routers, Routers acting as Proxy
> and
> Address Owner, I think it could be extended to a new usage
> that indicates that the Router was indeed authorized
> to insert RDNSS and DNSSL options.
> -----------------------------------------------------------------------
> 
> I reflected his comments on this update.
> 
> Could you check whether this update is fine to you or not?
> 
> If it is fine to you, I will submit it to the IETF repository.
> 
> Thanks.
> 
> Best Regards,
> Paul
> 
> 
> -----Original Message-----
> From: Vincent Roca [mailto:vincent.roca@inrialpes.fr]
> Sent: Tuesday, July 20, 2010 5:24 AM
> To: Jaehoon Jeong
> Cc: draft-ietf-6man-dns-options-bis all; secdir@mit.edu; IESG; 6man
> Chairs; Jari Arkko
> Subject: Re: SecDir review of draft-ietf-6man-dns-options-bis-03
> 
> Dear authors,
> 
> First of all, sorry for this late answer.
> 
> Otherwise I read -06 version and I'm now happy with modifications made
> in Section 5.3.
> 
> Concerning Section 7 "Security Considerations", I still find the
> current text confusing (sorry):
> 
> - there is no clear discussion of what are the additional
> threats specific to the proposed RDNSS/DNSSL.
> Instead I see a discussion explaining that the situation is
> not worse than before because an attacker can launch other
> types of attacks on ND. You're right and you can mention this
> quickly, but do not limit yourself to such a discussion.
> 
> - the new text on SEND is much better. However there is no
> explicit recommendation (no RECOMMENDED/SHOULD keyword).
> How should I understand this? Is it deliberate? Why?
> 
> 
> So I suggest that you add two subsections (with a suggested
> structure):
> 7.1. Security threats
> <specific attacks on RDNSS/DNSSL>
> <how to launch them (rogue router or forged packets)>
> <in fact the situation is not worse than ND or DHCP
> attacks>
> 7.2. Recommendations
> <port filtering in case of wired networks is RECOMMENDED>
> <mitigation at the DNS resolver is RECOMMENDED>
> <SEND is RECOMMENDED>
> 
> NB: In paragraph discussing filtering on switches:
> "is recommended" -> "is RECOMMENDED"
> 
> NB2: I wouldn't like to give you the feeling that I set myself against
> you, this is not my goal.
> 
> 
> Cheers,
> 
> Vincent
> 
> 
> ----- Original Message -----
> > From: "Jaehoon Jeong" <pjeong@Brocade.com>
> > To: "Jari Arkko" <jari.arkko@piuha.net>
> > Cc: "Vincent Roca" <vincent.roca@inrialpes.fr>,
> > "draft-ietf-6man-dns-options-bis all"
> > <draft-ietf-6man-dns-options-bis.all@tools.ietf.org>,
> > secdir@mit.edu, "IESG" <iesg@ietf.org>, "6man Chairs"
> > <6man-chairs@tools.ietf.org>
> > Sent: Tuesday, July 6, 2010 4:37:06 PM
> > Subject: RE: SecDir review of draft-ietf-6man-dns-options-bis-03
> > Hi Jari,
> > Is this update fine to you along with Section 5.3.2 (Warnings for
> > DNS
> > Options Configuration)?
> >
> > The difference between 05-version and 06-version is located at:
> > http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/w
> > diff%20draft-ietf-6man-dns-options-bis-05_txt%20draft-ietf-6man-dns-op
> > tions-bis-06_txt.htm
> >
> > If so, I will submit the version 06-ID today.
> >
> > Thanks.
> >
> > Best Regards,
> > Paul
> >
> > -----Original Message-----
> > From: Jaehoon Jeong [mailto:pjeong@Brocade.com]
> > Sent: Saturday, July 03, 2010 12:33 PM
> > To: Vincent Roca
> > Cc: Jari Arkko; draft-ietf-6man-dns-options-bis.all@tools.ietf.org;
> > secdir@mit.edu; IESG; 6man Chairs
> > Subject: RE: SecDir review of draft-ietf-6man-dns-options-bis-03
> >
> > Hi Vincent,
> > I would like to address your comments as below.
> >
> > The updated I-D is located in the following link:
> > http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/d
> > raft-ietf-6man-dns-options-bis-06.txt
> >
> > On Sat, Jul 3, 2010 at 11:31 AM, Jaehoon Jeong <pjeong@brocade.com>
> > wrote:
> > >
> > >
> > > -----Original Message-----
> > > From: Vincent Roca [mailto:vincent.roca@inrialpes.fr]
> > > Sent: Saturday, July 03, 2010 8:04 AM
> > > To: Jaehoon Jeong
> > > Cc: Jari Arkko;
> > > draft-ietf-6man-dns-options-bis.all@tools.ietf.org;
> > > secdir@mit.edu; IESG; 6man Chairs; vincent.roca@inrialpes.fr
> > > Subject: Re: SecDir review of draft-ietf-6man-dns-options-bis-03
> > >
> > > 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.
> >
> > I reorganize the text such that the description for SEND (as a
> > security solution for RA) follows the above paragraph:
> > ...
> > 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.
> >
> > If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used
> > as
> > a security mechanism for ND, all the ND options including the RDNSS
> > and DNSSL options are automatically included in the signatures, so
> > the
> > transport for the RA options is integrity-protected; that is, SEND
> > can
> > prevent the spoofing of these DNS options with signatures.
> > Also, SEND enables an IPv6 host to verify that the sender of an RA
> > is
> > actually a router authorized to act as a router. However, since any
> > valid SEND router can still insert RDNSS and DNSSL options, SEND
> > cannot verify which one is or is not authorized to send the options.
> >
> > >
> > >>> ** 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
> > > responsibility.
> >
> > In the following paragraph, we address that SEND can prevent such RA
> > DNS option spoofing:
> >
> > If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used
> > as
> > a security mechanism for ND, all the ND options including the RDNSS
> > and DNSSL options are automatically included in the signatures, so
> > the
> > transport for the RA options is integrity-protected; that is, SEND
> > can
> > prevent the spoofing of these DNS options with signatures.
> > Also, SEND enables an IPv6 host to verify that the sender of an RA
> > is
> > actually a router authorized to act as a router. However, since any
> > valid SEND router can still insert RDNSS and DNSSL options, SEND
> > cannot verify which one is or is not authorized to send the options.
> >
> > >
> > >>> ** 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.
> >
> > According to the comments, the checking for valid router is
> > mentioned
> > in the middle:
> >
> > If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used
> > as
> > a security mechanism for ND, all the ND options including the RDNSS
> > and DNSSL options are automatically included in the signatures, so
> > the transport for the RA options is integrity-protected; that is,
> > SEND can prevent the spoofing of these DNS options with signatures.
> > Also, SEND enables an IPv6 host to verify that the sender of an RA
> > is
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > actually a router authorized to act as a router. However, since any
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > valid SEND router can still insert RDNSS and DNSSL options, SEND
> > cannot verify which one is or is not authorized to send the options.
> >
> > >
> > > ** 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 preferred in
> > > the
> > > choice. If some RA use SEND, they must be preferred over others.
> > >
> >
> > In Section 5.3.1, the considerations on SEND is mentioned as
> > follows:
> >
> > 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. Unless explicitly specified for
> > the discovery mechanism, the exact number of addresses and domain
> > names to keep is a matter of local policy and implementation choice.
> > However, it is RECOMMENDED that at least three RDNSS addresses (or
> > DNSSL domain names) can be stored from at least two different
> > sources. The DNS options from Router Advertisements and DHCP SHOULD
> > be stored into DNS Repository and Resolver Repository so that
> > information from DHCP appears there first and therefore takes
> > precedence. Thus, the DNS information from DHCP takes precedence
> > over that from RA for DNS queries. On the other hand, for DNS
> > ^^^^^^^^^^^^^^^^^^^^^^^^^
> > options announced by RA, if some RAs use the Secure Neighbor
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > Discovery (SEND) protocol [RFC3971] for RA security, they MUST be
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > preferred over those which do not use SEND. Refer to Section 7 for
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > the detailed discussion on SEND for RA DNS options.
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > > I hope my comments are useful.
> > > Cheers,
> > >
> > >    Vincent
> > >
> >
> > Thanks for your efforts on the improvement for this document.
> >
> > Best Regards,
> > Paul

_______________________________________________
secdir mailing list
secdir@mit.edu
https://mailman.mit.edu/mailman/listinfo/secdir