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

Jaehoon Jeong <pjeong@brocade.com> Thu, 22 July 2010 13: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 970D33A6AF5 for <secdir@core3.amsl.com>; Thu, 22 Jul 2010 06:37:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.232
X-Spam-Level:
X-Spam-Status: No, score=-5.232 tagged_above=-999 required=5 tests=[AWL=1.367, BAYES_00=-2.599, 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 1kA53Pp1xMhy for <secdir@core3.amsl.com>; Thu, 22 Jul 2010 06:37:02 -0700 (PDT)
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 1CFFC3A6B36 for <secdir@ietf.org>; Thu, 22 Jul 2010 06:36:52 -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 o6MDb7wX007131 for <secdir@ietf.org>; Thu, 22 Jul 2010 09:37:07 -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 o6MDb57T007127 for <secdir@PCH.mit.edu>; Thu, 22 Jul 2010 09:37:05 -0400
Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU [18.9.25.15]) by mailhub-dmz-4.mit.edu (8.13.8/8.9.2) with ESMTP id o6MDagTs008096 for <secdir@mit.edu>; Thu, 22 Jul 2010 09:37:05 -0400
X-AuditID: 1209190f-b7b0aae000000a7d-32-4c4849843a64
Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by dmz-mailsec-scanner-4.mit.edu (Symantec Brightmail Gateway) with SMTP id 89.7B.02685.489484C4; Thu, 22 Jul 2010 09:37:08 -0400 (EDT)
Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.3/8.14.3) with SMTP id o6MDYoeJ030316; Thu, 22 Jul 2010 06:36:53 -0700
Received: from brm-exedge.brocade.com (brm-exedge.brocade.com [144.49.197.8]) by mx0a-000f0801.pphosted.com with ESMTP id q68up0ftv-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 22 Jul 2010 06:36:53 -0700
Received: from brm-excashub-2.corp.brocade.com (172.16.72.231) by BRM-EXEDGE-2.corp.brocade.com (172.16.72.249) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 22 Jul 2010 07:36:41 -0600
Received: from brm-exch-3.corp.brocade.com ([169.254.2.126]) by brm-excashub-2.corp.brocade.com ([172.16.72.231]) with mapi; Thu, 22 Jul 2010 07:36:51 -0600
From: Jaehoon Jeong <pjeong@brocade.com>
To: Vincent Roca <vincent.roca@inrialpes.fr>
Date: Thu, 22 Jul 2010 07:36:51 -0600
Thread-Topic: SecDir review of draft-ietf-6man-dns-options-bis-03
Thread-Index: Acspn1kO1WEvOs2fSmuBM/Tx2WwXjgAA25GA
Message-ID: <F3BA781F50E6CF40BE424085EA902DE397EBF013BB@BRM-EXCH-3.corp.brocade.com>
References: <F3BA781F50E6CF40BE424085EA902DE397EBE715A0@BRM-EXCH-3.corp.brocade.com> <1655704977.54.1279802168445.JavaMail.root@zmbs1.inria.fr>
In-Reply-To: <1655704977.54.1279802168445.JavaMail.root@zmbs1.inria.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-22_03:2010-07-22, 2010-07-22, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1007220052
X-Brightmail-Tracker: AAAAAhVGFDQVRuR3
X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id o6MDb57T007127
X-BeenThere: secdir@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: secdir-bounces@mit.edu
Errors-To: secdir-bounces@mit.edu
X-Mailman-Approved-At: Thu, 22 Jul 2010 06:47:38 -0700
Cc: 6man Chairs <6man-chairs@tools.ietf.org>, Tony Cheneau <tony.cheneau@it-sudparis.eu>, "secdir@mit.edu" <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 13:37:12 -0000

Hi Vincent,
After fixing this typo, I will submit the new version.
Thanks very much for your contribution.

Best Regards,
Paul

-----Original Message-----
From: Vincent Roca [mailto:vincent.roca@inrialpes.fr]
Sent: Thursday, July 22, 2010 7:36 AM
To: Jaehoon Jeong
Cc: draft-ietf-6man-dns-options-bis all; secdir@mit.edu; IESG; 6man Chairs; Jari Arkko; Tony Cheneau
Subject: Re: SecDir review of draft-ietf-6man-dns-options-bis-03

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/d
> raft-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/w
> diff%20draft-ietf-6man-dns-options-bis-06_txt%20draft-ietf-6man-dns-op
> tions-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