Re: [secdir] SecDir review of draft-ietf-6man-dns-options-bis-03
Jaehoon Jeong <pjeong@brocade.com> Tue, 06 July 2010 17:11 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 22E7D3A6846 for <secdir@core3.amsl.com>; Tue, 6 Jul 2010 10:11:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.288
X-Spam-Level:
X-Spam-Status: No, score=-4.288 tagged_above=-999 required=5 tests=[AWL=2.311, 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 TeRwffdZXqYV for <secdir@core3.amsl.com>; Tue, 6 Jul 2010 10:11:15 -0700 (PDT)
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 288A13A699C for <secdir@ietf.org>; Tue, 6 Jul 2010 10:11:15 -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 o66HBHS2024945 for <secdir@ietf.org>; Tue, 6 Jul 2010 13:11:17 -0400
Received: from mailhub-dmz-3.mit.edu (MAILHUB-DMZ-3.MIT.EDU [18.9.21.42]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o66HBFW6024919 for <secdir@PCH.mit.edu>; Tue, 6 Jul 2010 13:11:15 -0400
Received: from dmz-mailsec-scanner-8.mit.edu (DMZ-MAILSEC-SCANNER-8.MIT.EDU [18.7.68.37]) by mailhub-dmz-3.mit.edu (8.13.8/8.9.2) with ESMTP id o66HB5jc001449 for <secdir@mit.edu>; Tue, 6 Jul 2010 13:11:14 -0400
X-AuditID: 12074425-b7b12ae0000009fd-c3-4c3363b27abe
Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by dmz-mailsec-scanner-8.mit.edu (Symantec Brightmail Gateway) with SMTP id E0.5D.02557.2B3633C4; Tue, 6 Jul 2010 13:11:14 -0400 (EDT)
Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.3/8.14.3) with SMTP id o66HA5s6032180; Tue, 6 Jul 2010 10:11:09 -0700
Received: from brm-exedge.brocade.com (brm-exedge.brocade.com [144.49.197.7]) by mx0b-000f0801.pphosted.com with ESMTP id pv26e867p-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 06 Jul 2010 10:11:09 -0700
Received: from brm-excashub-1.corp.brocade.com (172.16.72.131) by BRM-EXEDGE-1.corp.brocade.com (172.16.72.149) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 6 Jul 2010 11:10:31 -0600
Received: from brm-exch-3.corp.brocade.com ([169.254.3.246]) by brm-excashub-1.corp.brocade.com ([172.16.72.131]) with mapi; Tue, 6 Jul 2010 11:11:07 -0600
From: Jaehoon Jeong <pjeong@brocade.com>
To: Sandra Murphy <Sandra.Murphy@sparta.com>
Date: Tue, 06 Jul 2010 11:11:05 -0600
Thread-Topic: [secdir] SecDir review of draft-ietf-6man-dns-options-bis-03
Thread-Index: AcsdLdVMvXCzLbgnQXms1IFQCsxdCgAAFXrw
Message-ID: <5A6980BCAE9E6D438D4D8A05540F6FB70115649EA0@BRM-EXCH-3.corp.brocade.com>
References: <4C248D9A.5080508@inrialpes.fr> <5A6980BCAE9E6D438D4D8A05540F6FB70113043B9B@BRM-EXCH-3.corp.brocade.com> <4C25CA06.1080809@piuha.net> <5A6980BCAE9E6D438D4D8A05540F6FB70113658855@BRM-EXCH-3.corp.brocade.com> <4C2F3541.7000206@inrialpes.fr> <5A6980BCAE9E6D438D4D8A05540F6FB70115513677@BRM-EXCH-3.corp.brocade.com> <Pine.WNT.4.64.1007061257330.4996@SMURPHY-LT.columbia.ads.sparta.com>
In-Reply-To: <Pine.WNT.4.64.1007061257330.4996@SMURPHY-LT.columbia.ads.sparta.com>
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=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-06_01:2010-02-06, 2010-07-06, 2010-07-06 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-1007060083
X-Brightmail-Tracker: AAAAAhTzSz4U9B3E
X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id o66HBFW6024919
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: Tue, 06 Jul 2010 11:10:52 -0700
Cc: 6man Chairs <6man-chairs@tools.ietf.org>, "draft-ietf-csi-send-cert@tools.ietf.org" <draft-ietf-csi-send-cert@tools.ietf.org>, "secdir@mit.edu" <secdir@mit.edu>, "draft-ietf-csi-proxy-send.all@tools.ietf.org" <draft-ietf-csi-proxy-send.all@tools.ietf.org>, Jari Arkko <jari.arkko@piuha.net>, IESG <iesg@ietf.org>, "draft-ietf-6man-dns-options-bis.all@tools.ietf.org" <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: Tue, 06 Jul 2010 17:11:19 -0000
Sandra, Thanks for this useful information. Best Regards, Paul -----Original Message----- From: Sandra Murphy [mailto:Sandra.Murphy@sparta.com] Sent: Tuesday, July 06, 2010 12:08 PM To: Jaehoon Jeong Cc: Vincent Roca; 6man Chairs; secdir@mit.edu; draft-ietf-6man-dns-options-bis.all@tools.ietf.org; Jari Arkko; IESG; draft-ietf-csi-proxy-send.all@tools.ietf.org; draft-ietf-csi-send-cert@tools.ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-6man-dns-options-bis-03 There is presently a discussion between the secdir and the authors of a new csi document that describes ways to use a new authorization value to provide more fine grained protection than "is a router". I notice that SEND protection of RA is mentioned below, with the caveat that RFC3971 SEND does not distinguish the specific authority of authorized routers. Perhaps this work in csi would be of value. --Sandy P.S. I added the appropriate recipient expansions for the csi drafts to the recipient list. That makes for a bunch of recipients, not all of whom would be interested in a longer exchange on the topic. Please consider trimming the list if you reply . On Sat, 3 Jul 2010, Jaehoon Jeong wrote: > 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 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir
- [secdir] SecDir review of draft-ietf-6man-dns-opt… Vincent Roca
- Re: [secdir] SecDir review of draft-ietf-6man-dns… Jari Arkko
- Re: [secdir] SecDir review of draft-ietf-6man-dns… Jaehoon Jeong
- Re: [secdir] SecDir review of draft-ietf-6man-dns… Bob Hinden
- Re: [secdir] SecDir review of draft-ietf-6man-dns… Vincent Roca
- Re: [secdir] SecDir review of draft-ietf-6man-dns… Jaehoon Jeong
- Re: [secdir] SecDir review of draft-ietf-6man-dns… Jaehoon Jeong
- Re: [secdir] SecDir review of draft-ietf-6man-dns… Sandra Murphy
- Re: [secdir] SecDir review of draft-ietf-6man-dns… Jaehoon Jeong
- Re: [secdir] SecDir review of draft-ietf-6man-dns… Vincent Roca
- Re: [secdir] SecDir review of draft-ietf-6man-dns… Jaehoon Jeong
- Re: [secdir] SecDir review of draft-ietf-6man-dns… Vincent Roca
- Re: [secdir] SecDir review of draft-ietf-6man-dns… Jaehoon Jeong
- Re: [secdir] SecDir review of draft-ietf-6man-dns… Jaehoon Jeong