Re: [secdir] Clarification question on draft-ietf-6man-dns-options-bis-06

Jaehoon Jeong <pjeong@brocade.com> Sun, 11 July 2010 02:31 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 818503A6926 for <secdir@core3.amsl.com>; Sat, 10 Jul 2010 19:31:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.989
X-Spam-Level:
X-Spam-Status: No, score=-4.989 tagged_above=-999 required=5 tests=[AWL=1.610, 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 ScS7uRcX6SYX for <secdir@core3.amsl.com>; Sat, 10 Jul 2010 19:31:42 -0700 (PDT)
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 87A273A6925 for <secdir@ietf.org>; Sat, 10 Jul 2010 19:31:41 -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 o6B2VlRf013571 for <secdir@ietf.org>; Sat, 10 Jul 2010 22:31:47 -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 o6B2ViAC013563 for <secdir@PCH.mit.edu>; Sat, 10 Jul 2010 22:31:44 -0400
Received: from dmz-mailsec-scanner-8.mit.edu (DMZ-MAILSEC-SCANNER-8.MIT.EDU [18.7.68.37]) by mailhub-dmz-4.mit.edu (8.13.8/8.9.2) with ESMTP id o6B2Vi1V029524 for <secdir@mit.edu>; Sat, 10 Jul 2010 22:31:44 -0400
X-AuditID: 12074425-b7b12ae0000009fd-87-4c392d0faf0d
Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by dmz-mailsec-scanner-8.mit.edu (Symantec Brightmail Gateway) with SMTP id 35.45.02557.F0D293C4; Sat, 10 Jul 2010 22:31:44 -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 o6B2VZi2000910; Sat, 10 Jul 2010 19:31:35 -0700
Received: from brm-exedge.brocade.com (brm-exedge.brocade.com [144.49.197.7]) by mx0a-000f0801.pphosted.com with ESMTP id pxk7r08us-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 10 Jul 2010 19:31:34 -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; Sat, 10 Jul 2010 20:31:32 -0600
Received: from brm-exch-3.corp.brocade.com ([169.254.2.126]) by brm-excashub-1.corp.brocade.com ([172.16.72.131]) with mapi; Sat, 10 Jul 2010 20:31:33 -0600
From: Jaehoon Jeong <pjeong@brocade.com>
To: Tony Cheneau <tony.cheneau@it-sudparis.eu>
Date: Sat, 10 Jul 2010 20:31:29 -0600
Thread-Topic: Clarification question on draft-ietf-6man-dns-options-bis-06
Thread-Index: AcsgP/PhUzGllTOETiSz2GREGYKluAAYKjIQ
Message-ID: <5A6980BCAE9E6D438D4D8A05540F6FB7012FFD262B@BRM-EXCH-3.corp.brocade.com>
References: <alpine.LNX.2.00.1007101438580.19494@localhost.localdomain>
In-Reply-To: <alpine.LNX.2.00.1007101438580.19494@localhost.localdomain>
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-09_02:2010-02-06, 2010-07-09, 2010-07-09 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-1007100142
X-Brightmail-Tracker: AAAAAA==
X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id o6B2ViAC013563
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: Mon, 12 Jul 2010 09:21:32 -0700
Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "ben@nostrum.com" <ben@nostrum.com>, "secdir@mit.edu" <secdir@mit.edu>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-6man-dns-options-bis@tools.ietf.org" <draft-ietf-6man-dns-options-bis@tools.ietf.org>
Subject: Re: [secdir] Clarification question on draft-ietf-6man-dns-options-bis-06
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: Sun, 11 Jul 2010 02:31:43 -0000

Hi Tony,
Thanks for this update.

If this draft can support the identification of DNS option source, I will refer to this draft in the next revision of our draft.

Best Regards,
Paul

-----Original Message-----
From: Tony Cheneau [mailto:tony.cheneau@it-sudparis.eu] 
Sent: Saturday, July 10, 2010 9:55 AM
To: draft-ietf-6man-dns-options-bis@tools.ietf.org
Subject: Clarification question on draft-ietf-6man-dns-options-bis-06

Hello,

I read your document and I have the following comment on the Security Consideration section. (I know it may be a late comment due to the IESG
processing...)

The document states:
    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 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.

Hope it helps.

Best regards,
 	Tony Cheneau

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