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

Jaehoon Jeong <> Sun, 11 July 2010 02:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 818503A6926 for <>; Sat, 10 Jul 2010 19:31:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.989
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ScS7uRcX6SYX for <>; Sat, 10 Jul 2010 19:31:42 -0700 (PDT)
Received: from (PCH.MIT.EDU []) by (Postfix) with ESMTP id 87A273A6925 for <>; Sat, 10 Jul 2010 19:31:41 -0700 (PDT)
Received: from ( []) by (8.13.6/8.12.8) with ESMTP id o6B2VlRf013571 for <>; Sat, 10 Jul 2010 22:31:47 -0400
Received: from (MAILHUB-DMZ-4.MIT.EDU []) by (8.13.6/8.12.8) with ESMTP id o6B2ViAC013563 for <>; Sat, 10 Jul 2010 22:31:44 -0400
Received: from (DMZ-MAILSEC-SCANNER-8.MIT.EDU []) by (8.13.8/8.9.2) with ESMTP id o6B2Vi1V029524 for <>; Sat, 10 Jul 2010 22:31:44 -0400
X-AuditID: 12074425-b7b12ae0000009fd-87-4c392d0faf0d
Received: from ( []) by (Symantec Brightmail Gateway) with SMTP id 35.45.02557.F0D293C4; Sat, 10 Jul 2010 22:31:44 -0400 (EDT)
Received: from pps.filterd (m0000542 []) by (8.14.3/8.14.3) with SMTP id o6B2VZi2000910; Sat, 10 Jul 2010 19:31:35 -0700
Received: from ( []) by 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 ( by ( with Microsoft SMTP Server (TLS) id; Sat, 10 Jul 2010 20:31:32 -0600
Received: from ([]) by ([]) with mapi; Sat, 10 Jul 2010 20:31:33 -0600
From: Jaehoon Jeong <>
To: Tony Cheneau <>
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: <>
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
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 id o6B2ViAC013563
X-Mailman-Version: 2.1.6
Precedence: list
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 12 Jul 2010 09:21:32 -0700
Cc: "" <>, "" <>, "" <>, "" <>, "" <>
Subject: Re: [secdir] Clarification question on draft-ietf-6man-dns-options-bis-06
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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,

-----Original Message-----
From: Tony Cheneau [] 
Sent: Saturday, July 10, 2010 9:55 AM
Subject: Clarification question on draft-ietf-6man-dns-options-bis-06


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

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