From nobody Mon Aug 1 07:51:23 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF9A12D9C4; Mon, 1 Aug 2016 07:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3c9I9c9v3082; Mon, 1 Aug 2016 07:51:15 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD3CC12D08E; Mon, 1 Aug 2016 07:51:14 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id l69so117335022lfg.1; Mon, 01 Aug 2016 07:51:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=Bye1ofhPr55wpDmPs0+nURz8YuIBrt6Y667U/txFYCM=; b=YbHDzGNKUHhJt9Ajlgfkwxkb+agjoUlFVcTzKXYGIhJ5tQdXXBIS9SuvORHN7XxugT wSFDj//Iuj+mP7fJ+XAf0N2QVd8xO1KH6ypO8Sfr9HONVETefpa4+sgayueWxvKZUvNQ /6nmx2xPl841x7c85qp/v+jgasGH1IqRuLF+Au9soYAqUJWy1jphJh7dcgc4phZvpaN7 hsIuYkC+Ujqkd9aCXGvjX8wmRn4dlW+XaFiEXL2S1CB8dw0ZzcQaH3XadQO1Jcx6fZHI u/vG6KyV6n7IMMzEpqxuzPFe+I9K2qblr3Ox2rCy4hWySVFZCqOKeFmPXHw0Gk2DWn2Q rqzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Bye1ofhPr55wpDmPs0+nURz8YuIBrt6Y667U/txFYCM=; b=cEU5NF0FZzvRgfy4BfsTXLyLPQOTbvLSdZ0UUCXjZdVFZ36ZIPgrjbpDObIffvppmM FR6N6njJfl+JlxoKFtef3XyPVGDHGt+BCd+QY6kM380gslbxmSWRT7MIC0gVHBIIdh9O PwWrL5ZC6JRk2Y8OF26ZLuN3z6HaDdtE5zzMJfiGhPyrQo/Ti2j1I59fo/GaPGF1b6fW I4rybwJ0Ao2tkqCrFo3qRKSoyiYLcyUtsptoRGP3rzoLkNvP23hR2J2yxGfxSDr7oy/5 wr56HivBpswIWaLRL5U/l8cLqqg9EMcnRsb8lyCaKcha6GPhNApI2HB2nOS6gAFkEZk5 Etsg== X-Gm-Message-State: AEkoouvuVLI8cWSge78ZjZwaUXTIkXUfFsz8A63FJs9k0RXuAqbbuct3bcrCSthzttPfpQ== X-Received: by 10.25.22.91 with SMTP id m88mr15732030lfi.25.1470063072965; Mon, 01 Aug 2016 07:51:12 -0700 (PDT) Received: from [10.0.0.100] (093105179034.dynamic-ww-02.vectranet.pl. [93.105.179.34]) by smtp.googlemail.com with ESMTPSA id p128sm5313772lfb.32.2016.08.01.07.51.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Aug 2016 07:51:12 -0700 (PDT) To: Yaron Sheffer , IETF Security Directorate , The IESG , draft-ietf-dhc-topo-conf.all@tools.ietf.org References: From: Tomek Mrugalski Message-ID: Date: Mon, 1 Aug 2016 16:51:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] Repeat SecDir review: draft-ietf-dhc-topo-conf-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 14:51:18 -0000 On 29.07.2016 17:32, Yaron Sheffer wrote: > Summary > > The document is ready for publication. > > Details > > My previous SecDir review of -08 lamented the then short and essentially > useless Security Considerations section. This section has now been > significantly extended and as far as I can determine, is now at an > appropriate level for this draft. > > I would like to thank the authors for addressing my comments! Thank you for your review and your favourable comments. Tomek From nobody Tue Aug 2 12:49:34 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C6512D867 for ; Tue, 2 Aug 2016 12:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBseZ3g9t0ZN for ; Tue, 2 Aug 2016 12:49:30 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76A1112D7B0 for ; Tue, 2 Aug 2016 12:49:30 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:35535 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1bUfgZ-0008WH-TI; Tue, 02 Aug 2016 15:49:08 -0400 To: secdir , hch@lst.de, spencer.shepler@gmail.com, beepee@gmail.com, spencerdawkins.ietf@gmail.com, leifj@sunet.se From: Stephen Kent Message-ID: <753991fe-9379-c6cd-9342-4c837a81e6db@bbn.com> Date: Tue, 2 Aug 2016 15:49:07 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------B62E64E575DBDA929184A3E1" Archived-At: Subject: [secdir] review of draft-ietf-nfsv4-scsi-layout-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 19:49:32 -0000 This is a multi-part message in MIME format. --------------B62E64E575DBDA929184A3E1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.These comments were written with the intent of improving security requirements and considerations in IETF drafts.Comments not addressed in last call may be included in AD reviews during the IESG review.Document editors and WG chairs should treat these comments just like any other last call comments. This document the SCSI layout for Parallel NFS (RFC 5663). It appears to update that RFC (see the last paragraph on page 3), although the header does not indicate this. In section 1 the text refers to a SCSI device “signature” but does not define this term. Section 2.1 describes the security responsibilities for clients, and notes that the Security Considerations section (4) provides an expanded discussion. The bottom line is that SCSI layout pNFS is not recommended for use in contexts where clients cannot be trusted to enforce file access controls. I did not review later parts of Section 2. Section 3 reiterates the fact that SCSI layout pNFS relies on clients to enforce access controls and locks at a granularity finer than a device. For example, the architecture relies on client software to not try to access blocks on a device other than those to which the metadata server has granted access. Sections 3.1 and 3.2 provide additional descriptions of the security assumptions and limitations associated with SCSI layout pNFS. TheSecurity Considerations section consists of two paragraphs. The first reminds the reader that NFS security mechanisms may not be available in the SCSI layout pNFS context, because it operates at a lower layer than NFS. This mode of operation for pNFS may be insecure, or may be afforded good security, depending on the underlying access protocols. iSCSI (RFC 7143) is cited as an example of the latter.The second paragraph reiterates the warnings that appeared earlier in the document, noting that this mode of pNFS is not suitable for all environments. I think the discussions of security provided by this I-D are appropriate and clearly written. --------------B62E64E575DBDA929184A3E1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving security requirements and considerations in IETF drafts.  Comments not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

 

This document the SCSI layout for Parallel NFS (RFC 5663). It appears to update that RFC (see the last paragraph on page 3), although the header does not indicate this.

 

In section 1 the text refers to a SCSI device “signature” but does not define this term.

 

Section 2.1 describes the security responsibilities for clients, and notes that the Security Considerations section (4) provides an expanded discussion. The bottom line is that SCSI layout pNFS is not recommended for use in contexts where clients cannot be trusted to enforce file access controls.

 

I did not review later parts of Section 2.

 

Section 3 reiterates the fact that SCSI layout pNFS relies on clients to enforce access controls and locks at a granularity finer than a device. For example, the architecture relies on client software to not try to access blocks on a device other than those to which the metadata server has granted access.

 

Sections 3.1 and 3.2 provide additional descriptions of the security assumptions and limitations associated with SCSI layout pNFS.

 

The  Security Considerations section consists of two paragraphs. The first reminds the reader that NFS security mechanisms may not be available in the SCSI layout pNFS context, because it operates at a lower layer than NFS. This mode of operation for pNFS may be insecure, or may be afforded good security, depending on the underlying access protocols. iSCSI (RFC 7143) is cited as an example of the latter.  The second paragraph reiterates the warnings that appeared earlier in the document, noting that this mode of pNFS is not suitable for all environments.

 

I think the discussions of security provided by this I-D are appropriate and clearly written.

--------------B62E64E575DBDA929184A3E1-- From nobody Tue Aug 2 22:37:56 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C9712D967; Tue, 2 Aug 2016 22:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RS9k2KRFRw7N; Tue, 2 Aug 2016 22:37:53 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FB3412B020; Tue, 2 Aug 2016 22:37:53 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id r9so218590547ywg.0; Tue, 02 Aug 2016 22:37:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=Tyxv91Wk0pYu81hza6o9xeTRvWL2yEwBFcyLj8VxCzw=; b=m1ZdjlZfiQ9FlfUW457x7Ug/phTbVS0wHvFBPjaoh8iIxJ8vDfWMZIZwPJTM6HHEBP cYA48hd8vUrrPmMaNDdO6DON/PAZMM3Pkzc5nBvj3Wgdyeg3PL2nNXB3BLBc111uVgVg meDRrg/zzZZRLmNZW+dBs8Cr2cn+bOSLalDirL5Ak0Lo0OkCpxCLBRer+CChpeVv7Z9N vvLd4L4rwD9VlLFpS4J+xsTHlFz0hZIJpk+EgopW1PPFwjj1bORaYodKO/zdaNeYUAxe 7Fby4enXeEAxPi3qpT04g97v76VXuNJS31pR5d4i08kwIPKGGYtX14UrZrygq135puHw qcDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Tyxv91Wk0pYu81hza6o9xeTRvWL2yEwBFcyLj8VxCzw=; b=hnqPKASJ4pykwo/tjB4Lqrdsnenj9n4PCe0GduYac1OJ/vhG/7GEKbZVAgteMeUT8d 3ii/st9zDLZJwHe+VclLsjo5LCburf/JIpGHCN2UiJuV56DYLUXBuAjGPCRcL+2NmgAX QN2h9GjCx9YIW6IvLHKK2zTEYV7O528snOPxIfp/uyoeYg3hHf1PCtzXYbU96wYkGTYO tWz5y5c4Hrzpzx1vEQf9daOEvUIptZ1w3svkZrkaFVEB3IiKBPgjiZJ8dFjUAjVnD+Ra KQ4Uyg1IKs7gFD5qVPOoCK3ge+IvTU+Dazm4iVrn3AIxly/6TmL1DO6X+MMRaoqSFSJU ddNQ== X-Gm-Message-State: AEkoouus0i7tpOfB5TSbPRyO/YO1aBw0GmRTRPqfxn62Tkv7DLVlGmfGVD/1zCFU1b0radRgHjjjt5X88OV5XA== X-Received: by 10.37.109.86 with SMTP id i83mr4179905ybc.123.1470202672600; Tue, 02 Aug 2016 22:37:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.192.208 with HTTP; Tue, 2 Aug 2016 22:37:52 -0700 (PDT) From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= Date: Tue, 2 Aug 2016 22:37:52 -0700 Message-ID: To: "secdir@ietf.org" , draft-ietf-bess-ir@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [secdir] Secdir review of draft-ietf-bess-ir X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 05:37:55 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes the establishment and use of so-called "ingress replication tunnels" in connection with multicast VPNs. As such, the document, as I read it, merely provides further details on the procedures already defined in RFC 6513 and RFC 6514. Correspondingly, I would agree with the assertion in the Security Considerations section that the Security Considerations sections in those RFCs still apply. -- Magnus From nobody Wed Aug 3 23:54:59 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFA712D0E4; Wed, 3 Aug 2016 23:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjmYrxKiz4mG; Wed, 3 Aug 2016 23:54:54 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7597212D103; Wed, 3 Aug 2016 23:54:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9714; q=dns/txt; s=iport; t=1470293694; x=1471503294; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=QGj5eNbVQm2Tvsx/rqzRfkT4oS1mAvGV91mfVGTf4bc=; b=D6mJ7ziqSVF9hLJSsr3aQaNYKsY9twyxvScla/RwyA0jnu5GNo46C5Eg eceOuX4f3qj8y2Jv+r3SRxX8ibpzFdQSGisrEwO+lFo3OD+xWiYrQYHg4 b8v8j5NcYpAaemIegyvkuAUdHq72+LtMS9T/ZlGnMR7KV82a9H9sIabji Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A4AgAc5qJX/4oNJK1XBoNFVnwHuRmBf?= =?us-ascii?q?SCFfQIcgTE4FAEBAQEBAQFdJ4ReAQEEAQ4VBA0xBg4FCwIBBgIYAgImAgICMBU?= =?us-ascii?q?QAgQOBYgXAw8IkjudIItWGIQNAQEBAQEBAQEBAQEBAQEBAQEBAR6BAYUpgXiBU?= =?us-ascii?q?oEDhDIOgwErgi8BBJk0AYkThWyPQIwwg3YBHjaCEhyBTG6HJn8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,469,1464652800"; d="scan'208";a="306582383" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Aug 2016 06:54:34 +0000 Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u746sYFr009882 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 4 Aug 2016 06:54:34 GMT Received: from xch-rcd-019.cisco.com (173.37.102.29) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 4 Aug 2016 01:54:34 -0500 Received: from xch-rcd-019.cisco.com ([173.37.102.29]) by XCH-RCD-019.cisco.com ([173.37.102.29]) with mapi id 15.00.1210.000; Thu, 4 Aug 2016 01:54:34 -0500 From: "Pal Martinsen (palmarti)" To: Charlie Kaufman Thread-Topic: Secdir review of draft-ietf-ice-dualstack-fairness-03 Thread-Index: AQHR2AUWk4ql4+jlVEO1OZzBN30rgKA43a+A Date: Thu, 4 Aug 2016 06:54:33 +0000 Message-ID: <34E03521-A8B0-417C-8A81-5F8234AE7CB4@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.217.3] Content-Type: text/plain; charset="utf-8" Content-ID: <93CBDB58298DFA43A769322E7DAEAAC0@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-ice-dualstack-fairness.all@tools.ietf.org" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ice-dualstack-fairness-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 06:54:57 -0000 DQo+IE9uIDA3IEp1bCAyMDE2LCBhdCAwNjoxMiwgQ2hhcmxpZSBLYXVmbWFuIDxjaGFybGlla2F1 Zm1hbkBvdXRsb29rLmNvbT4gd3JvdGU6DQo+IA0KPiBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1 bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0 IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNH LiBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBv ZiB0aGUgc2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMuIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNo YWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0 IGNhbGwgY29tbWVudHMuDQo+IA0KPiBJIGRvbid0IGJlbGlldmUgdGhpcyBwcm9wb3NhbCByYWlz ZXMgYW55IHNlY3VyaXR5IGNvbmNlcm5zLiBJdCBoYXMgYSBzaG9ydCBTZWN1cml0eSBDb25zaWRl cmF0aW9ucyBzZWN0aW9uIGNvbnRhaW5pbmcgaW5mb3JtYXRpb24gcmVsZXZhbnQgdG8gSUNFIGJ1 dCBub3QgdG8gdGhpcyBwcm9wb3NlZCBtb2RpZmljYXRpb24uDQo+IA0KUmV3cm90ZSB0aGUgc2Vj dXJpdHkgc2VjdGlvbi4gR29pbmcgaW50byBkZXRhaWxzIHJlZ2FyZGluZyBTVFVOIGlzIG5vdCBu ZWVkZWQuDQoNCkhvdyBhYm91dDoNClRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBkZXNjcmli ZWQgaW4gW0ktRC5pZXRmLWljZS1yZmM1MjQ1YmlzXQ0KYXJlIHN0aWxsIHZhbGlkLiAgVGhpcyBz cGVjaWZpY2F0aW9uIGRvZXMgbm90IGFkZCBvciByZW1vdmUgYW55DQpzZWN1cml0eSBjb25zaWRl cmF0aW9ucy4gIEl0IGNoYW5nZXMgcmVjb21tZW5kZWQgdmFsdWVzIGFuZCBkZXNjcmliZXMNCmhv dyBhbiBhZ2VudCBjb3VsZCBjaG9vc2UgdGhvc2UgdmFsdWVzIGluIGEgc2FmZSB3YXkuDQoNCg0K DQo+IFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgYSBtb2RpZmljYXRpb24gdG8gUkZDNTI0NWJpcyAo d2hpY2ggc3BlY2lmaWVzIGEgcHJvdG9jb2wgZm9yIE5BVCB0cmF2ZXJzYWwpLiBXaGVuIHRyeWlu ZyB0byBlc3RhYmxpc2ggYSBjb25uZWN0aW9uIHRocm91Z2ggYSBOQVQsIHRoZXJlIGFyZSBhIG51 bWJlciBvZiBkaWZmZXJlbnQgdGVjaG5pcXVlcyB0aGF0IGNhbiBiZSB1c2VkLCBzb21lIG9mIHdo aWNoIHdpbGwgd29yayBhbmQgc29tZSBvZiB3aGljaCB3aWxsIG5vdCB3b3JrIGRlcGVuZGluZyBv biB0aGUgY2hhcmFjdGVyaXN0aWNzIG9mIHRoZSBOQVQgYW5kIG90aGVyIGFzcGVjdHMgb2YgdGhl IGVudmlyb25tZW50LiBSRkM1MjQ1IHNwZWNpZmllcyBhbiBlbnVtZXJhdGlvbiBvZiBzdWNoIHRl Y2huaXF1ZXMgYW5kIHNwZWNpZmllcyBhbiBvcmRlciBpbiB3aGljaCB0aGV5IHNob3VsZCBiZSBh dHRlbXB0ZWQuDQo+IA0KPiBBcHBhcmVudGx5LCB0aGVyZSBhcmUgcHJvYmxlbXMgaW4gcmVhbCB3 b3JsZCBkZXBsb3ltZW50cyB3aGVyZSB0aGVyZSBhcmUgYSBsYXJnZSBudW1iZXIgb2YgcG9zc2li bGUgTkFUIHRyYXZlcnNhbCB0ZWNobmlxdWVzIGFuZCBjaGVja2luZyB0aGVtIGluIHRoZSBvcmRl ciBwcmVzY3JpYmVkIGJ5IFJGQzUyNDViaXMgcmVzdWx0cyBpbiBsb25nIGRlbGF5cyBhbmQgc29t ZXRpbWVzIGNvbm5lY3Rpb24gZmFpbHVyZXMgYmFzZWQgb24gdGltZW91dHMuIFRoaXMgZG9jdW1l bnQgcHJvcG9zZXMgY2hhbmdpbmcgdGhlIG9yZGVyIGluIG9yZGVyIHRvIGdldCBiZXR0ZXIgcGVy Zm9ybWFuY2UgYW5kIHJlbGlhYmlsaXR5LiBJdCBtYWtlcyBubyBvdGhlciBjaGFuZ2VzIHRvIHRo ZSBwcm90b2NvbC4NCj4gDQoNClRoYXQgaXMgYSBnb29kIHN1bW1hcnkuIE15IG9ubHkgY29tbWVu dCBpcyB0aGF0IHdlIGFyZSBub3QgZGVhbGluZyB3aXRoIOKAnHRlY2huaXF1ZXPigJ0gKElDRSBp cyB0aGUgdGVjaG5pcXVlIHdlIGFyZSB1c2luZykuICBXaGF0IHdlIGFyZSBzdHJ1Z2dsaW5nIHdp dGggaXMgbXVsdGlwbGUgbmV0d29yayBwYXRocyB0aGF0IG1heSBvciBtYXkgbm90IHdvcmsuIA0K DQo+IERldGFpbGVkIHJldmlldzoNCj4gDQo+IEknbSBub3QgYW4gSUNFIGV4cGVydCwgc28gc29t ZSBvZiB0aGVzZSBjb21tZW50cyBtYXkgYmUgY29tcGxldGVseSBtaXNndWlkZWQuIFRha2UgdGhl bSBmb3Igd2hhdGV2ZXIgdGhleSBtYXkgYmUgd29ydGguDQo+IA0KPiBJIGRvbid0IHRoaW5rICJm YWlybmVzcyIgaXMgdGhlIHJpZ2h0IHRlcm0gaW4gdGhpcyBjb250ZXh0LiBUaGUgZ29hbCBpcyBu b3QgYSBmYWlyIGRpdmlzaW9uIG9mIHJlc291cmNlcyBiZXR3ZWVuIGRpZmZlcmVudCBjbGllbnRz IG9yIGV2ZW4gYW55IHNvcnQgb2YgYmFsYW5jZSBiZXR3ZWVuIHVzZSBvZiBJUHY0IGFuZCBJUHY2 LiBJZiBtYW55IGRpZmZlcmVudCBjb25uZWN0aXZpdHkgbWVjaGFuaXNtcyB3b3JrZWQsIHRoZSBw cmVmZXJyZWQgbWVjaGFuaXNtIHdvdWxkIGJlIChJIGFzc3VtZSkgdGhlIG9uZSBjb21wdXRlZCB1 c2luZyB0aGUgZm9ybXVsYSBpbiBSRkM1MjQ1YmlzLiBUaGUgcHJvYmxlbSBpcyB0aGF0IGNoZWNr aW5nIGFsbCBvZiB0aGUgbWVjaGFuaXNtcyBpbiBvcmRlciB0byB0b28gdGltZSBjb25zdW1pbmcs IGFuZCB0aGVyZSBpcyBhIGRlc2lyZSB0byBjaGVjayAoYW5kIHNldHRsZSBvbikgdGVjaG5pcXVl cyBtb3JlIGxpa2VseSB0byB3b3JrIGFoZWFkIG9mIHRlY2huaXF1ZXMgbGVzcyBsaWtlbHkgdG8g d29yayBidXQgbW9yZSBvcHRpbWFsIGlmIHRoZXkgZG8gKGluIHBhcnRpY3VsYXIsIGNoZWNraW5n IHNvbWUgSVB2NCBiYXNlZCB0ZWNobmlxdWVzIGJlZm9yZSBhbGwgb2YgdGhlIElQdjYgYmFzZWQg dGVjaG5pcXVlcyBoYXZlIGJlZW4gdHJpZWQpLg0KPiANCg0KSSB0ZW5kIHRvIGFncmVlLCBidXQg d2Ugc3RydWdnbGVkIHRvIGZpbmQgYSBiZXR0ZXIgd29yZCB0aGFuIGZhaXJuZXNzLiANCg0KSSBh bSBub3QgYSBuYXRpdmUgc3BlYWtlciwgc28gSSBtaWdodCBnb3QgdGhpcyB3cm9uZy4gRnJvbSBo dHRwOi8vd3d3LmRpY3Rpb25hcnkuY29tOg0K4oCcdGhlIHN0YXRlLCBjb25kaXRpb24sIG9yIHF1 YWxpdHkgb2YgYmVpbmcgZmFpciwgb3IgZnJlZSBmcm9tIGJpYXMgb3IgaW5qdXN0aWNlOyBldmVu aGFuZGVkbmVzc+KAnS4NCg0KV2UgYXJlIHRyeWluZyB0byBiZSBmcmVlIGZyb20gYmlhcyBvciBp bmp1c3RpY2Ugd2hlbiBkZWNpZGluZyB3aGF0IG5ldHdvcmsgcGF0aHMgdG8gdGVzdCBmaXJzdC4g DQoNCg0KPiBTZWN0aW9uIDUgc2F5czoNCj4gPiBJQ0UgW0ktRC5pZXRmLWljZS1yZmM1MjQ1Ymlz XSBzZWN0aW9uIDQuMS4yLjIgaGFzIGd1aWRlbGluZXMgZm9yIGhvdw0KPiA+IHRoZSB0eXBlIHBy ZWZlcmVuY2UgYW5kIGxvY2FsIHByZWZlcmVuY2UgdmFsdWUgc2hvdWxkIGJlIGNob3Nlbi4NCj4g PiBJbnN0ZWFkIG9mIGhhdmluZyBhIHN0YXRpYyBsb2NhbCBwcmVmZXJlbmNlIHZhbHVlIGZvciBJ UHY0IGFuZCBJUHY2DQo+ID4gYWRkcmVzc2VzLCBpdCBpcyBwb3NzaWJsZSB0byBjaG9vc2UgdGhp cyB2YWx1ZSBkeW5hbWljYWxseSBpbiBzdWNoIGENCj4gPiB3YXkgdGhhdCBJUHY0IGFuZCBJUHY2 IGFkZHJlc3MgY2FuZGlkYXRlIHByaW9yaXRpZXMgZW5kIHVwDQo+ID4gaW50ZXJtaW5nbGVkIHdp dGhpbiB0aGUgc2FtZSBjYW5kaWRhdGUgdHlwZS4gSXQgaXMgYWxzbyBwb3NzaWJsZSB0bw0KPiA+ IGFzc2lnbiBsb3dlciBwcmlvcml0aWVzIHRvIElQIGFkZHJlc3NlcyBkZXJpdmVkIGZyb20gdW5y ZWxpYWJsZQ0KPiA+IGludGVyZmFjZXMgdXNpbmcgdGhlIGxvY2FsIHByZWZlcmVuY2UgdmFsdWUu DQo+IA0KPiBUaGlzIHNwZWNpZmljYXRpb24gc2F5cyB3aGF0IGlzIHBvc3NpYmxlLCBidXQgaXQg ZG9lcyBub3QgKGFzIGZhciBhcyBJIGNvdWxkIHNlZSkgc3BlY2lmeSBhbnkgcGFydGljdWxhciBt ZWFucyBvZiBhY2NvbXBsaXNoaW5nIGl0LiBJZiB0aGUgaW50ZW50IG9mIHRoaXMgUkZDIGlzIHRv IGVuY291cmFnZSBwZW9wbGUgdG8gZXhwZXJpbWVudCB3aXRoIGRpZmZlcmVudCBwcmlvcml0eSB0 ZWNobmlxdWVzLCB0aGF0J3MgZmFpciBidXQgdGhlIGRvY3VtZW50IHNob3VsZCBzYXkgc28uIElm IHRoZSBpbnRlbnQgaXMgdG8gZW5jb3VyYWdlIHBlb3BsZSB0byBjb3B5IHRoZSBkZXNpZ24gaW4g SUNFX2R1YWxzdGFja19pbXAsIHRoZW4gaXQncyBmb3JtdWxhIGZvciBwcmlvcml0eSBzaG91bGQg YmUgc3BlY2lmaWVkIGhlcmUgaW4gc3VmZmljaWVudCBkZXRhaWwgdG8gaW1wbGVtZW50IGl0Lg0K PiANCkdvb2QgcG9pbnQuIA0KDQpUaGUgb3JpZ2luYWwgaW50ZW50IG9mIHRoZSBkcmFmdCB3YXMg dG8gcHJvdmlkZSBhIGZvcm11bGEsIGJ1dCBjcmVhdGluZyBvbmUgdGhhdCBldmVyeW9uZSB3YXMg aGFwcHkgd2l0aCBwcm92ZWQgZGlmZmljdWx0LiBTbyB0aGUgZHJhZnQgcmV2ZXJ0ZWQgdG8gcHJv dmlkZSBndWlkZWxpbmVzIGFuZCBzYXkgd2hhdCB2YWx1ZXMgc2FmZWx5IGNvdWxkIHNhZmVseSBi ZSBleHBlcmltZW50ZWQgd2l0aC4gDQogDQpBZGRlZCB0ZXh0IHRvIGludHJvZHVjdGlvbjoNCuKA nCBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB3aGF0IHBhcmFtZXRlcnMgYW4gYWdlbnQgY2FuIHNh ZmVseSBhbHRlciB0bw0KICAgZmFpcmx5IG9yZGVyIHRoZSBjaGVja2xpc3QgY2FuZGlkYXRlIHBh aXJzIGluIG11bHRpaG9tZWQgYW5kIGR1YWwtDQogICBzdGFjayBlbnZpcm9ubWVudHMsIHRodXMg YWZmZWN0aW5nIHRoZSBzZW5kaW5nIG9yZGVyIG9mIHRoZQ0KICAgY29ubmVjdGl2aXR5IGNoZWNr cy4gIEFjdHVhbCB2YWx1ZXMgb2YgdGhvc2UgcGFyYW1ldGVycyBpcyBhbg0KICAgaW1wbGVtZW50 YXRpb24gZGV0YWlsLiAgRGVwZW5kYW50IG9uIHRoZSBub21pbmF0aW9uIG1ldGhvZCBpbiB1c2Us DQogICB0aGlzIG1pZ2h0IGhhdmUgYW4gZWZmZWN0IG9uIHdoYXQgY2FuZGlkYXRlIHBhaXIgZW5k cyB1cCBhcyB0aGUNCiAgIGFjdGl2ZSBvbmUuICBVbHRpbWF0ZWx5IGl0IHNob3VsZCBiZSB1cCB0 byB0aGUgYWdlbnQgdG8gZGVjaWRlIHdoYXQNCiAgIGNhbmRpZGF0ZSBwYWlyIGlzIGJlc3Qgc3Vp dGVkIGZvciB0cmFuc3BvcnRpbmcgbWVkaWEu4oCdDQoNCg0KPiBTZWN0aW9uIDEgcGFyYSAxIGxp bmUgNTogQWxsIGludGVyZmFjZXMgYW5kIGFkZHJlc3MgdHlwZXMgYXJlIGtub3duIHRvIHRoZSBh cHBsaWNhdGlvbi4gUGVyaGFwcyB0aGlzIHdhcyBpbnRlbmRlZCB0byBzYXkgYWxsIGludGVyZmFj ZXMgYW5kIGFkZHJlc3MgdHlwZXMga25vd24gYnkgdGhlIGFwcGxpY2F0aW9uIHRvIGJlIHVucmVs aWFibGXigKYNCj4gDQo/PyBEaWQgbm90IGZpbmQgdGhhdCB0ZXh0Lg0KDQo+IFNlY3Rpb24gMSBs YXN0IHBhcmFncmFwaCBhbmQgU2VjdGlvbiA1IHRoaXJkIHRvIGxhc3QgcGFyYWdyYXBoIHNheToN Cj4gDQo+ID4gVGhlIGludHJvZHVjZWQgZmFpcm5lc3MgbWlnaHQgYmUgYmV0dGVyLCBidXQgbm90 DQo+ID4gd29yc2UgdGhhbiB3aGF0IGV4aXN0cyB0b2RheQ0KPiANCj4gVGhpcyBpcyBwcm9iYWJs eSBub3QgdHJ1ZS4gVGhlcmUgYXJlIHByb2JhYmx5IHVudXN1YWwgY2FzZXMgd2hlcmUgdGhpcyBy ZW9yZGVyaW5nIHdpbGwgcmVzdWx0IGluIHNsaWdodGx5IGluY3JlYXNlZCBjb25uZWN0aW9uIHRp bWVzLiBJIHN1c3BlY3Qgd2hhdCBpcyBtZWFudCBpcyB0aGF0ICJJbiBhbG1vc3QgYWxsIGNhc2Vz IHRoaXMgY2hhbmdlIHdpbGwgcmVzdWx0IGluIGNvbm5lY3Rpb24gdGltZXMgYXQgbGVhc3QgYXMg ZmFzdCBhcyB0aG9zZSB1c2luZyB0aGUgcHJldmlvdXMgc3lzdGVtLCBhbmQgaW4gbWFueSBjYXNl cyB0aGUgYmVuZWZpdCB3aWxsIGJlIHN1YnN0YW50aWFsLuKAnQ0KPiANCkJvdGggb2YgdGhvc2Ug c2VjdGlvbnMgdGFsa3MgYWJvdXQgYmFja3dhcmQgY29tcGF0aWJpbGl0eS4gVGhlIGludGVudCB3 YXMgdG8gc2F5IGlmIGFnZW50IHN1cHBvcnRpbmcgZHVhbC1zdGFjayBmYWlybmVzcyB0YWxrcyB0 byBhbiBvbGQgSUNFIGFnZW50IHRoaW5ncyB3b3VsZCBwcm9iYWJseSBzdGlsbCBiZSBiZXR0ZXIg b2ZmLCBidXQgc2luY2UgdGhpcyBpcyBhbHNvIG9ubHkgcmVjb21tZW5kYXRpb25zIGluIHRoZSBJ Q0UgUkZDIHRoZXJlIGlzIHJlYWxseSBrbm93IHdheSBmb3IgdXMgdG8ga25vdy4gDQoNClNheWlu ZyBhbnl0aGluZyBhYm91dCBjb25uZWN0aW9uIHRpbWVzIHdpbGwgb3BlbiB1cCBhIGJpZyByYXQt aG9sZSBpbiB0aGUgV0cuIFRoZSB1c2Ugb2YgdGhlIGZhaXJuZXNzIHdvcmRpbmcgd2FzIG1lYW50 IHRvIGluZGljYXRlIHRoYXQgb3ZlcmFsbCBjb25uZWN0aW9uIHRpbWVzIG1pZ2h0IGdvIHVwICgo RXNwZWNpYWxseSBmb3IgdGhvc2UgaW1wbGVtZW50YXRpb24gdGhhdCBkaWQgYSBoYXJkIHByaW9y aXRpc2F0aW9uIG9mIElQdjQsIGJ1dCB0aGUgZ29hbCBvZiB0aGlzIGlzIHRvIGhlbHAgSVB2NiBh cyB3ZWxsKSwgYnV0IHlvdSB3b3VsZCBhdm9pZCB0aG9zZSBzY2VuYXJpb3Mgd2hlcmUgZXhjZXNz aXZlIGRlbGF5cyBlcmUgZW5jb3VudGVyZWQuIA0KDQo+IFR5cG9zOg0KPiANCj4gU2VjdGlvbiAx IHBhcmEgMSBsaW5lIDU6IGFyZ3VhYmxlIC0+IGFyZ3VhYmx5DQpGaXhlZC4NCj4gU2VjdGlvbiAx IHBhcmEgMSBsaW5lIDc6IGtub3cgLT4ga25vd24NCkZpeGVkDQo+IFNlY3Rpb24gMSBwYXJhIDIg bGluZSA3OiBkZXNjcmliZXMgLT4gZGVzY3JpYmUNCkZpeGVkLg0KPiBQYWdlIDQgbGFzdCBwYXJh IGxpbmUgNzog4oCcdG9vIGV4Y2Vzc2l2ZSIgLT4gIm5vdCBvcHRpbWFsIg0KRml4ZWQNCj4gU2Vj dGlvbiA3IGVuZCBvZiB0aGlyZCB0byBsYXN0IHBhcmFncmFwaDogbWlzc2luZyDigJwu4oCdDQpJ Z25vcmVkLCB0ZXh0IHRvIGJlIHJlbW92ZWQgYmVmb3JlIHB1Ymxpc2hpbmcgYXMgUkZDLiANCg0K DQoNCkhhdmUgcG9zdGVkIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0LiBXZSBzaG91bGQgcHJv YmFibHkgdGFrZSBlc3BlY2lhbGx5IGNhcmUgdG8gbWFrZSBzdXJlIHdlIGFyZSBoYXBweSB3aXRo IHRoZSBuZXcgc2VjdXJpdHkgc2VjdGlvbi4gDQoNCg0KLi0uDQpQw6VsLUVyaWsNCg0KPiANCj4g DQo+IA0KPiBTZW50IGZyb20gT3V0bG9vaw0KDQo= From nobody Thu Aug 4 02:40:13 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F0612D875 for ; Thu, 4 Aug 2016 02:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BexbJMasseET for ; Thu, 4 Aug 2016 02:40:08 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6819212D593 for ; Thu, 4 Aug 2016 02:40:08 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u749e3AZ012471 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 4 Aug 2016 12:40:03 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u749e30c024153; Thu, 4 Aug 2016 12:40:03 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22435.3443.92391.275792@fireball.acr.fi> Date: Thu, 4 Aug 2016 12:40:03 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 09:40:12 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Klaas Wierenga is next in the rotation. For telechat 2016-08-04 Reviewer LC end Draft Tobias Gondrom T 2016-07-11 draft-sweet-rfc2910bis-08 Paul Hoffman TR2016-07-04 draft-ietf-grow-blackholing-02 Simon Josefsson T 2016-07-13 draft-ietf-6lo-ethertype-request-01 Warren Kumari T 2016-07-29 draft-sweet-rfc2911bis-09 Ben Laurie T 2016-08-04 draft-ietf-6man-multi-homed-host-07 Catherine Meadows T 2016-08-01 draft-ietf-xrblock-independent-burst-gap-discard-02 For telechat 2016-08-18 Jeffrey Hutzelman T 2016-07-04 draft-ietf-sipcore-dns-dual-stack-06 Eric Osterweil T 2016-08-16 draft-ietf-httpauth-extension-06 Radia Perlman T 2016-08-15 draft-ietf-i2rs-protocol-security-requirements-06 Yaron Sheffer T 2016-08-15 draft-ietf-isis-rfc4971bis-01 Melinda Shore T 2016-08-12 draft-ietf-jose-cfrg-curves-03 Robert Sparks T 2016-08-11 draft-ietf-manet-smf-sec-threats-05 Sean Turner T 2016-08-17 draft-ietf-radext-datatypes-04 Carl Wallace T 2016-08-11 draft-ietf-radext-ip-port-radius-ext-09 Last calls and special requests: Alan DeKok 2016-04-30 draft-bradner-rfc3979bis-08 Daniel Kahn Gillmor E 2016-02-01 draft-ietf-rtcweb-security-08 Matt Lepinski 2016-08-04 draft-ietf-insipid-session-id-24 Matthew Miller 2016-08-06 draft-ietf-avtcore-rfc5764-mux-fixes-10 Sandy Murphy 2016-08-12 draft-ietf-tsvwg-gre-in-udp-encap-13 Yoav Nir 2016-08-17 draft-seantek-ldap-pkcs9-05 Hilarie Orman 2016-08-12 draft-ietf-avtext-rid-04 Rich Salz 2016-08-15 draft-ietf-isis-remaining-lifetime-01 Takeshi Takahashi 2016-08-12 draft-ietf-nvo3-arch-06 Hannes Tschofenig E None draft-ietf-ntp-network-time-security-14 Hannes Tschofenig E None draft-ietf-ntp-cms-for-nts-message-06 Hannes Tschofenig E None draft-ietf-ntp-using-nts-for-ntp-05 Tina TSOU 2016-08-15 draft-ietf-ospf-two-part-metric-05 David Waltermire 2016-08-11 draft-ietf-tram-turn-mobility-02 Brian Weis E 2016-02-01 draft-ietf-cdni-uri-signing-09 Brian Weis 2016-08-11 draft-ietf-tram-turn-server-discovery-07 -- kivinen@iki.fi From nobody Thu Aug 4 03:45:16 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33DDD12DC9D for ; Thu, 4 Aug 2016 03:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.988 X-Spam-Level: X-Spam-Status: No, score=-3.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jq1GP1Qmym2 for ; Thu, 4 Aug 2016 03:45:12 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8730512DC64 for ; Thu, 4 Aug 2016 03:45:12 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id w127so165864471vkh.2 for ; Thu, 04 Aug 2016 03:45:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=FmV98zh2loyVJ2VzFo42oNUN4B5zhcUp67R5CpWAF0U=; b=lB0xt8Py1hI18wYu8+mzvjW5fF4dTda8O9/LNq+B8i6PzmaTDCJous9DNYUasdbt5v JG0UrrIteKNBXTKsFx7Z0UU4iS087UXh4m3EwMIBmzpbvOlST3lejG0OBrDIZTUYrkXT NFdTD9p7tY5Oju3hnkA5trMBN/7bqldMp5zt+T4aGvoS0q1hBXvCiGLmeTvZd+oMGkCJ lQNs2eJZIU4RRhYhKz42v1Al0Ehn8nfY/fSiubwHqlvY80XjDBkZEpGpB/j+5wID7X0U pOfokO/ihveZjFeaydmSCfxwm/O2u7u6Sqsp+LzYM5zzIAhd2SN2oaM/bBXprZg5hcjN h74Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=FmV98zh2loyVJ2VzFo42oNUN4B5zhcUp67R5CpWAF0U=; b=BiwF+TfwxK64qlUpZ49ai/JQ5bpIRtutfwcYjQeDtEpTqYZxluu4pofXZ5a63Ox1kJ WUK5updcqa72h7BM7zL47bs45knqxB2K5yetgjdwD3d58FgBNa0SWDT80TNTgrSvBtKL xJB21IAywlNzafxaRTf906Ps1UCnvWP8dcu6M4l3LF31HHOuOl+BKmyclxe4ekoss65F 6U6PnBOVxr2uNpu0VNuPOd6azxzf/3L0Nux2HZWB1rMF/ySxMz4pkoOrBVCqusIRZrnY MqLI0z3KJiFOJztLPRYEqFEsgSfTYSLTK9wyMLMj4qChEusX8RIiRUaGZacJYvNr2EZG tCtA== X-Gm-Message-State: AEkooutnmlT39ViUbFUoTG+6aapGsCflpBkCPkzysEfI2Qe4iA+ZKq2DLWUX1B5PlFRVOdkaodnJpS4mBNjh6gvg X-Received: by 10.31.203.196 with SMTP id b187mr1478193vkg.4.1470307511492; Thu, 04 Aug 2016 03:45:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.168.142 with HTTP; Thu, 4 Aug 2016 03:45:10 -0700 (PDT) From: Ben Laurie Date: Thu, 4 Aug 2016 11:45:10 +0100 Message-ID: To: The IESG , "secdir@ietf.org" , draft-ietf-6man-multi-homed-host.all@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [secdir] draft-ietf-6man-multi-homed-host-07 security review X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 10:45:14 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Status: ready with nits. The document claims to introduce no new security exposure, but it seems to me that it is designed to ensure routing occurs correctly in situations where it previously didn't - this may result in unexpected exposure of networks that previously were unreachable. I think this is a nit, because clearly such networks were poorly designed in the first place, but perhaps a mention should be made? From nobody Fri Aug 5 03:01:22 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 434A112D12B; Fri, 5 Aug 2016 03:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LUkr2TqS0l8; Fri, 5 Aug 2016 03:01:16 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DB9012D098; Fri, 5 Aug 2016 03:01:14 -0700 (PDT) Received: by mail-pa0-x231.google.com with SMTP id ti13so13398803pac.0; Fri, 05 Aug 2016 03:01:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:from:to:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=PQ1M/sgSqKb0MGtp+6dh7EZMDigDnDcx1FCFMy3U5do=; b=zEj+RMs8VdlR1X9THYmRU1LcX/LKObGl5A7pC3qTgLE3tE8CN6jTCcVkm11OQh+xPE DAGB7YzknGFTycyjDkCg7LVOg4YnS8BMXQyVe4Mq/PXStIhOE0SNmV8RqfDKRJDUjc8x tNJ9AYTNVil4HJyHAMZN6ikGuciznokSzTwBnmhddMMz+utPWwup+Gu6ZQrFdQ3CuJLz lU0FxAOZwtREHyrLWIC99+aA0xXg+QKYfXbkahpG0K2iUANNHfzKLXZua+HJUsYq4VrU Uzb1tEh/g8pAjBReBkquCnMYwDkvKNMc8dGzOiw7jLENkN+6hymer+zhtPjimZBtr0HU ABpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:from:to:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=PQ1M/sgSqKb0MGtp+6dh7EZMDigDnDcx1FCFMy3U5do=; b=VtTGuIOS8+3TjCNeJtLsMf8fcPekTooEYmkTbwAw1kSsafoXlvYU2cvDQGcVSmKvAe plenGOyGO3uKjknzpFkVuQhpLkZCMS/WqTocXlbS2dD/YdhkKLhhXkvGROPftBEFTwDZ ThiSlbrAWqBvVE40ngdWpHw5UrV+bk6h4e5TJ7aBSv94v+H7Rj+fWiLq6zukg7Mdf1PJ 3oJsbotJTcUSbpy5s1u33K6hRbCeelRpnBaKHZ9X79WUrT9e3W6zBQgpbe224ecYODQl +i4mhBX8TzDu4RbiK1NmRtmqYZ/gDx6x2F2yrUETBbgDqRsJic3EtVNjmkRHyvd/XUPH xexQ== X-Gm-Message-State: AEkoout9yaxSqHhawhDn1fOv5BjrLfQckjY6iC4at0iVLF6MSxKDaQZ5m1mKszZcDA4lQA== X-Received: by 10.66.43.7 with SMTP id s7mr135577626pal.27.1470391272771; Fri, 05 Aug 2016 03:01:12 -0700 (PDT) Received: from [172.17.202.168] (mtcharleston.intuit.com. [199.16.140.24]) by smtp.gmail.com with ESMTPSA id u72sm26615747pfa.31.2016.08.05.03.01.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Aug 2016 03:01:11 -0700 (PDT) References: <5751B895.1070400@gmail.com> From: Yaron Sheffer To: IETF Security Directorate , The IESG , draft-ietf-isis-rfc4971bis.all@tools.ietf.org X-Forwarded-Message-Id: <5751B895.1070400@gmail.com> Message-ID: <6c9c5a95-61a9-23e3-6df4-8103480fa684@gmail.com> Date: Fri, 5 Aug 2016 13:01:06 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <5751B895.1070400@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [secdir] SecDir review of draft-ietf-isis-rfc4971bis-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 10:01:19 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is a minor update to RFC4971, in order to correctly support IPv6-only routers. Summary The document is ready for publication. Details The Security Considerations are unchanged from the original RFC and cover the router capability feature reasonably. They still seem to describe this quaint world where each router can rely on all its peers to always send correct information. But at least we recommend to use protocol-level integrity mechanisms in "high risk" situations. Thanks, Yaron From nobody Fri Aug 5 04:55:08 2016 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6858212D838; Fri, 5 Aug 2016 04:53:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1470398030; bh=QXalKaGMEl3eqHySUeM+GT873FVGroGE+uzTTo+CIDQ=; h=From:Date:To:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=i9AIh9VziyU17wXV3bguyKeQxLsOj6YKYkvlvtM4AJS1tFbz3CgCbBMPSxtwioEgv Q5AzP6CRSWDNclqiL1kJ1dno5wd1/mU2S/VU56AOT2nh1POEVEB7nQD93XpKl9HrKN x4MpGtL5TjrSGJYUt4O7dLQyA3c6HNZGIJrRPzH4= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B7E12D828 for ; Fri, 5 Aug 2016 04:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPRccNwOm8LF for ; Fri, 5 Aug 2016 04:53:45 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74DBF12D77B for ; Fri, 5 Aug 2016 04:53:45 -0700 (PDT) Received: from [2a01:e34:ed80:f650:c914:eee7:1c8f:42ba] by raoul.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bVdh9-0003mt-LO; Fri, 05 Aug 2016 11:53:43 +0000 From: Coralie Mercier Date: Fri, 5 Aug 2016 13:53:43 +0200 To: new-work@ietf.org Message-Id: <89095492-02CE-4867-985F-E7EDCE6CF3CF@w3.org> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 05 Aug 2016 04:55:08 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Cascading Style Sheets (CSS) Working Group (until 2016-09-02) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 11:53:50 -0000 SGVsbG8sCgpUb2RheSBXM0MgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlcyByZWNl aXZlZCBhIFByb3Bvc2FsCnRvIHJldmlldyBhIGRyYWZ0IGNoYXJ0ZXIgZm9yIHRoZSBDYXNjYWRp bmcgU3R5bGUgU2hlZXRzIChDU1MpIFdvcmtpbmcgR3JvdXA6CiAgaHR0cHM6Ly93d3cudzMub3Jn L1N0eWxlLzIwMTYvY3NzLTIwMTYuaHRtbAoKQXMgcGFydCBvZiBlbnN1cmluZyB0aGF0IHRoZSBj b21tdW5pdHkgaXMgYXdhcmUgb2YgcHJvcG9zZWQgd29yawphdCBXM0MsIHRoaXMgZHJhZnQgY2hh cnRlciBpcyBwdWJsaWMgZHVyaW5nIHRoZSBBZHZpc29yeQpDb21taXR0ZWUgcmV2aWV3IHBlcmlv ZC4KClczQyBpbnZpdGVzIHB1YmxpYyBjb21tZW50cyB0aHJvdWdoIDIwMTYtMDktMDIgb24gdGhl CnByb3Bvc2VkIGNoYXJ0ZXIuIFBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvCnB1YmxpYy1uZXctd29y a0B3My5vcmcsIHdoaWNoIGhhcyBhIHB1YmxpYyBhcmNoaXZlOgogIGh0dHA6Ly9saXN0cy53My5v cmcvQXJjaGl2ZXMvUHVibGljL3B1YmxpYy1uZXctd29yay8KCk90aGVyIHRoYW4gY29tbWVudHMg c2VudCBpbiBmb3JtYWwgcmVzcG9uc2VzIGJ5IFczQyBBZHZpc29yeQpDb21taXR0ZWUgUmVwcmVz ZW50YXRpdmVzLCBXM0MgY2Fubm90IGd1YXJhbnRlZSBhIHJlc3BvbnNlIHRvCmNvbW1lbnRzLiBJ ZiB5b3Ugd29yayBmb3IgYSBXM0MgTWVtYmVyIFsxXSwgcGxlYXNlIGNvb3JkaW5hdGUKeW91ciBj b21tZW50cyB3aXRoIHlvdXIgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlLiBGb3IK ZXhhbXBsZSwgeW91IG1heSB3aXNoIHRvIG1ha2UgcHVibGljIGNvbW1lbnRzIHZpYSB0aGlzIGxp c3QgYW5kCmhhdmUgeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVzZW50YXRpdmUgcmVmZXIg dG8gaXQgZnJvbSBoaXMKb3IgaGVyIGZvcm1hbCByZXZpZXcgY29tbWVudHMuCgpJZiB5b3Ugc2hv dWxkIGhhdmUgYW55IHF1ZXN0aW9ucyBvciBuZWVkIGZ1cnRoZXIgaW5mb3JtYXRpb24sIHBsZWFz ZQpjb250YWN0IFRlYW0gQ29udGFjdHMgQ2hyaXMgTGlsbGV5IDxjaHJpc0B3My5vcmc+IG9yIEJl cnQgQm9zIDxiZXJ0QHczLm9yZz4uCgpUaGFuayB5b3UsCgpDb3JhbGllIE1lcmNpZXIsIEhlYWQg b2YgVzNDIE1hcmtldGluZyAmIENvbW11bmljYXRpb25zCgpbMV0gaHR0cDovL3d3dy53My5vcmcv Q29uc29ydGl1bS9NZW1iZXIvTGlzdAoKCuKAlCAKQ29yYWxpZSBNZXJjaWVyICAtICBXM0MgTWFy a2V0aW5nICYgQ29tbXVuaWNhdGlvbnMgLSAgaHR0cDovL3d3dy53My5vcmcKbWFpbHRvOmNvcmFs aWVAdzMub3JnICszMzYgNDMyMiAwMDAxIGh0dHA6Ly93d3cudzMub3JnL1Blb3BsZS9DTWVyY2ll ci8KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldy13 b3JrIG1haWxpbmcgbGlzdApuZXctd29ya0BpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldy13b3JrCg== From nobody Sun Aug 7 05:49:42 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9BEF12B074; Sun, 7 Aug 2016 05:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.801 X-Spam-Level: **** X-Spam-Status: No, score=4.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFobohqr7XD3; Sun, 7 Aug 2016 05:49:36 -0700 (PDT) Received: from server.inlakscomputers.com (server.inlakscomputers.com [192.163.242.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA25F12B01C; Sun, 7 Aug 2016 05:49:36 -0700 (PDT) Received: from [159.253.189.239] (port=60527 helo=syew.net) by server.inlakscomputers.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1bWMru-00088v-7b; Sun, 07 Aug 2016 13:07:51 +0100 From: ietf To: "saag" , "sarikaya" , "secdir" , "stbryant" Date: Sun, 7 Aug 2016 15:07:15 +0300 Message-ID: <0000b6af5268$f0c79e10$174392b1$@frobbit.se> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0013_014FA189.1E602BED" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdH2B8SwRVwxJgvcqXCNimX4pI5+uA== Content-Language: en-gb X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.inlakscomputers.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - frobbit.se X-Get-Message-Sender-Via: server.inlakscomputers.com: authenticated_id: okoyejo@inlakscomputers.com X-Authenticated-Sender: server.inlakscomputers.com: okoyejo@inlakscomputers.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: [secdir] =?utf-8?q?that_is_so_nice?= X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2016 12:49:38 -0000 ------=_NextPart_000_0013_014FA189.1E602BED Content-Type: multipart/alternative; boundary="----=_NextPart_001_0014_014FA189.1E602BED" ------=_NextPart_001_0014_014FA189.1E602BED Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sIA0KDQpIYXZlIHlvdSBhbHJlYWR5ICBzZWVuIHRoYXQgbmljZSBzdHVmZj8gT2gsIHlv dSd2ZSBnb3QgdG8gdGFrZSBhICBsb29rIDxodHRwOi8vb3B0aW9uLmFieXNhY2suY29tL2U0dml3 eT4NCg0KU3BlYWsgdG8geW91IGxhdGVyLCBpZXRmDQo= ------=_NextPart_001_0014_014FA189.1E602BED Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

<= span lang=3DEN-US>Hello,

 

Have you already seen that nice stuff? Oh, you've got = to take a look http://op= tion.abysack.com/e4viwy

=  

Speak to you later, ietf

<= p class=3DMsoNormal> 

------=_NextPart_001_0014_014FA189.1E602BED-- ------=_NextPart_000_0013_014FA189.1E602BED Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgMCAgMDAwMEAwMEBQgFBQQEBQoHBwYIDAoMDAsK CwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIUFRT/2wBDAQMEBAUEBQkFBQkUDQsNFBQUFBQU FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBT/wAARCACAAIADASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9M5Ha OuW8U61fDU9L0HTJfs+oan5sj3QUM1paxgebMqsNrPukhjUHOGmDlXVGU9HJvrkNM/f/ABc1zzP3 n2XQ9P8AI3c+V5txeebs/u7/ACYd2PveUmc7Rj5mPc9ZjJYm+HN5p0lvdX11oN9dx2d1HqN7Ndva yyHZDMkkrPIQ8hihaPJUeYrjYFkMnayTvs+SuQ+MPyfCnxfMvE1tpVzdQSD70U0cbSRSKf4XR1Vl YchlBGCBXZlN9N6pMNEyDzZKfJ1SiSOjL/3KgoETzE+/R5f+3RHH8lP2fP8A7dBBYST+/RIRJVd5 KZHPmtOcnkCT+/TJJPnp874SmR1maE+/zEoj3/cqOP8AeVJ5iVqSHl0tO++KT7ifLQK494d9cZf2 yaF8UNOuzxba/Ytpru3OLm3Lz26IByN0Ul8zE5H7lBlScP2G/P3XqhrWl2mvadLY30TPDJgkBirK ykMrqykMjqwDKykMrKCCCAa1TpomzOZ+KqfafC/9gJzN4inTR9g4YwyAm5ZSeFdLZbiRS3G5AMMS Fbr/ADPkrntF8KDSLt7681O917UjGYUvdREIeKIkExosUcaKCwBYhdzbV3EhEC7qf6w1zt9EaLzJ /lpknWjy/nqU9KkYu2momKd/DT460UCCtJH/AAUz7P8A3KuTOmyqfmU5gncelp8n36kTZv2VBG7x vVp3wlAED0Uf8Dp/yx1kWMj61Mjp/wADqGTrRHJ8n3KIEvUI5NlD/vH+SmR/vKsoiUQArf79R/6u rT7E/wB+ofL/AHlBQRyVN2/v1D5fz7KI/wB3QA+T5/kqPzNn3KnfvVKT/WUTAuxyefTPL8x6gt5H 31aRMVpAkHj+d6Z5fz1Z2H1NM3lKfIK5D/q6Z5n7yrWBTPL+esuQdyOT++lEibPn/jp7/wB/+CmT vvoAZ5f7yp46jj/eP9+jy/LetQJE+8al2JTNi/fpjz4o/hi3Cb7wpRIn8FG/f9+oPL+f5KBll/kT 5KZJH5m/fTI/9+pk+4KBbFb5PMq1uqDy/Lf5EooGPST+9T5upqt/HU0H9yl7QB8NOqP/AHEoL7Kz 5xWHyfx1U+z/AD/PU8bvvofZG/361DYXZs+/T2++KN/yZqOOfzE+5QAyPfs2U94Pnp8ju/yLTfn2 UwDY9P8AL/2Kg/1cdM+0PvpDJ3/v0nmeW3z0zzKe8fn/AD0ADz4qrHJ5j1agj3w7Ho+yeX9ylyc4 iG4jp/l/J89TOlVY4/n2PR7MZJG+yPfRJGkn+/VnZ8lQvJ/do5BXDZ8uKZ/rPkR6ZHI/8dTRps+9 WYyGnx/f2VJ5fyURx/x0cgD/ALgpju+P9ukkn/2Pnp6fOlai9St5nmUSfvPnqbyEP3qJETZ9+lyD GeX/AN9095/k2JTJP9ZTPn37KYD4/wDWVP8APUcaPHUjps/jpiGI+Xojf5P9uneYm/ZnmmPB/wB8 UgIfnkf/AKZ09JNlM8t9nyU+PolZDH/LRvFMk/1dEm+RE2UAEcjmrP30pdiPUE52PWv8MncWSPzH qOp9/mJTI6Bj9n956g/1j/PUkj4pn8dAxJN9PgGQj0v+sTZRJ8j/AC0wJd6PQ5xVaP8Av1NG7fc/ jq+cm1hfLR/9+jY+/wC/8lQXH7unpOhT/bqBhOn8dM+z+XSySUn2j+5SGLJHTk/do++mR9anKb6B Mc+16h+Sepv9779RP/s0VAQBNlR/8s9+yl/jqwifLS5AbsZ8f7x6upsRaZ5ab/uU/euadMGCJ8m6 oZJHxvSrPnJULp82xK0mCfcPPT+4aZv/AI6PstEkf9ysvfGEkm+iOPy6ZT/9ZWYBJ8n++9M/1aVa +zmmSW/7utOQXOV0/wBYavx/JVDzHR/kqx5j+XRAJn//2Q== ------=_NextPart_000_0013_014FA189.1E602BED-- From nobody Sun Aug 7 08:43:10 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78D912D0ED for ; Sun, 7 Aug 2016 08:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJAsL_mZAs0D for ; Sun, 7 Aug 2016 08:43:04 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C05A12D0BF for ; Sun, 7 Aug 2016 08:43:04 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id v123so170298320qkh.3 for ; Sun, 07 Aug 2016 08:43:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=3ho9s/1np6+oboFQvQ2Zum/ks38d30dRkuiHIKap/+0=; b=fNvYPZz4jtt1yGCOpMHc4WWLLIhkxph1ABn+r+xbtsthBOHONn70Kc9X25xYAbCbog AEFXlFYIK96gHO0vdF+16bM63EWrVFPeNzJhqGTqFIvhVPRe182AXIoZ9tHPghzzoie5 VHbGvUYwVhmo7a5Cs618z23Qrc5CiBAm5GZ5E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=3ho9s/1np6+oboFQvQ2Zum/ks38d30dRkuiHIKap/+0=; b=geW/sxPi5MCrflZNFIFXIAJ8OwZyCdnysLkEGbySCj9PTe03ARcdN1wekMrtOq2NdE GyXbhZtE9CiqcKeSefG/mMdT5fYWgWiY1AMR7sdIjoUR9SU9L/4fmXVrXGUkqfvwYdGC l2R7goBTad01cJ/DoIscFU67+lIXKKxU5PaDttQe93AmrwLywzdGzG+Arj9GEisWq+Yy hWNb72w1UC3X7kSJ+LJotf96pYG1OTZjWvYz6V5Tj/bsh5S8wJFez4Jog41g5aW07wcd 9o01RbSBddxSxR+zhnsUB80hKQuttPzfRKQ4qpvdxr0lMxot+kbopMAKqylUcJ6d1mu7 z1mg== X-Gm-Message-State: AEkoousnQHw3p9I193jxZhQWBCc834vyv83DOKfdEirETnU4crGZJVimJfbYHkfm9jfONA== X-Received: by 10.55.94.135 with SMTP id s129mr22235245qkb.80.1470584583518; Sun, 07 Aug 2016 08:43:03 -0700 (PDT) Received: from [172.16.0.112] (pool-173-73-123-93.washdc.east.verizon.net. [173.73.123.93]) by smtp.gmail.com with ESMTPSA id 55sm15170034qtp.32.2016.08.07.08.43.02 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 07 Aug 2016 08:43:02 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <242FE537-8205-4CAC-85BD-AC9CB740AFC4@sn3rd.com> Date: Sun, 7 Aug 2016 11:43:01 -0400 To: draft-dekok-radext-datatypes.all@ietf.org, The IESG , secdir@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [secdir] secdir review of draft-dekok-radext-datatypes X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2016 15:43:07 -0000 All, I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. This document is essentially one long IANA consideration; the document = defines an IANA registry for data types, and updates the RADIUS = Attribute Type registry to use those newly defined data types. It=E2=80=99= s not just busy work though because the document does recommend = implementations should use the data types. Finally, this document = mandates no changes to any RADIUS implementation. Summary: ready nits (take =E2=80=98em or leave =E2=80=98em, but please don=E2=80=99t = hold anything up for these): s2.1.4:r/a new data type, it should follow the/a new data type, it = SHOULD follow the s2.1.4: r/fields =E2=80=9CName=E2=80=9D, =E2=80=A6 /field=E2=80=99s = =E2=80=9CName=E2=80=9D, =E2=80=A6 s2.1.4:r/The "Value" field should be given as to be determined or = =E2=80=9CTBD=E2=80=9D in specifications./The "Value" field SHOULD be "to = be determined" or =E2=80=9CTBD". spt= From nobody Mon Aug 8 06:36:00 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0919512D0DD; Mon, 8 Aug 2016 06:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.769 X-Spam-Level: X-Spam-Status: No, score=-15.769 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQ_K86rKtF2d; Mon, 8 Aug 2016 06:35:52 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40DB312D7FD; Mon, 8 Aug 2016 06:35:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1692; q=dns/txt; s=iport; t=1470663336; x=1471872936; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=tl4tnlV4W/b3cNXrmLnqBHb7f5VqscuWJ4e4+2/TUtI=; b=ZUUpxmOdEYYAjmHzL62nWpCJh9Md8DApTJcBv/HEqN2eNcWey1yqcUzc XEL2pHZfUKrNYedJBxu1Gwgb+BiChu1BWyDCfZgNxbRyV9CXCEhIkP8Hs gJg07hM3l/BKE0wP1KTBWmaqh6MVE9TlMP3Dt2xUiGy9F44Lm65it/FcF Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASAgDqiahX/5JdJa1dg0WBUgesY4wog?= =?us-ascii?q?X2GHQIcgR44FAEBAQEBAQFdJ4ReAQEFIxFRBAIBCBEEAQEDAiMDAgICHxEUAQg?= =?us-ascii?q?IAgQBEgiIDwMXshaLSg2ENwEBAQEBAQEBAQEBAQEBAQEBAQEBARyBAYUphE2CQ?= =?us-ascii?q?4R+gloFk3WFEDQBiRiDNoI0gXKNWIZkgUmEB4N3AR42g3puAYZffwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,490,1464652800"; d="scan'208";a="138971696" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Aug 2016 13:35:35 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u78DZZnd031722 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 8 Aug 2016 13:35:35 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 8 Aug 2016 08:35:34 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Mon, 8 Aug 2016 08:35:34 -0500 From: "Les Ginsberg (ginsberg)" To: Yaron Sheffer , IETF Security Directorate , The IESG , "draft-ietf-isis-rfc4971bis.all@tools.ietf.org" Thread-Topic: SecDir review of draft-ietf-isis-rfc4971bis-01 Thread-Index: AQHR7wBy8GKk5jMb70GIfEBKnuFC4aA/FUyQ Date: Mon, 8 Aug 2016 13:35:34 +0000 Message-ID: References: <5751B895.1070400@gmail.com> <6c9c5a95-61a9-23e3-6df4-8103480fa684@gmail.com> In-Reply-To: <6c9c5a95-61a9-23e3-6df4-8103480fa684@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.91.7] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] SecDir review of draft-ietf-isis-rfc4971bis-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 13:35:53 -0000 WWFyb24gLQ0KDQpUaGFueCBmb3IgeW91ciByZXZpZXcuDQoNCiAgIExlcw0KDQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogWWFyb24gU2hlZmZlciBbbWFpbHRvOnlhcm9u Zi5pZXRmQGdtYWlsLmNvbV0NCj4gU2VudDogRnJpZGF5LCBBdWd1c3QgMDUsIDIwMTYgMzowMSBB TQ0KPiBUbzogSUVURiBTZWN1cml0eSBEaXJlY3RvcmF0ZTsgVGhlIElFU0c7IGRyYWZ0LWlldGYt aXNpcy0NCj4gcmZjNDk3MWJpcy5hbGxAdG9vbHMuaWV0Zi5vcmcNCj4gU3ViamVjdDogU2VjRGly IHJldmlldyBvZiBkcmFmdC1pZXRmLWlzaXMtcmZjNDk3MWJpcy0wMQ0KPiANCj4gSSBoYXZlIHJl dmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUn cyBvbmdvaW5nDQo+IGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHBy b2Nlc3NlZCBieSB0aGUgSUVTRy4NCj4gVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1h cmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWENCj4gZGlyZWN0b3JzLiAg RG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50 cw0KPiBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCj4gDQo+IFRoaXMg ZG9jdW1lbnQgaXMgYSBtaW5vciB1cGRhdGUgdG8gUkZDNDk3MSwgaW4gb3JkZXIgdG8gY29ycmVj dGx5IHN1cHBvcnQNCj4gSVB2Ni1vbmx5IHJvdXRlcnMuDQo+IA0KPiBTdW1tYXJ5DQo+IA0KPiBU aGUgZG9jdW1lbnQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLg0KPiANCj4gRGV0YWlscw0KPiAN Cj4gVGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIGFyZSB1bmNoYW5nZWQgZnJvbSB0aGUgb3Jp Z2luYWwgUkZDIGFuZCBjb3Zlcg0KPiB0aGUgcm91dGVyIGNhcGFiaWxpdHkgZmVhdHVyZSByZWFz b25hYmx5LiBUaGV5IHN0aWxsIHNlZW0gdG8gZGVzY3JpYmUgdGhpcw0KPiBxdWFpbnQgd29ybGQg d2hlcmUgZWFjaCByb3V0ZXIgY2FuIHJlbHkgb24gYWxsIGl0cyBwZWVycyB0byBhbHdheXMgc2Vu ZA0KPiBjb3JyZWN0IGluZm9ybWF0aW9uLiBCdXQgYXQgbGVhc3Qgd2UgcmVjb21tZW5kIHRvIHVz ZSBwcm90b2NvbC1sZXZlbA0KPiBpbnRlZ3JpdHkgbWVjaGFuaXNtcyBpbiAiaGlnaCByaXNrIiBz aXR1YXRpb25zLg0KPiANCj4gVGhhbmtzLA0KPiAJWWFyb24NCg== From nobody Mon Aug 8 08:17:53 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719DE12D624; Mon, 8 Aug 2016 08:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNqciejhMm3h; Mon, 8 Aug 2016 08:17:51 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51CF312D623; Mon, 8 Aug 2016 08:17:49 -0700 (PDT) Received: from unnumerable.local ([173.57.161.14]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u78FHmR8054911 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Mon, 8 Aug 2016 10:17:48 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.57.161.14] claimed to be unnumerable.local To: General Area Review Team , "secdir@ietf.org" , "ietf@ietf.org" , manet@ietf.org, draft-ietf-manet-smc-sec-threats.all@ietf.org From: Robert Sparks Message-ID: Date: Mon, 8 Aug 2016 10:17:48 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [secdir] Combined Gen-art and secdir LC review: draft-ietf-manet-smc-sec-threats-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 15:17:52 -0000 I am the assigned Gen-ART and secdir reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. The secdir does the same for the security area directors. Please treat these comments just like any other last call comments. For more information on Gen-Art, please see the FAQ at . For moe information on secdir, see the wiki at Document: draft-ietf-manet-smf-sec-threats-05 Reviewer: Robert Sparks Review Date: 8 Aug 2016 IETF LC End Date: 11 Aug 2016 IESG Telechat date: 18 Aug 2016 Summary: Ready for publication as an Informational RFC This draft provides a discussion of vulnerabilities in Simplified Multicast Forwarding (SMF), focusing on attacking the Duplicate Packet Detection and Relay Set Selection mechanisms. It positions itself as being useful information for those deploying SMF as currently defined. It does not propose mitigations, but does have a section that identifies potential future work that might. I have sent several editorial nits directly to the authors. From nobody Mon Aug 8 08:33:26 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C762712D18D; Mon, 8 Aug 2016 08:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hij9bGkTp1YH; Mon, 8 Aug 2016 08:33:23 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 212B912B044; Mon, 8 Aug 2016 08:33:22 -0700 (PDT) Received: from unnumerable.local ([173.57.161.14]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u78FXLDU056439 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Mon, 8 Aug 2016 10:33:21 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.57.161.14] claimed to be unnumerable.local To: General Area Review Team , "secdir@ietf.org" , draft-ietf-manet-smf-sec-threats.all@ietf.org References: From: Robert Sparks Message-ID: <597043f8-f24a-df96-43bc-06a8d3142bf7@nostrum.com> Date: Mon, 8 Aug 2016 10:33:21 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] Combined Gen-art and secdir LC review: draft-ietf-manet-smc-sec-threats-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 15:33:25 -0000 Resending (to a subset of the original distro) correcting a typo in the draft name to make this easier to search for later. RjS On 8/8/16 10:17 AM, Robert Sparks wrote: > I am the assigned Gen-ART and secdir reviewer for this draft. The > General Area > Review Team (Gen-ART) reviews all IETF documents being processed by > the IESG > for the IETF Chair. The secdir does the same for the security area > directors. > Please treat these comments just like any other last call comments. > > For more information on Gen-Art, please see the FAQ at > . > > For moe information on secdir, see the wiki at > > > Document: draft-ietf-manet-smf-sec-threats-05 > Reviewer: Robert Sparks > Review Date: 8 Aug 2016 > IETF LC End Date: 11 Aug 2016 > IESG Telechat date: 18 Aug 2016 > > Summary: Ready for publication as an Informational RFC > > This draft provides a discussion of vulnerabilities in Simplified > Multicast > Forwarding (SMF), focusing on attacking the Duplicate Packet Detection > and > Relay Set Selection mechanisms. It positions itself as being useful > information > for those deploying SMF as currently defined. It does not propose > mitigations, > but does have a section that identifies potential future work that might. > > I have sent several editorial nits directly to the authors. > From nobody Mon Aug 8 09:56:12 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06EAF12D84B; Mon, 8 Aug 2016 09:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsQjT-Me5TgX; Mon, 8 Aug 2016 09:56:05 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0136.outbound.protection.outlook.com [23.103.200.136]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3871612D66F; Mon, 8 Aug 2016 09:56:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1wPWlx4JPnGXwm/JfQnDOLZyscRIgDR0vE/uedQf6aw=; b=je5J5x0mEMP+5fLwbNlSrEOdM6RqwMk36z1RGCMc6tp92dyJfP3myk5qAIvkKvWJ5rl4iBoueU+spzZzxbZC8JdYiUAYiCerhPN0nmyrm5P3ixQ6MXUjGBuHUtRoIpqcswpbeYRDjsiMlael8e0jeQ5VkynWzLN6XO5v1g4hv1M= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1439.namprd09.prod.outlook.com (10.173.50.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Mon, 8 Aug 2016 16:56:00 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.0549.025; Mon, 8 Aug 2016 16:56:00 +0000 From: "Waltermire, David A. (Fed)" To: "secdir@ietf.org" , "'iesg@ietf.org'" , "draft-ietf-tram-turn-mobility.all@ietf.org" Thread-Topic: Secdir review of draft-ietf-tram-turn-mobility-03 Thread-Index: AdHxlZAf0viCeDMrR7KVHzNfcwAdaA== Date: Mon, 8 Aug 2016 16:55:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.224.58] x-ms-office365-filtering-correlation-id: 447a1b7e-fe8d-4474-90d6-08d3bfacdfd7 x-microsoft-exchange-diagnostics: 1; MWHPR09MB1439; 6:m84n/SWJL5V0FfNwGtGTBYq/Rs7/28jSFaAFnBJRaPQdskdPSCMSi+QMRYtc1jHkCnc9+NtweNMxMlBzWtWD03kFqilARd6qMQsOh/OEsqIfpp3C4OYsBHIr6b6o4rv62YvqjmY7Un3Vwffieykf/qWKrnDGH3SQzYjEoo22P9lm6+H4rhuvJ4HZWlCva3XLWP9ecCuVD0oHEbajkKIWAsQhSepvYkUwTHyp/8rxcf4Aqf+8TqGwG6BTkhR4Rqk6CEUa1yEKsx/NreLdjbA2/5rU2590Zt7sHfMBQTsmskOqdVniZ2+L52UIKH7Lua8B9Mn+x4c+soRCvV/P5JoFmg==; 5:/Ra89pZSJ92VDCLJYBnyF4bdrT27A46yS1QPjJtm6Akg/S4UMJuZWocxkHul3aTG/6MoNIB7w5nbt9D2xs9XSeR+Pfasj2O0xFVEmveNNeGdIeWjRDTzkhGhkG34ljxO/8jjTKrahKH8dYJqAnOuWQ==; 24:Bx9B3mGaBsnkbYBWvSXYfEWd1ke7y4uY1C8qGdHJKLJ/grA6nzlNfxWAgLxIKissly9NS8V/K5eWkF3Sy6bQ88+X2ob3BVqgwLjNfwujNmM=; 7:Bt7DmTwW/j57dNx930CdMgRIQR7aWz3Yb9UL0OvGkw5Ck3a20zc92vnh8tK+6h4AGAEKqyE0M8snHh6bx6uQVvNSMLnuZ+BUOQMqB0SqeJ1RfzA221aVyySVJuBaEAQx2RFq8KOqGXzV9wjqi66azFq1cRFdZSGglO/Bmq0G2h0P66R1A0PgDbFcrvCBQjNmxh/AAV5ZU7228rU9kmqhw4Yz/w1xSCgOw9Qx3YyEMxpUnMipasPqVY4/2nOq1xQI x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR09MB1439; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:MWHPR09MB1439; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1439; x-forefront-prvs: 00286C0CA6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(10400500002)(229853001)(2906002)(101416001)(68736007)(2900100001)(122556002)(106356001)(33656002)(5001770100001)(3660700001)(97736004)(99286002)(77096005)(107886002)(105586002)(189998001)(92566002)(86362001)(87936001)(3280700002)(230783001)(102836003)(586003)(7696003)(66066001)(3846002)(6116002)(50986999)(2501003)(8676002)(8936002)(74316002)(305945005)(81156014)(54356999)(5002640100001)(9686002)(11100500001)(81166006)(7846002)(450100001)(7736002)(76576001)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1439; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Aug 2016 16:55:59.7446 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1439 Archived-At: Subject: [secdir] Secdir review of draft-ietf-tram-turn-mobility-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 16:56:07 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. Summary: ready with nits. This standards track draft describes a mechanism for a Traversal Using Rela= ys around NAT (TURN) client to re-associate with a TURN server after the cl= ients IP address and/or port changes allowing previous allocations to be ke= pt. This helps to support IP address mobility in a way that is transparent = and seamless to remote peers. I found that the draft clearly articulates the problem it is trying to solv= e. The security considerations seem to be appropriate for the draft. The following are minor nits and editorial issues with the draft that would= be good to address before progressing the draft: In section 1, second paragraph, STUN should be spelled out on its first use= and an informative reference to RFC 7635 should be included. In section 2, there is an extra space s/[RFC5245] , and the/[RFC5245], and = the/. Similar issues exist throughout the document which also need to be fi= xed.=20 The phase "TBD (Mobility Forbidden)" is used in section 3.1.4 and in other = parts of the document as a placeholder for the 405 Mobility Forbidden STUN = Error Code requested in the IANA considerations. While the actions to be ta= ken by IANA are clear, the TBD placeholders should be filled in with what i= s expected to be assigned by IANA before the draft progresses. Regards, Dave Waltermire From nobody Mon Aug 8 21:11:07 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59F412D74E; Mon, 8 Aug 2016 21:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.768 X-Spam-Level: X-Spam-Status: No, score=-15.768 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wf0wTiNC3nTk; Mon, 8 Aug 2016 21:11:00 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8F2312D728; Mon, 8 Aug 2016 21:10:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2294; q=dns/txt; s=iport; t=1470715859; x=1471925459; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=qDAfKxp2y0ielNRG42U4yQVt/adqE4mL0vY2W4I+BkY=; b=NnLn6Uo+RsQWfuTlza+FcjK7kYvwaMX94/F2SfN5aCh7nDaGB/c94NBg EMufxYErQMa293WAkb9ULCLdvyOcvyiVtxtpJgvX7M1zOi/hhLl0JeM5L nb+BgZeDCUHqjbu70BzBMNQN3famf3HTfKTd3nNXHCmcjBJKrJTTcHocm Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAgA5V6lX/5pdJa1dg0WBUge5GIF9h?= =?us-ascii?q?h0CgUU4FAEBAQEBAQFdJ4ReAQEEATpEBwQCAQgRBAEBHwkHMhQJCAEBBAESCIg?= =?us-ascii?q?hCMMqAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIYqhE2EKoVxBZN1hUQBjwKBcoRbi?= =?us-ascii?q?H2MNIN3AR42g3puhXd/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,493,1464652800"; d="scan'208";a="135733727" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Aug 2016 04:10:58 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u794Awas032389 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 9 Aug 2016 04:10:59 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 8 Aug 2016 23:10:58 -0500 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1210.000; Mon, 8 Aug 2016 23:10:58 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "Waltermire, David A. (Fed)" , "secdir@ietf.org" , "'iesg@ietf.org'" , "draft-ietf-tram-turn-mobility.all@ietf.org" Thread-Topic: Secdir review of draft-ietf-tram-turn-mobility-03 Thread-Index: AdHxlZAf0viCeDMrR7KVHzNfcwAdaAAW8uLw Date: Tue, 9 Aug 2016 04:10:57 +0000 Message-ID: <97ae9a43544a4144aaddde0c476f73d5@XCH-RCD-017.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.32.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-tram-turn-mobility-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 04:11:01 -0000 Thanks for the review. Please see inline > -----Original Message----- > From: Waltermire, David A. (Fed) [mailto:david.waltermire@nist.gov] > Sent: Monday, August 8, 2016 10:26 PM > To: secdir@ietf.org; 'iesg@ietf.org' ; draft-ietf-tram-tur= n- > mobility.all@ietf.org > Subject: Secdir review of draft-ietf-tram-turn-mobility-03 >=20 > I have reviewed this document as part of the security directorate's ongoi= ng > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments ju= st > like any other last call comments. >=20 > Summary: ready with nits. >=20 > This standards track draft describes a mechanism for a Traversal Using Re= lays > around NAT (TURN) client to re-associate with a TURN server after the cli= ents > IP address and/or port changes allowing previous allocations to be kept. = This > helps to support IP address mobility in a way that is transparent and sea= mless > to remote peers. >=20 > I found that the draft clearly articulates the problem it is trying to so= lve. The > security considerations seem to be appropriate for the draft. >=20 > The following are minor nits and editorial issues with the draft that wou= ld be > good to address before progressing the draft: >=20 > In section 1, second paragraph, STUN should be spelled out on its first u= se=20 Updated. > and > an informative reference to RFC 7635 should be included. Informative reference to RFC 7635 is already included in the draft. >=20 > In section 2, there is an extra space s/[RFC5245] , and the/[RFC5245], an= d > the/. Similar issues exist throughout the document which also need to be > fixed. Thanks, fixed. >=20 > The phase "TBD (Mobility Forbidden)" is used in section 3.1.4 and in othe= r > parts of the document as a placeholder for the 405 Mobility Forbidden STU= N > Error Code requested in the IANA considerations. While the actions to be > taken by IANA are clear, the TBD placeholders should be filled in with wh= at is > expected to be assigned by IANA before the draft progresses. Yes. -Tiru >=20 > Regards, > Dave Waltermire From nobody Mon Aug 8 22:26:59 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E5612D0B6; Mon, 8 Aug 2016 22:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80L-rUuaFzCB; Mon, 8 Aug 2016 22:26:52 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8150512B062; Mon, 8 Aug 2016 22:26:52 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id o80so9822959wme.1; Mon, 08 Aug 2016 22:26:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=mCN4j1P3fVV2tK++DmY+4VEc07/Q3v6Uj73vTAi41is=; b=VXNfKyOC9sRtY7egGHG5/PjPZlmNJzhB22ChdPknwew/28vBQXK8TADVC5uoXYHhYV wX9Sxau/hCcbakuO4wn4lZfU7Lvn+1dZcYeuiYRqTy2bPCLpqRIELjtsFKLvXP9L/Q+B gZKZrChBXn4/msixjqheTYY0Ih3fm8y38BscZGFa/tfleNvScaYhv1G5Lv9Qdn4FpRSr lHlcL8FnkQZwXhkrntHhxFMpEu5CIOTZrQ0+PulpIp/Pao/Z7nNDEsGIPg2LcFGmFHoD 0XYfjHw1p4BbSO85isW3e3V1/A1bci/WrmSIysmxjlJ5X7Uhee0iaRD0ywNEBbILVN8T 0wfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=mCN4j1P3fVV2tK++DmY+4VEc07/Q3v6Uj73vTAi41is=; b=DwBLBQ/iVH0rjzh/6YYxoSHvtjpHbQypxfku9AL906M5ae0UjmSxjjokCGjVDkuKgY SuUF3IepO6dceQOA/b8X1XLKvNFqV9ys3B7xd963Ex/8jL44gjoKG70Czw6GMIEmNdXJ uBUfQz+Rh3RhF6kh90n3ram4oLlGePJWTT2NvR+Rm67p1qsbQ32lAMRpR7zYD0LLwcPC PHzkHIgHWI4vyY4m5XSUtGYlWNKhbcJhSK3uTxRWm1TrBbC2GnJYUU3r6TW1LXv/iPaz Xeg1W2W61BbV0zeaEWU9koPpWxQCtgI4Yzl50eP9UoegSmpQyDxwJSKLmMCMURq7GcTU Oi3Q== X-Gm-Message-State: AEkoouuSAoGiM6+MyaiJgvawVVcDrgghpqBKFafKILRsPrrZHPUxQ5cCrrjkIGXKgzQljA== X-Received: by 10.28.47.199 with SMTP id v190mr19761059wmv.28.1470720410832; Mon, 08 Aug 2016 22:26:50 -0700 (PDT) Received: from [192.168.137.252] ([176.13.19.237]) by smtp.gmail.com with ESMTPSA id 207sm1382701wmb.7.2016.08.08.22.26.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 08 Aug 2016 22:26:49 -0700 (PDT) From: Yoav Nir Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 9 Aug 2016 08:26:41 +0300 To: secdir , The IESG , draft-seantek-ldap-pkcs9.all@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [secdir] SecDir Review of draft-seantek-ldap-pkcs9-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 05:26:54 -0000 Note: I was assigned draft-seantek-ldap-pkcs9-05, but since version -06 = was available, I reviewed that. Summary: Ready with nits The draft adds definitions from PKCS#9 to the IANA registry for LDAP. As = such, the IANA Considerations section is the largest and most important = type. The OIDs in the draft have already been defined in RFC 2985 = (PKCS#9), which has a good Security Considerations, especially = considering that it was written in 2000. Security considerations for = this document are mostly those for LDAP and for PKCS#9. Beyond regular LDAP security considerations, some of the attributes = defined in this draft are privacy-sensitive. Section 6 calls out = dateOfBirth and placeOfBirth, but the same could be said for gender and = countryOfResidence, among others.=20 I would have liked slightly stronger language than "may be subject to = privacy laws in certain jurisdictions=E2=80=9D. More like =E2=80=9Care = sensitive and the information should never be stored or transmitted = unencrypted=E2=80=9D One nit about the structure. I believe sections 2, 3, and 5, each = occupying less than two lines could all be combined into a single = paragraph in the Introduction. Yoav From nobody Mon Aug 8 23:03:47 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CACF12B075; Mon, 8 Aug 2016 23:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFPF_SFIoUXA; Mon, 8 Aug 2016 23:03:42 -0700 (PDT) Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89CC812B062; Mon, 8 Aug 2016 23:03:42 -0700 (PDT) Received: from in01.mta.xmission.com ([166.70.13.51]) by out03.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1bX08a-0007cr-Vu; Tue, 09 Aug 2016 00:03:41 -0600 Received: from [72.250.219.84] (helo=rumpleteazer.rhmr.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1bX08a-0003IZ-4f; Tue, 09 Aug 2016 00:03:40 -0600 Received: from rumpleteazer.rhmr.com (localhost [127.0.0.1]) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id u7962nSk025111; Tue, 9 Aug 2016 00:02:49 -0600 Received: (from hilarie@localhost) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Submit) id u7962mQc025110; Tue, 9 Aug 2016 00:02:48 -0600 Date: Tue, 9 Aug 2016 00:02:48 -0600 Message-Id: <201608090602.u7962mQc025110@rumpleteazer.rhmr.com> From: "Hilarie Orman" To: iesg@ietf.org X-XM-SPF: eid=1bX08a-0003IZ-4f; ; ; mid=<201608090602.u7962mQc025110@rumpleteazer.rhmr.com>; ; ; hst=in01.mta.xmission.com; ; ; ip=72.250.219.84; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-XM-AID: U2FsdGVkX1/idD172fKFEnYK/1QDBR8f X-SA-Exim-Connect-IP: 72.250.219.84 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ***;iesg@ietf.org X-Spam-Relay-Country: X-Spam-Timing: total 397 ms - load_scoreonly_sql: 0.06 (0.0%), signal_user_changed: 4.5 (1.1%), b_tie_ro: 3.3 (0.8%), parse: 3.1 (0.8%), extract_message_metadata: 8 (1.9%), get_uri_detail_list: 1.52 (0.4%), tests_pri_-1000: 4.1 (1.0%), tests_pri_-950: 1.50 (0.4%), tests_pri_-900: 1.18 (0.3%), tests_pri_-400: 24 (6.0%), check_bayes: 22 (5.6%), b_tokenize: 6 (1.5%), b_tok_get_all: 7 (1.6%), b_comp_prob: 2.8 (0.7%), b_tok_touch_all: 3.2 (0.8%), b_finish: 1.26 (0.3%), tests_pri_0: 341 (85.9%), check_dkim_signature: 0.79 (0.2%), check_dkim_adsp: 44 (11.0%), tests_pri_500: 6 (1.5%), rewrite_mail: 0.00 (0.0%) X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Archived-At: Cc: draft-ietf-avtext-rid.all@tools.ietf.org, secdir@ietf.org Subject: [secdir] Security review of draft-ietf-avtext-rid-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Hilarie Orman List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 06:03:43 -0000 Security review of RTP Stream Identifier Source Description (SDES) draft-ietf-avtext-rid-04 Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. We begin by quoting from the document: "Abstract This document defines and registers two new RTCP SDES items. One, named RtpStreamId, is used for unique identification of RTP streams. The other, RepairedRtpStreamId, can be used to identify which stream a redundancy RTP stream is to be used to repair. Security considerations: The actual identifiers used for RtpStreamIds (and therefore RepairedRtpStreamIds) are expected to be opaque." "Opaque" seems to mean "no one cares what it is." Nonetheless, a protocol should give some guidance about this. Taking the value from a global 64-bit counter, for example, could leak information about the global state of the machine. Having a short counter for each session with a starting value of 0 would probably be OK. Having a short counter start at a random value and wraps around would probably be OK. The "terminology" section could be improved by EAFMA and RUP (expanding a few more acronyms and removing unused phrases). MSID and SSRC are not expanded; "encoded stream" is never used. Hilarie From nobody Tue Aug 9 02:24:18 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2A712D0DA; Tue, 9 Aug 2016 02:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thomasclausen.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSTFLqoY-nkP; Tue, 9 Aug 2016 02:24:16 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED0E612D0AE; Tue, 9 Aug 2016 02:24:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id B372D240E93; Tue, 9 Aug 2016 02:24:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1470734655; bh=aWK5riFpFYKJvpm7zzn5sWydYFSmVurbaMcmS9q1GtU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=k3A69lnNVA12SSWpuaDDsFlExDV7gvn+oyZjH9s44UOqCvHJu2nyFefbSBzTELosb QNKHz7arc0dxj5Ysjmidvx40l2DUCiytJGuvVWBenZtU1+ncrtR96MpwV1Z3eQjK0v q1AzUl+gSKWbRgAPiQOL3bPBs8ogYV8/WpRtrpW8= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [10.44.183.161] (unknown [37.165.31.6]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id A1D74240302; Tue, 9 Aug 2016 02:24:14 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-91E7CF33-EDA5-4D62-9731-2C34A1C54FC1 Mime-Version: 1.0 (1.0) From: Thomas Clausen X-Mailer: iPhone Mail (14A5322e) In-Reply-To: Date: Tue, 9 Aug 2016 11:24:10 +0200 Content-Transfer-Encoding: 7bit Message-Id: <13F5D40F-712E-4970-9CBF-B0E6A1A13F2D@thomasclausen.org> References: To: Robert Sparks Archived-At: Cc: General Area Review Team , manet@ietf.org, "ietf@ietf.org" , draft-ietf-manet-smc-sec-threats.all@ietf.org, "secdir@ietf.org" Subject: Re: [secdir] [manet] Combined Gen-art and secdir LC review: draft-ietf-manet-smc-sec-threats-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 09:24:17 -0000 --Apple-Mail-91E7CF33-EDA5-4D62-9731-2C34A1C54FC1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Robert, all, Thank you for this review. Much appreciated. As I understand it, there are n= o major issues to address? If it is alright with you (& with our AD), We propose to fold the "nits" (as= you call them) that you found in with a couple of "nits" raised by Alvaro a= lready, and with whatever else the ongoing LC raises, and spin a revision ca= pturing it all when the LC is closed? Thanks again for your help, Thomas -- Thomas Heide Clausen =E2=80=A2 @thclausen =E2=80=A2 thomasclaus= en.org=20 www.arkko.com/tools/allstats/thomasheideclausen.html > On 8 Aug 2016, at 17:17, Robert Sparks wrote: >=20 > I am the assigned Gen-ART and secdir reviewer for this draft. The General A= rea > Review Team (Gen-ART) reviews all IETF documents being processed by the IE= SG > for the IETF Chair. The secdir does the same for the security area directo= rs. > Please treat these comments just like any other last call comments. >=20 > For more information on Gen-Art, please see the FAQ at > . >=20 > For moe information on secdir, see the wiki at > >=20 > Document: draft-ietf-manet-smf-sec-threats-05 > Reviewer: Robert Sparks > Review Date: 8 Aug 2016 > IETF LC End Date: 11 Aug 2016 > IESG Telechat date: 18 Aug 2016 >=20 > Summary: Ready for publication as an Informational RFC >=20 > This draft provides a discussion of vulnerabilities in Simplified Multicas= t > Forwarding (SMF), focusing on attacking the Duplicate Packet Detection and= > Relay Set Selection mechanisms. It positions itself as being useful inform= ation > for those deploying SMF as currently defined. It does not propose mitigat= ions, > but does have a section that identifies potential future work that might. >=20 > I have sent several editorial nits directly to the authors. >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-91E7CF33-EDA5-4D62-9731-2C34A1C54FC1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hello Robert, al= l,

Thank you for this review. Much apprecia= ted. As I understand it, there are no major issues to address?
<= div>
If it is a= lright with you (& with our AD), We propose to fold the "nits" (as you c= all them) that you found in with a couple of "nits" raised by Alvaro already= , and with whatever else the ongoing LC raises, and spin a revision capturin= g it all when the LC is closed?

Thanks again for your help,
=
Thomas


--
T= homas Heide Clausen  =E2=80=A2  @thclausen   =E2=80=A2 = = www.arkko.com/tools/allstats/thomasheideclausen.html

On 8 Aug 2016, at 17:17, Robert Sparks <rjsparks@nostrum.com> wrote:

I am the assigned Gen-ART and secdir reviewer for= this draft. The General Area
Review Team (Gen-ART) reviews a= ll IETF documents being processed by the IESG
for the IETF C= hair. The secdir does the same for the security area directors.
Please treat these comments just like any other last call comments.

For more information on Gen-Art, please see the= FAQ at
<https://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfa= q>.

For moe information on secdir, s= ee the wiki at
<https://trac.tools.ietf.org/area/sec/trac/wik= i/SecDirReview>

Document: draft-ietf= -manet-smf-sec-threats-05
Reviewer: Robert Sparks
= Review Date: 8 Aug 2016
IETF LC End Date: 11 Aug 2016<= /span>
IESG Telechat date: 18 Aug 2016

<= span>Summary: Ready for publication as an Informational RFC
=
This draft provides a discussion of vulnerabilities in Simp= lified Multicast
Forwarding (SMF), focusing on attacking the= Duplicate Packet Detection and
Relay Set Selection mechanis= ms. It positions itself as being useful information
for thos= e deploying SMF as currently defined.  It does not propose mitigations,=
but does have a section that identifies potential future wo= rk that might.

I have sent several editoria= l nits directly to the authors.

___________= ____________________________________
manet mailing list
manet@ietf.org
<= span>https://www.iet= f.org/mailman/listinfo/manet
= --Apple-Mail-91E7CF33-EDA5-4D62-9731-2C34A1C54FC1-- From nobody Thu Aug 11 03:19:04 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCF112B014 for ; Thu, 11 Aug 2016 03:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZMBPQwfsE2b for ; Thu, 11 Aug 2016 03:19:00 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F88F120727 for ; Thu, 11 Aug 2016 03:19:00 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u7BAIqZE008943 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 11 Aug 2016 13:18:52 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u7BAIqfL009368; Thu, 11 Aug 2016 13:18:52 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22444.20748.596013.770441@fireball.acr.fi> Date: Thu, 11 Aug 2016 13:18:52 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 10:19:02 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Derek Atkins is next in the rotation. For telechat 2016-08-18 Reviewer LC end Draft Jeffrey Hutzelman T 2016-07-04 draft-ietf-sipcore-dns-dual-stack-06 Matt Lepinski T 2016-08-04 draft-ietf-insipid-session-id-24 Eric Osterweil T 2016-08-16 draft-ietf-httpauth-extension-06 Radia Perlman T 2016-08-15 draft-ietf-i2rs-protocol-security-requirements-06 Melinda Shore T 2016-08-12 draft-ietf-jose-cfrg-curves-03 Carl Wallace T 2016-08-11 draft-ietf-radext-ip-port-radius-ext-09 For telechat 2016-09-01 Klaas Wierenga T 2016-08-22 draft-ietf-6man-deprecate-atomfrag-generation-06 Tom Yu T 2016-08-24 draft-ietf-6man-ipv6-mibs-obsolete-01 Last calls and special requests: Alan DeKok 2016-04-30 draft-bradner-rfc3979bis-08 Daniel Kahn Gillmor E 2016-02-01 draft-ietf-rtcweb-security-08 Warren Kumari 2016-09-06 draft-sweet-rfc2911bis-09 Matthew Miller 2016-08-06 draft-ietf-avtcore-rfc5764-mux-fixes-10 Sandy Murphy 2016-08-12 draft-ietf-tsvwg-gre-in-udp-encap-13 Rich Salz 2016-08-15 draft-ietf-isis-remaining-lifetime-01 Takeshi Takahashi 2016-08-12 draft-ietf-nvo3-arch-06 Hannes Tschofenig E None draft-ietf-ntp-network-time-security-14 Hannes Tschofenig E None draft-ietf-ntp-cms-for-nts-message-06 Hannes Tschofenig E None draft-ietf-ntp-using-nts-for-ntp-05 Tina TSOU 2016-08-15 draft-ietf-ospf-two-part-metric-05 Brian Weis E 2016-02-01 draft-ietf-cdni-uri-signing-09 Brian Weis 2016-08-11 draft-ietf-tram-turn-server-discovery-07 Paul Wouters 2016-09-02 draft-moriarty-pkcs1-01 Liang Xia 2016-09-02 draft-moriarty-pkcs5-v2dot1-01 Dacheng Zhang 2016-08-22 draft-ietf-core-http-mapping-12 -- kivinen@iki.fi From nobody Thu Aug 11 05:51:42 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BFC12D549; Thu, 11 Aug 2016 05:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.948 X-Spam-Level: X-Spam-Status: No, score=-3.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uD2Nz-3NIlLq; Thu, 11 Aug 2016 05:51:40 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF8412D1E4; Thu, 11 Aug 2016 05:51:40 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4CB93423770; Thu, 11 Aug 2016 12:51:40 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 34E0A423763; Thu, 11 Aug 2016 12:51:40 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1470919900; bh=mv4N+VU53afd//Kyvy1TbUHbbkk1O73GLgeE1PIhER0=; l=1257; h=From:To:Date:From; b=Ic+xFmp3Q59p4G78mfCmX8Iq4MGyI1IID8eajacavG1qTFIZN4bFoGqBg6rMeNHqS L1IPvowj0IpdiMPmpKK3exSOBJYNQTR2EJ3lqIlnnH1G13cb/Zn6ryuiNfR/z3jUpq 6zmWwwh+WL4wjZ36toLuvMMB+rPDzyaf7xZPC9tE= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 34AB11FC8E; Thu, 11 Aug 2016 12:51:40 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 11 Aug 2016 08:51:35 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Thu, 11 Aug 2016 08:51:35 -0400 From: "Salz, Rich" To: "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-isis-remaining-lifetime.all@ietf.org" Thread-Topic: secdir review of draft-ietf-isis-remaining-lifetime Thread-Index: AdHzzmZg4Mh1hPmZT1yCnbUEDw3l4gAAHyHA Date: Thu, 11 Aug 2016 12:51:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.99] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-isis-remaining-lifetime X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 12:51:42 -0000 Re-sending because of typo in some addresses; sorry for the dups -- =20 Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz > -----Original Message----- > From: Salz, Rich > Sent: Thursday, August 11, 2016 8:49 AM > To: '?iesg@ietf.org'; '?secdir@ietf.org'; 'draft-ietf-isis-remaining- > lifetime.all@ietf.org' > Subject: secdir review of draft-ietf-isis-remaining-lifetime >=20 > I have reviewed this document as part of the security directorate's ongo= ing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments > just like any other last call comments. >=20 > This document is READY with one possible NIT. >=20 > I assume that "flooding" is a standard term used in the IS-IS community. = If so, > fine; if not, consider another term like "distribution" since flooding ca= n have > negative connotations in the security community, related to denial of ser= vice. >=20 > The problem statement was particularly well-done and informative. > -- > Senior Architect, Akamai Technologies > IM: richsalz@jabber.at Twitter: RichSalz >=20 From nobody Thu Aug 11 19:50:08 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1FA912D10F; Thu, 11 Aug 2016 19:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.767 X-Spam-Level: X-Spam-Status: No, score=-15.767 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQs33cnzXuaW; Thu, 11 Aug 2016 19:50:06 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FD4112B015; Thu, 11 Aug 2016 19:50:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12516; q=dns/txt; s=iport; t=1470970206; x=1472179806; h=from:to:cc:subject:date:message-id:mime-version; bh=loCVFEcjYHpK+w8NE94O3XUzGeoAq7a1XveZgU072cA=; b=dEaMklBUl+vU3FVRivFzfmJM6BC1xfqgQeS+gAsnf+QVPCpgghGOUyaQ 61rZjT+UMTnuxk2PeuHP/8vBu6jjlj5trbe0f+2qVUO+bxLaMEpeIvVHM cJsFIAtwa3NO2bW/8Gx+kUec4HKZXI1CxZH3UBqyJVNvVmjWbal0zxg+L M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CkAgD2OK1X/5tdJa1egndOgVm0HYUHg?= =?us-ascii?q?X2GHR6BOjgUAQEBAQEBAV0nhGUjVhIBSgIEMCcEAQ2INrBQkDABAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEciCKGf4MXK4IvBZN4hUQBjxOPQ5AsAR42g3qGVisZfwEBA?= =?us-ascii?q?Q?= X-IronPort-AV: E=Sophos;i="5.28,508,1464652800"; d="scan'208,217";a="309925395" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Aug 2016 02:49:45 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u7C2niqE029851 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 12 Aug 2016 02:49:44 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 11 Aug 2016 22:49:43 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1210.000; Thu, 11 Aug 2016 22:49:43 -0400 From: "Brian Weis (bew)" To: "secdir@ietf.org" , The IESG Thread-Topic: SecDir review of draft-ietf-tram-turn-server-discovery-08 Thread-Index: AQHR9EQtsMc8iAoZw0eiSM9NE0uIMQ== Date: Fri, 12 Aug 2016 02:49:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.191.172] Content-Type: multipart/alternative; boundary="_000_CB3946078BE542C2BD5A8431F2C9CB83ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-tram-turn-server-discovery.all@tools.ietf.org" Subject: [secdir] SecDir review of draft-ietf-tram-turn-server-discovery-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 02:50:08 -0000 --_000_CB3946078BE542C2BD5A8431F2C9CB83ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGly ZWN0b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJl aW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHBy aW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiBE b2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRz IGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQpJIGNvbnNpZGVyIHRo aXMgZHJhZnQgdG8gYmUgUmVhZHkgd2l0aCBuaXRzLg0KDQpUVVJOIHNlcnZlcnMgYXJlIHVzZWQg dG8gY29ubmVjdCBkZXZpY2VzIHJ1bm5pbmcgUGVlci10by1QZWVyIGFwcGxpY2F0aW9ucywgc3Vj aCBhcyByZWFsLXRpbWUgY29tbXVuaWNhdGlvbi4gVHlwaWNhbGx5IHRoZXNlIFRVUk4gc2VydmVy cyBhcmUgbm90IHVuZGVyIGEgbG9jYWwgbmV0d29ya+KAmXMgYWRtaW5pc3RyYXRpdmUgY29udHJv bCAoZS5nLiwgdGhlIGVudGVycHJpc2Ugb3IgSVNQIGhvc3RpbmcgdGhlIGNvbW11bmljYXRpbmcg ZGV2aWNlcy4gVGhpcyBkcmFmdCBwcm92aWRlcyBhIHNlcnZlciBkaXNjb3ZlcnkgbWV0aG9kIHRv IGEgVFVSTiBzZXJ2ZXIgdGhhdCBpcyB1bmRlciB0aGUgYWRtaW5pc3RyYXRpdmUgY29udHJvbCBv ZiB0aGUgbG9jYWwgbmV0d29yay4gVGhlcmUgYXJlIHNvbWUgc2VjdXJpdHkgYW5kIG9wZXJhdGlv bmFsIGFkdmFudGFnZXMgdG8gdGhlIHVzZSBvZiBhIGxvY2FsIFRVUk4gc2VydmVyLCBzaW5jZSB0 aGUgbG9jYWwgc2VydmljZSBjYW4gdGVuZCB0byBrZWVwIHRoZSByZWFsLXRpbWUgY29tbXVuaWNh dGlvbiAob3Igb3RoZXIgYXBwbGljYXRpb24pIG1lc3NhZ2VzIGZyb20gbGVhdmluZyB0aGUgbG9j YWwgbmV0d29yay4gVGhpcyBpcyB1c2VmdWwuIFRoZSBtZXRob2RzIGZvciBhdXRvLWRpc2NvdmVy aW5nIGxvY2FsIFRVUk4gc2VydmVycyBkaXNjdXNzZWQgaW4gdGhlIGRvY3VtZW50IGluY2x1ZGUg RE5TIFNlcnZpY2UgUmVzb2x1dGlvbiwgRE5TIFNlcnZpY2UgRGlzY292ZXJ5LCAgYW5kIEFueWNh c3QuDQoNClRoZSBtYWluIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gb2YgdXNpbmcgdXNpbmcgc2Vy dmVyIGRpc2NvdmVyeSBtZXRob2RzIHdvdWxkIHNlZW0gdG8gYmUgZW5zdXJpbmcgdGhhdCBhbiBh dXRob3JpemVkIGxvY2FsIFNUVU4gc2VydmVyIGhhcyBiZWVuIHJlYWNoZWQuIFRoZSBTZWN1cml0 eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIG1lbnRpb25zIFNUVU4gYXV0aGVudGljYXRpb24gYXMg T1BUSU9OQUwgZm9yIOKAnFRVUk4gc2VydmVycyBwcm92aWRlZCBieSB0aGUgbG9jYWwgbmV0d29y ayBvciBieSB0aGUgYWNjZXNzIG5ldHdvcmvigJ0sIGJ1dCAiaXQgaXMgUkVDT01NRU5ERUQgdGhh dCB0aGUgVFVSTiBjbGllbnQgdXNlIG9uZSBvZiB0aGUgZm9sbG93aW5nIHRlY2huaXF1ZXMgd2l0 aCAoRClUTFPigJ0uIFdoZW4gKEQpVExTIGlzIHVzZWQsIHNldmVyYWwgbWVjaGFuaXNtcyBhcmUg ZGVzY3JpYmVkIHdoZXJlYnkgdGhlIGNsaWVudCBjYW4gZGV0ZXJtaW5lIHRoYXQgYSBTVFVOIHNl cnZlciBpcyBhdXRob3JpemVkLiBUaGUgcmVxdWlyZW1lbnRzIGxhbmd1YWdlIGlzIGEgYml0IG9i c2N1cmUsIGJ1dCB0aGUgcmVzdWx0IGlzIHJlY29tbWVuZGluZyB0aGF0IChEKVRMUyBhdXRoZW50 aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBpcyB1c2VkLCB3aGljaCBpcyBmaW5lLg0KDQpUaGUg U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiBhbHNvIHJlY29tbWVuZHMgd2hhdCBhIGNs aWVudCBvdWdodCB0byBkbyB3aGVuIGF1dGhlbnRpY2F0ZWQgKEQpVExTIGlzbuKAmXQgcG9zc2li bGUuIFRoZSBwYXJhZ3JhcGgganVzdCBiZWZvcmUgU2VjdGlvbiA5LjEgY29udGFpbnMgZ29vZCBh ZHZpY2UsIGJ1dCBpdCBjb3VsZCBiZSBjbGVhcmVyLiBGb3IgZXhhbXBsZSB0aGUgcGFyYWdyYXBo IGNvbmZ1c2VzIHByaXZhY3kgZ29hbHMgd2l0aCB0aGUgc2VjdXJpdHkgZ29hbCBvZiBtaXRpZ2F0 aW5nIG9uLXBhdGggaW5qZWN0aW9uIG9mIHNwb29mZWQgcGFja2V0cy4gSSBzdWdnZXN0IHJld29y ZGluZyB0aGlzIHBhcmFncmFwaCB3aXRoIHRleHQgc29tZXRoaW5nIGxpa2UgdGhpczoNCg0KICAg SW4gc29tZSBhdXRvLWRpc2NvdmVyeSBzY2VuYXJpb3MsIGl0IG1pZ2h0IG5vdCBiZSBwb3NzaWJs ZSBmb3IgdGhlDQogICBUVVJOIGNsaWVudCB0byB1c2UgKEQpVExTIGF1dGhlbnRpY2F0aW9uIHRv IHZhbGlkYXRlIHRoZSBUVVJOIHNlcnZlci4NCiAgIEhvd2V2ZXIsIGZhbGwtYmFjayB0byBjbGVh ciB0ZXh0IGluIHN1Y2ggY2FzZXMgY291bGQgbGVhdmUgdGhlIFRVUk4NCiAgIGNsaWVudCBvcGVu IHRvIG9uLXBhdGggaW5qZWN0aW9uIG9mIHNwb29mZWQgVFVSTiBtZXNzYWdlcy4NCiAgIEluc3Rl YWQsIGEgVFVSTiBjbGllbnQgU0hPVUxEIGZhbGwtYmFjayB0byBlbmNyeXB0aW9uLW9ubHkNCiAg IChEKVRMUyB3aGVuIChEKVRMUyBhdXRoZW50aWNhdGlvbiBpcyBub3QgYXZhaWxhYmxlLiBBbm90 aGVyIHJlYXNvbg0KICAgdG8gZmFsbC1iYWNrIHRvIGVuY3J5cHRpb24tb25seSBpcyBmb3IgcHJp dmFjeSwgd2hpY2ggaXMNCiAgIGFuYWxvZ291cyB0byBTTVRQIG9wcG9ydHVuaXN0aWMgZW5jcnlw dGlvbg0KICAgW1JGQzc0MzVdICB3aGVyZSBvbmUgZG9lcyBub3QgcmVxdWlyZSBwcml2YWN5IGJ1 dCBvbmUgZGVzaXJlcyBwcml2YWN5DQogICB3aGVuIHBvc3NpYmxlLg0KDQogICBJdCBpcyBzdWdn ZXN0ZWQgdGhhdCBhIFRVUk4gY2xpZW50IGF0dGVtcHQgKEQpVExTIHdpdGgNCiAgIGF1dGhlbnRp Y2F0aW9uIGFuZCBlbmNyeXB0aW9uLCBmYWxsaW5nIGJhY2sgdG8gZW5jcnlwdGlvbi1vbmx5IGlm IHRoZQ0KICAgVFVSTiBzZXJ2ZXIgY2Fubm90IGJlIGF1dGhlbnRpY2F0ZWQgdmlhIChEKVRMUy4g IFRoZSBUVVJOIHNlcnZlcg0KICAgY291bGQgZmFsbCBiYWNrIHRvIGNsZWFyIHRleHQgaWYgaXQg IGRvZXMgbm90IHN1cHBvcnQgdW5hdXRoZW50aWNhdGVkIChEKVRMUywNCiAgIGJ1dCBmYWxsYmFj ayB0byBjbGVhciB0ZXh0IGlzIE5PVCBSRUNPTU1FTkRFRCBiZWNhdXNlIGl0IG1ha2VzDQogICB0 aGUgY2xpZW50IG1vcmUgc3VzY2VwdGlibGUgdG8gbWFuLWluLXRoZS1taWRkbGUgYXR0YWNrcyBh bmQgb24tcGF0aA0KICAgcGFja2V0IGluamVjdGlvbi4NCg0KVGhlIFNlY3VyaXR5IENvbnNpZGVy YXRpb25zIGluIGVhY2ggb2YgdGhlIHN1Yi1zZWN0aW9ucyBpcyBnb29kIGFzIHdyaXR0ZW4uDQoN CkJyaWFuDQoNCg0K --_000_CB3946078BE542C2BD5A8431F2C9CB83ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSSBoYXZlIHJldmlld2VkIHRoaXMg ZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyBvbmdvaW5nIGVm Zm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUg SUVTRy4gVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVm aXQgb2YmbmJzcDt0aGUgc2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMuIERvY3VtZW50IGVkaXRvcnMg YW5kIFdHIGNoYWlycw0KIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55 IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkgY29uc2lkZXIgdGhpcyBkcmFmdCB0byBiZSA8Zm9udCBm YWNlPSJUaW1lcyBOZXcgUm9tYW4sIHRpbWVzLCBzZXJpZiIgY2xhc3M9IiI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxNXB4OyIgY2xhc3M9IiI+UmVhZHkgd2l0aCBuaXRzLjwvc3Bhbj48L2Zv bnQ+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+VFVSTiBzZXJ2ZXJzIGFyZSB1c2VkIHRvIGNvbm5lY3QgZGV2aWNlcyBydW5u aW5nIFBlZXItdG8tUGVlciBhcHBsaWNhdGlvbnMsIHN1Y2ggYXMgcmVhbC10aW1lIGNvbW11bmlj YXRpb24uIFR5cGljYWxseSB0aGVzZSBUVVJOIHNlcnZlcnMgYXJlIG5vdCB1bmRlciBhIGxvY2Fs IG5ldHdvcmvigJlzIGFkbWluaXN0cmF0aXZlIGNvbnRyb2wgKGUuZy4sIHRoZSBlbnRlcnByaXNl IG9yIElTUCBob3N0aW5nIHRoZSBjb21tdW5pY2F0aW5nDQogZGV2aWNlcy4gVGhpcyBkcmFmdCBw cm92aWRlcyBhIHNlcnZlciBkaXNjb3ZlcnkgbWV0aG9kIHRvIGEgVFVSTiBzZXJ2ZXIgdGhhdCBp cyB1bmRlciB0aGUgYWRtaW5pc3RyYXRpdmUgY29udHJvbCBvZiB0aGUgbG9jYWwgbmV0d29yay4g VGhlcmUgYXJlIHNvbWUgc2VjdXJpdHkgYW5kIG9wZXJhdGlvbmFsIGFkdmFudGFnZXMgdG8gdGhl IHVzZSBvZiBhIGxvY2FsIFRVUk4gc2VydmVyLCBzaW5jZSB0aGUgbG9jYWwgc2VydmljZSBjYW4g dGVuZCB0bw0KIGtlZXAgdGhlIHJlYWwtdGltZSBjb21tdW5pY2F0aW9uIChvciBvdGhlciBhcHBs aWNhdGlvbikgbWVzc2FnZXMgZnJvbSBsZWF2aW5nIHRoZSBsb2NhbCBuZXR3b3JrLiBUaGlzIGlz IHVzZWZ1bC4gVGhlIG1ldGhvZHMgZm9yIGF1dG8tZGlzY292ZXJpbmcgbG9jYWwgVFVSTiBzZXJ2 ZXJzIGRpc2N1c3NlZCBpbiB0aGUgZG9jdW1lbnQgaW5jbHVkZSBETlMgU2VydmljZSBSZXNvbHV0 aW9uLCBETlMgU2VydmljZSBEaXNjb3ZlcnksICZuYnNwO2FuZCBBbnljYXN0LjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhlIG1haW4g c2VjdXJpdHkgY29uc2lkZXJhdGlvbiBvZiB1c2luZyB1c2luZyBzZXJ2ZXIgZGlzY292ZXJ5IG1l dGhvZHMmbmJzcDt3b3VsZCBzZWVtIHRvIGJlIGVuc3VyaW5nIHRoYXQgYW4gYXV0aG9yaXplZCBs b2NhbCBTVFVOIHNlcnZlciBoYXMgYmVlbiByZWFjaGVkLiBUaGUgU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnMgc2VjdGlvbiBtZW50aW9ucyBTVFVOIGF1dGhlbnRpY2F0aW9uIGFzIE9QVElPTkFMIGZv ciDigJxUVVJOIHNlcnZlcnMNCiBwcm92aWRlZCBieSB0aGUgbG9jYWwgbmV0d29yayBvciBieSB0 aGUgYWNjZXNzIG5ldHdvcmvigJ0sIGJ1dCAmcXVvdDtpdCBpcyBSRUNPTU1FTkRFRCB0aGF0IHRo ZSBUVVJOIGNsaWVudCB1c2Ugb25lIG9mIHRoZSBmb2xsb3dpbmcgdGVjaG5pcXVlcyB3aXRoIChE KVRMU+KAnS4gV2hlbiAoRClUTFMgaXMgdXNlZCwgc2V2ZXJhbCBtZWNoYW5pc21zIGFyZSBkZXNj cmliZWQgd2hlcmVieSB0aGUgY2xpZW50IGNhbiBkZXRlcm1pbmUgdGhhdCBhIFNUVU4gc2VydmVy DQogaXMgYXV0aG9yaXplZC4gVGhlIHJlcXVpcmVtZW50cyBsYW5ndWFnZSBpcyBhIGJpdCBvYnNj dXJlLCBidXQgdGhlIHJlc3VsdCBpcyByZWNvbW1lbmRpbmcgdGhhdCAoRClUTFMgYXV0aGVudGlj YXRpb24gYW5kIGF1dGhvcml6YXRpb24gaXMgdXNlZCwgd2hpY2ggaXMgZmluZS48L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoZSBTZWN1 cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIGFsc28gcmVjb21tZW5kcyB3aGF0IGEgY2xpZW50 IG91Z2h0IHRvIGRvIHdoZW4gYXV0aGVudGljYXRlZCAoRClUTFMgaXNu4oCZdCBwb3NzaWJsZS4g VGhlIHBhcmFncmFwaCBqdXN0IGJlZm9yZSBTZWN0aW9uIDkuMSBjb250YWlucyBnb29kIGFkdmlj ZSwgYnV0IGl0IGNvdWxkIGJlIGNsZWFyZXIuIEZvciBleGFtcGxlIHRoZSBwYXJhZ3JhcGggY29u ZnVzZXMgcHJpdmFjeQ0KIGdvYWxzIHdpdGggdGhlIHNlY3VyaXR5IGdvYWwgb2YgbWl0aWdhdGlu ZyBvbi1wYXRoIGluamVjdGlvbiBvZiBzcG9vZmVkIHBhY2tldHMuIEkgc3VnZ2VzdCByZXdvcmRp bmcgdGhpcyBwYXJhZ3JhcGggd2l0aCB0ZXh0IHNvbWV0aGluZyBsaWtlIHRoaXM6PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmllciBOZXciIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDtJ biBzb21lIGF1dG8tZGlzY292ZXJ5IHNjZW5hcmlvcywgaXQgbWlnaHQgbm90IGJlIHBvc3NpYmxl IGZvciB0aGU8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIg TmV3IiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7VFVSTiBjbGllbnQgdG8gdXNlIChEKVRMUyBhdXRo ZW50aWNhdGlvbiB0byB2YWxpZGF0ZSB0aGUgVFVSTiBzZXJ2ZXIuPC9mb250PjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNw O0hvd2V2ZXIsIGZhbGwtYmFjayB0byBjbGVhciB0ZXh0IGluIHN1Y2ggY2FzZXMgY291bGQgbGVh dmUgdGhlIFRVUk48L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJp ZXIgTmV3IiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7Y2xpZW50IG9wZW4gdG8gb24tcGF0aCBpbmpl Y3Rpb24gb2Ygc3Bvb2ZlZCBUVVJOIG1lc3NhZ2VzLiZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmllciBOZXciIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDtJ bnN0ZWFkLCBhIFRVUk4gY2xpZW50IFNIT1VMRCBmYWxsLWJhY2sgdG8gZW5jcnlwdGlvbi1vbmx5 PC9mb250PjwvZGl2Pg0KPGZvbnQgZmFjZT0iQ291cmllciBOZXciIGNsYXNzPSIiPiZuYnNwOyAm bmJzcDsoRClUTFMgd2hlbiAoRClUTFMgYXV0aGVudGljYXRpb24gaXMgbm90IGF2YWlsYWJsZS4g QW5vdGhlciByZWFzb248L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNv dXJpZXIgTmV3IiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7dG8gZmFsbC1iYWNrIHRvIGVuY3J5cHRp b24tb25seSBpcyBmb3IgcHJpdmFjeSwgd2hpY2ggaXM8L2ZvbnQ+DQo8ZGl2IGNsYXNzPSIiPjxm b250IGZhY2U9IkNvdXJpZXIgTmV3IiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7YW5hbG9nb3VzIHRv IFNNVFAgb3Bwb3J0dW5pc3RpYyBlbmNyeXB0aW9uPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwO1tSRkM3NDM1 XSAmbmJzcDt3aGVyZSBvbmUgZG9lcyBub3QgcmVxdWlyZSBwcml2YWN5IGJ1dCBvbmUgZGVzaXJl cyBwcml2YWN5PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVy IE5ldyIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwO3doZW4gcG9zc2libGUuICZuYnNwOzwvZm9udD48 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmllciBOZXciIGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291 cmllciBOZXciIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDtJdCBpcyBzdWdnZXN0ZWQgdGhhdCBhIFRV Uk4gY2xpZW50IGF0dGVtcHQgKEQpVExTIHdpdGg8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pjxmb250IGZhY2U9IkNvdXJpZXIgTmV3IiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7YXV0aGVudGlj YXRpb24gYW5kIGVuY3J5cHRpb24sIGZhbGxpbmcgYmFjayB0byBlbmNyeXB0aW9uLW9ubHkgaWYg dGhlPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyIg Y2xhc3M9IiI+Jm5ic3A7ICZuYnNwO1RVUk4gc2VydmVyIGNhbm5vdCBiZSBhdXRoZW50aWNhdGVk IHZpYSAoRClUTFMuICZuYnNwO1RoZSBUVVJOIHNlcnZlcjwvZm9udD48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGZvbnQgZmFjZT0iQ291cmllciBOZXciIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDtjb3Vs ZCBmYWxsIGJhY2sgdG8gY2xlYXIgdGV4dCBpZiBpdCAmbmJzcDtkb2VzIG5vdCBzdXBwb3J0IHVu YXV0aGVudGljYXRlZCAoRClUTFMsJm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwO2J1dCBmYWxsYmFj ayB0byBjbGVhciB0ZXh0IGlzIE5PVCBSRUNPTU1FTkRFRCBiZWNhdXNlIGl0IG1ha2VzPC9mb250 PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyIgY2xhc3M9IiI+ Jm5ic3A7ICZuYnNwO3RoZSBjbGllbnQgbW9yZSBzdXNjZXB0aWJsZSB0byBtYW4taW4tdGhlLW1p ZGRsZSBhdHRhY2tzIGFuZCBvbi1wYXRoPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9u dCBmYWNlPSJDb3VyaWVyIE5ldyIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwO3BhY2tldCBpbmplY3Rp b24uPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+VGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIGluIGVhY2ggb2YgdGhlIHN1 Yi1zZWN0aW9ucyBpcyBnb29kIGFzIHdyaXR0ZW4uPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5CcmlhbjwvZGl2Pg0KPGJyIGNsYXNzPSJB cHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CB3946078BE542C2BD5A8431F2C9CB83ciscocom_-- From nobody Fri Aug 12 08:11:18 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4CA12D186; Fri, 12 Aug 2016 08:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGLyydudKNXC; Fri, 12 Aug 2016 08:11:08 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id 28B5C12B05F; Fri, 12 Aug 2016 08:11:05 -0700 (PDT) Received: from gw2.nict.go.jp (gw2.nict.go.jp [133.243.18.251]) by ns2.nict.go.jp with ESMTP id u7CFB4ST081976; Sat, 13 Aug 2016 00:11:04 +0900 (JST) Received: from DESKTOP2JPR8KD (ssh1.nict.go.jp [133.243.3.49]) by gw2.nict.go.jp with ESMTP id u7CFB4El081967; Sat, 13 Aug 2016 00:11:04 +0900 (JST) From: "Takeshi Takahashi" To: Date: Sat, 13 Aug 2016 00:11:04 +0900 Message-ID: <225101d1f4ab$be76d9a0$3b648ce0$@nict.go.jp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_2252_01D1F4F7.2E60F2A0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdH0qsTgaG4vD7ROT6y/ONbw1H4BGg== Content-Language: ja X-Virus-Scanned: clamav-milter 0.98.7 at zenith2 X-Virus-Status: Clean Archived-At: Cc: nvo3@ietf.org, iesg@ietf.org, secdir@ietf.org Subject: [secdir] Secdir review of draft-ietf-nvo3-arch-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 15:11:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_2252_01D1F4F7.2E60F2A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. [General summary] This document is ready. [Topic of this draft] This informational document describes a high-level overview architecture for building data center network viatualization overlay (NVO3) networks. It breaks down the architecture and defines several components needed for realizing the architecture, such as Network Virtualization Edge (NVE) and Network Virtualization Authority (NVA). [Minor Comment] In Section 16 "Security Considerations", you could consider addressing the policy enforcement issue you've discussed in Section 5.4. The sentence starting with "Leakage of sensitive information" could be, for instance, changed from "...by using encryption" to "...by using encryption and ensuring policy enforcement". [Editorial Comment] In Page 9, there is a sentence "NVAs provide a service, and NVEs access that service via an NVE-to-NVA protocol as discussed in Section 4.3." This current sentence is fine, but referring Section 8 "NVE-to-NVA Protocol" (instead of Section 4.3 "NVE State") could be better. In Section 2, definition of "VLAN": "are used in this document denote a C-VLAN", could be "are used in this document to denote a C-VLAN". I enjoyed reading the draft. Thank you. Take ------=_NextPart_000_2252_01D1F4F7.2E60F2A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have = reviewed this document as part of the security directorate's ongoing = effort to review all IETF documents being processed by the = IESG.

These comments were written primarily for the = benefit of the security area directors.

Document = editors and WG chairs should treat these comments just like any other = last call comments.

 

[General = summary]

This document is = ready.

 

[Topic = of this draft]

This informational document = describes a high-level overview architecture for building data center = network viatualization overlay (NVO3) networks.

It = breaks down the architecture and defines several components needed for = realizing the architecture, such as Network Virtualization Edge (NVE) = and Network Virtualization Authority (NVA).

 

[Minor = Comment]

In Section 16 “Security = Considerations”, you could consider addressing the policy = enforcement issue you've discussed in Section = 5.4.

The sentence starting with "Leakage of = sensitive information" could be, for instance, changed from = "...by using encryption" to "...by using encryption and = ensuring policy enforcement".

 

[Editorial Comment]

In Page = 9, there is a sentence "NVAs provide a service, and NVEs access = that service via an NVE-to-NVA protocol as discussed in Section = 4.3."

This current sentence is fine, but referring = Section 8 "NVE-to-NVA Protocol" (instead of Section 4.3 = "NVE State") could be better.

 

In = Section 2, definition of "VLAN": "are used in this = document denote a C-VLAN", could be "are used in this document = to denote a C-VLAN".

 

I = enjoyed reading the draft.

 

Thank = you.

Take

 

------=_NextPart_000_2252_01D1F4F7.2E60F2A0-- From nobody Fri Aug 12 08:51:22 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EECF712D59E; Fri, 12 Aug 2016 08:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.com header.b=hK/rIUIs; dkim=pass (1024-bit key) header.d=emc.com header.b=SoiHpT/j Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9vxbulmEgUJ; Fri, 12 Aug 2016 08:51:12 -0700 (PDT) Received: from esa8.dell-outbound.iphmx.com (esa8.dell-outbound.iphmx.com [68.232.149.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0849212D176; Fri, 12 Aug 2016 08:51:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=emc.com; i=@emc.com; q=dns/txt; s=jan2013; t=1471017072; x=1502553072; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=iMyte+q+PzcrRt7Z8OHwRONEpz9GzYEMqWzoo4b17tQ=; b=hK/rIUIsxiApq+wHvsWw9ebwWH/GLR8OWU2GY8DnbEElvUweecX/ms7l abyq7FdnlbTvWoHPqC+9FKuaaFA/vUP82wpm3wtSgsmrvwZQryUXJUyfO 0cv9z064vAlX/GyK10gsJhCCkF6w/4Hn/U3krapKeU5Zp+B37/2dqVmTN M=; Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa8.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Aug 2016 10:51:10 -0500 Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u7CFp9Xm005278 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 Aug 2016 11:51:09 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com u7CFp9Xm005278 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1471017069; bh=XKsKJxSnC8K6ntIlRWX04KGjMNA=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=SoiHpT/j2WM8wQZy2MySiChY9rDS3Q/yzy6QWVI/umm27rtEhJTykQteaS4j64sik z61QyfNpkZD5oa8YROv4VA3cxJTERi3LtZpsdMNaSUKzjJd0vsmev92DYtIKym1Owa dt12AZ//ncn4er7VmQXteOxtoy5nj0nyRGQ8RZuY= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com u7CFp9Xm005278 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd56.lss.emc.com (RSA Interceptor); Fri, 12 Aug 2016 11:50:47 -0400 Received: from MXHUB306.corp.emc.com (MXHUB306.corp.emc.com [10.146.3.32]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u7CFp1TA021501 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Fri, 12 Aug 2016 11:51:02 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB306.corp.emc.com ([10.146.3.32]) with mapi id 14.03.0266.001; Fri, 12 Aug 2016 11:51:01 -0400 From: "Black, David" To: Takeshi Takahashi , "draft-ietf-nvo3-arch.all@ietf.org" Thread-Topic: Secdir review of draft-ietf-nvo3-arch-06 Thread-Index: AdH0qsTgaG4vD7ROT6y/ONbw1H4BGgABFwhQ Date: Fri, 12 Aug 2016 15:51:00 +0000 Message-ID: References: <225101d1f4ab$be76d9a0$3b648ce0$@nict.go.jp> In-Reply-To: <225101d1f4ab$be76d9a0$3b648ce0$@nict.go.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.130] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362F63B90FMX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "Black, David" , "nvo3@ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-nvo3-arch-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 15:51:14 -0000 --_000_CE03DB3D7B45C245BCA0D243277949362F63B90FMX307CL04corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Take-san, Thank you for the review. I've made changes to address all of your commen= ts in my working copy of this draft that will be posted as the -07 version = next week. The minor comment on information leakage affects both the data plane and co= ntrol plane and hence I've made changes to address it in two paragraphs in = the Security Considerations section. Here are the revised versions of both= paragraphs: For the data plane, tunneled application traffic may need protection agains= t being misdelivered, modified, or having its content exposed to an inappro= priate third party. In all cases, encryption between authenticated tunnel e= ndpoints and enforcing policies that control which endpoints and VNs are pe= rmitted to exchange traffic can be used to mitigate risks. [...] Leakage of sensitive information about users or other entities associated w= ith VMs whose traffic is virtualized can also be covered by using encryptio= n for the control plane protocols and enforcing policies that control which= NVO3 components are permitted to exchange control plane traffic. Thanks, --David From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] Sent: Friday, August 12, 2016 11:11 AM To: draft-ietf-nvo3-arch.all@ietf.org Cc: iesg@ietf.org; secdir@ietf.org; nvo3@ietf.org Subject: Secdir review of draft-ietf-nvo3-arch-06 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area = directors. Document editors and WG chairs should treat these comments just like any ot= her last call comments. [General summary] This document is ready. [Topic of this draft] This informational document describes a high-level overview architecture fo= r building data center network viatualization overlay (NVO3) networks. It breaks down the architecture and defines several components needed for r= ealizing the architecture, such as Network Virtualization Edge (NVE) and Ne= twork Virtualization Authority (NVA). [Minor Comment] In Section 16 "Security Considerations", you could consider addressing the = policy enforcement issue you've discussed in Section 5.4. The sentence starting with "Leakage of sensitive information" could be, for= instance, changed from "...by using encryption" to "...by using encryption= and ensuring policy enforcement". [Editorial Comment] In Page 9, there is a sentence "NVAs provide a service, and NVEs access tha= t service via an NVE-to-NVA protocol as discussed in Section 4.3." This current sentence is fine, but referring Section 8 "NVE-to-NVA Protocol= " (instead of Section 4.3 "NVE State") could be better. In Section 2, definition of "VLAN": "are used in this document denote a C-V= LAN", could be "are used in this document to denote a C-VLAN". I enjoyed reading the draft. Thank you. Take --_000_CE03DB3D7B45C245BCA0D243277949362F63B90FMX307CL04corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Take-san,

 <= /p>

Thank you for the review.=    I’ve made changes to address all of your comments in my = working copy of this draft that will be posted as the -07 version next week= .

 <= /p>

The minor comment on info= rmation leakage affects both the data plane and control plane and hence I&#= 8217;ve made changes to address it in two paragraphs in the Security Considerations section.  Here are the revised versions of both paragr= aphs:

 <= /p>

 <= /p>

Thanks, --David

 <= /p>

From: Takeshi Takahashi [mailto:takeshi_takahash= i@nict.go.jp]
Sent: Friday, August 12, 2016 11:11 AM
To: draft-ietf-nvo3-arch.all@ietf.org
Cc: iesg@ietf.org; secdir@ietf.org; nvo3@ietf.org
Subject: Secdir review of draft-ietf-nvo3-arch-06<= /p>

 =

I have reviewed this document as part of the security directorate's on= going effort to review all IETF documents being processed by the IESG.=

These comments were written primarily for the benefit of the security = area directors.

Document editors and WG chairs should treat these comments just like a= ny other last call comments.

 

[General summary]

This document is ready.

 

[Topic of this draft]

This informational document describes a high-level overview architectu= re for building data center network viatualization overlay (NVO3) networks.=

It breaks down the architecture and defines several components needed = for realizing the architecture, such as Network Virtualization Edge (NVE) a= nd Network Virtualization Authority (NVA).

 

[Minor Comment]

In Section 16 “Security Considerations”, you could conside= r addressing the policy enforcement issue you've discussed in Section 5.4.<= o:p>

The sentence starting with "Leakage of sensitive information"= ; could be, for instance, changed from "...by using encryption" t= o "...by using encryption and ensuring policy enforcement".<= /o:p>

 

[Editorial Comment]

In Page 9, there is a sentence "NVAs provide a service, and NVEs = access that service via an NVE-to-NVA protocol as discussed in Section 4.3.= "

This current sentence is fine, but referring Section 8 "NVE-to-NV= A Protocol" (instead of Section 4.3 "NVE State") could be be= tter.

 

In Section 2, definition of "VLAN": "are used in this d= ocument denote a C-VLAN", could be "are used in this document to = denote a C-VLAN".

 

I enjoyed reading the draft.

 

Thank you.

Take

 

--_000_CE03DB3D7B45C245BCA0D243277949362F63B90FMX307CL04corpem_-- From nobody Fri Aug 12 15:42:05 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77C012D8FD; Fri, 12 Aug 2016 15:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkCm_q0efTF3; Fri, 12 Aug 2016 15:42:00 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA9A812D843; Fri, 12 Aug 2016 15:42:00 -0700 (PDT) Received: by mail-pa0-x230.google.com with SMTP id fi15so77821pac.1; Fri, 12 Aug 2016 15:42:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:cc:message-id:date:user-agent:mime-version; bh=lgqfOCIHIKZ0d0Dirq6a+gGdba+DgVvXJCXsawAiR8U=; b=uLcNaDJGE8PLsH0IV3ppdBhgz/K6oypy3Sl/I8gqDfFz541bU2qOR+D+e/Gt+TaUv/ uNCmcE05OFCziwke1WAe03xNHhoSkCz1pKj0fMNBxumyE7D/oMw+LuvoZQOFC5Q2e7lT 2EunSwk1tCJyzNP4w1jDz1P+b6azSO5ckTQsYFwuyyAyxFCAA3DWNKtAWSeo9ssi1vIx VRFFawdppsHlDg5Te3FmSXj1Q7NpNCvvKsgIIN33N/gn68Zq02wQaYEY4k8ort8lfq8P ahG/mTzq5ZW9wE/HYG3baYJyq+nnq9lp5hl6mlFXKtnFBCNDot2KpSevrvygP/6hEu4s RnVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:cc:message-id:date:user-agent :mime-version; bh=lgqfOCIHIKZ0d0Dirq6a+gGdba+DgVvXJCXsawAiR8U=; b=jjKcznyoJ/y7hKRgbQ3eV306i1jeMzqaULOAZsTIZVkqtHUoW2L8FmrIOjtpjzH7sR vgSRFz76vs8wDLNsObc/ltkHPlPm5L4RrGotR98I25f2Y6H/jYejlwCeKam+QspNcQBi WLJ1MfKUCzrfIXYiztQT7jlPsO1vReBjVsRmiI8wqqsNr1qLWD85FgWTH3CKGGQH+9mk 0nmQiXLXFmT8PstcgKeEuUr+zmu/FFWZWQaJ7RkYwtouXrlqpgv9DH/vpyOteYISMiV3 8cvVq/EtUK+lDFk3enrWDc590JIul8KODGev9TkUZW2yrAknp4CnCptvBzY5tFbFPuYe xmHg== X-Gm-Message-State: AEkoouv5XKwZbwn1vUXpgLl8fP/DFtYqSfNzfuUlSNsmCVpe2APhp655Morstw1Sqh3elg== X-Received: by 10.66.25.135 with SMTP id c7mr30940474pag.24.1471041720234; Fri, 12 Aug 2016 15:42:00 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (216-67-79-200-radius.dynamic.acsalaska.net. [216.67.79.200]) by smtp.googlemail.com with ESMTPSA id i62sm15402756pfg.62.2016.08.12.15.41.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Aug 2016 15:41:59 -0700 (PDT) From: Melinda Shore To: draft-ietf-jose-cfrg-curves.all@ietf.org Message-ID: Date: Fri, 12 Aug 2016 14:41:56 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="AF63xiqGpvrh5rkxWOhUPVDSOSBD9TiMv" Archived-At: Cc: secdir@ietf.org Subject: [secdir] secdir review of draft-ietf-jose-cfrg-curves-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 22:42:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AF63xiqGpvrh5rkxWOhUPVDSOSBD9TiMv Content-Type: multipart/mixed; boundary="qEpB4OopsseNxQxnvVnhnt5p4TFEK9cWW" From: Melinda Shore To: draft-ietf-jose-cfrg-curves.all@ietf.org Cc: secdir@ietf.org Message-ID: Subject: secdir review of draft-ietf-jose-cfrg-curves-05 --qEpB4OopsseNxQxnvVnhnt5p4TFEK9cWW Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable [Note: I was assigned draft-ietf-jose-cfrg-curves-03 but have reviewed the most recent revision] This document defines how to use the Diffie-Hellman algorithms "X25519" and "X448" as well as the signature algorithms "Ed25519" and "Ed448" from the IRTF CFRG elliptic curves work in JOSE, and in doing so introduces new a key type and subtypes, and specifies registry additions. Section 3 specifies the application of the algorithms within the JOSE framework. Summary: ready, with very minor nits on formal publication requirements I do not have the cryptographic chops to perform a cryptographic review of this draft. The algorithms being added to JOSE in this document are specified in a CFRG deliverable (https://datatracker.ietf.org/doc/draft-irtf-cfrg-eddsa/), which is currently under development (that is to say, mature but not completed). I am satisfied that this document pays heed to the security considerations in the CFRG document. The document appears complete and ready with respect to the needs of someone implementing this specification. Nits: normative reference to an informational RFC (7748) normative reference to an informational draft (draft-irtf-cfrg-eddsa) later version of draft-irtf-cfrg-eddsa has been published missing reference: "RFC-THIS" in IANA Considerations section Melinda --qEpB4OopsseNxQxnvVnhnt5p4TFEK9cWW-- --AF63xiqGpvrh5rkxWOhUPVDSOSBD9TiMv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXrlC1AAoJELiGRpM6HoEutVwP/1+FA6Ex9XtN9hg7zyCsZta5 RjDBDXyQpg3SdMeYkzWZ4dKaj5e+UGt+wZUsaHeQlDoRIcjgukzu2j8P9odRl52y Mwet+HvNio+VppSb4+tgd0NZStKvs2xXstfeWvhtUXujCQ48GH1IwF6eqWS3xY2y RSZ0a7P+ueUnxt5005nh97ZWChXwdAc+T5BD8kcTAqjTXos0vqyVypnk4Vhha3Vs 9Fuj1k1FvLoZVzQwKQXlzMFebRcmFSr0Jj5EkksqFzYQuBDwv+ZEFBPiODYhnRey VJo90n3oJL/GTaW9J0GDEcmROj7lYI870/PhxM+0t2yjsdNudheFTlARv+niwiCm /cGC/NdwJQh5OHtiS0WZgCJwq5XQeJgsdqfTuddxe8eVzVkwnNngrDDYJmiSTLjQ RrsriQRQj7IcYsfN5nDy9hbSx0Bj2QWeuouGVoRu12lAKPtKe+1i7TCr9+foXIWx 6DbszNncSxTMRcj318/T8OQ6ypqPg4R4+GoqMsIWraTgtdfpWI78z7GEY6pF8djx 0+KREfnqZFjAORzk6MpJxf5sg3brWsx8TswMlLeKPT9KKZNsCF9CruBMqE7HMXmZ ZhkrLo9C3wmUAM2VFLw2Tl2QAPRRvJTxBnFnRnjMO14nvruEgXA3qO79Nv8/Tkww B5zydhhXLkPvNu8UGpSw =Sx/S -----END PGP SIGNATURE----- --AF63xiqGpvrh5rkxWOhUPVDSOSBD9TiMv-- From nobody Fri Aug 12 17:10:25 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92BF212D92C; Fri, 12 Aug 2016 17:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LixavmMx0A2D; Fri, 12 Aug 2016 17:10:22 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id D886612D8B1; Fri, 12 Aug 2016 17:10:21 -0700 (PDT) Received: from gw1.nict.go.jp (gw1.nict.go.jp [133.243.18.250]) by ns1.nict.go.jp with ESMTP id u7D0AHAv014103; Sat, 13 Aug 2016 09:10:17 +0900 (JST) Received: from DESKTOP2JPR8KD (ssh1.nict.go.jp [133.243.3.49]) by gw1.nict.go.jp with ESMTP id u7D0AHTC013909; Sat, 13 Aug 2016 09:10:17 +0900 (JST) From: "Takeshi Takahashi" To: "'Black, David'" , References: <225101d1f4ab$be76d9a0$3b648ce0$@nict.go.jp> In-Reply-To: Date: Sat, 13 Aug 2016 09:10:17 +0900 Message-ID: <14afb01d1f4f7$1275e230$3761a690$@nict.go.jp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_14AFC_01D1F542.825D8A30" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJVc9ShE0j+FVnLpFrAsWqfActl/gEaTFovnzYytfA= Content-Language: ja X-Virus-Scanned: clamav-milter 0.98.7 at zenith1 X-Virus-Status: Clean Archived-At: Cc: nvo3@ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-nvo3-arch-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2016 00:10:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_14AFC_01D1F542.825D8A30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello David-san, Thank you for reflecting my comments. I like the revised sentences. I hope this draft will be published as an RFC soon. Best regards, Take From: Black, David [mailto:david.black@emc.com] Sent: Saturday, August 13, 2016 12:51 AM To: Takeshi Takahashi ; draft-ietf-nvo3-arch.all@ietf.org Cc: iesg@ietf.org; secdir@ietf.org; nvo3@ietf.org; Black, David Subject: RE: Secdir review of draft-ietf-nvo3-arch-06 Take-san, Thank you for the review. I've made changes to address all of your comments in my working copy of this draft that will be posted as the -07 version next week. The minor comment on information leakage affects both the data plane and control plane and hence I've made changes to address it in two paragraphs in the Security Considerations section. Here are the revised versions of both paragraphs: For the data plane, tunneled application traffic may need protection against being misdelivered, modified, or having its content exposed to an inappropriate third party. In all cases, encryption between authenticated tunnel endpoints and enforcing policies that control which endpoints and VNs are permitted to exchange traffic can be used to mitigate risks. [...] Leakage of sensitive information about users or other entities associated with VMs whose traffic is virtualized can also be covered by using encryption for the control plane protocols and enforcing policies that control which NVO3 components are permitted to exchange control plane traffic. Thanks, --David From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] Sent: Friday, August 12, 2016 11:11 AM To: draft-ietf-nvo3-arch.all@ietf.org Cc: iesg@ietf.org ; secdir@ietf.org ; nvo3@ietf.org Subject: Secdir review of draft-ietf-nvo3-arch-06 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. [General summary] This document is ready. [Topic of this draft] This informational document describes a high-level overview architecture for building data center network viatualization overlay (NVO3) networks. It breaks down the architecture and defines several components needed for realizing the architecture, such as Network Virtualization Edge (NVE) and Network Virtualization Authority (NVA). [Minor Comment] In Section 16 "Security Considerations", you could consider addressing the policy enforcement issue you've discussed in Section 5.4. The sentence starting with "Leakage of sensitive information" could be, for instance, changed from "...by using encryption" to "...by using encryption and ensuring policy enforcement". [Editorial Comment] In Page 9, there is a sentence "NVAs provide a service, and NVEs access that service via an NVE-to-NVA protocol as discussed in Section 4.3." This current sentence is fine, but referring Section 8 "NVE-to-NVA Protocol" (instead of Section 4.3 "NVE State") could be better. In Section 2, definition of "VLAN": "are used in this document denote a C-VLAN", could be "are used in this document to denote a C-VLAN". I enjoyed reading the draft. Thank you. Take ------=_NextPart_000_14AFC_01D1F542.825D8A30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello = David-san,

 

Thank = you for reflecting my comments. I like the revised = sentences.

I hope this draft will be published as an RFC = soon.

 

Best = regards,

Take

 

From:<= /b> Black, = David [mailto:david.black@emc.com]
Sent: Saturday, August 13, = 2016 12:51 AM
To: Takeshi Takahashi = <takeshi_takahashi@nict.go.jp>; = draft-ietf-nvo3-arch.all@ietf.org
Cc: iesg@ietf.org; = secdir@ietf.org; nvo3@ietf.org; Black, David = <david.black@emc.com>
Subject: RE: Secdir review of = draft-ietf-nvo3-arch-06

 

Take-san,

 

Thank you for the review.   I’ve made changes to = address all of your comments in my working copy of this draft that will = be posted as the -07 version next week.

 

The minor comment on information leakage affects both the data plane = and control plane and hence I’ve made changes to address it in two = paragraphs in the Security Considerations section.  Here are the = revised versions of both paragraphs:

 

For the data plane, tunneled application traffic may need protection = against being misdelivered, modified, or having its content exposed to = an inappropriate third party. In all cases, encryption between = authenticated tunnel endpoints and enforcing policies that control which = endpoints and VNs are permitted to exchange traffic can be used to = mitigate risks.

 

[...]

 

Leakage of sensitive information about users or other entities = associated with VMs whose traffic is virtualized can also be covered by = using encryption for the control plane protocols and enforcing policies = that control which NVO3 components are permitted to exchange control = plane traffic.

 

Thanks, --David

 

From: Takeshi = Takahashi [mailto:takeshi_takahashi@nic= t.go.jp]
Sent: Friday, August 12, 2016 11:11 = AM
To: draft-ietf-nvo3-arch.al= l@ietf.org
Cc: iesg@ietf.org; secdir@ietf.org; nvo3@ietf.org
Subject: = Secdir review of = draft-ietf-nvo3-arch-06

 

I have reviewed this document as = part of the security directorate's ongoing effort to review all IETF = documents being processed by the IESG.

These = comments were written primarily for the benefit of the security area = directors.

Document editors and WG chairs should treat = these comments just like any other last call = comments.

 

[General = summary]

This document is = ready.

 

[Topic = of this draft]

This informational document = describes a high-level overview architecture for building data center = network viatualization overlay (NVO3) networks.

It = breaks down the architecture and defines several components needed for = realizing the architecture, such as Network Virtualization Edge (NVE) = and Network Virtualization Authority (NVA).

 

[Minor = Comment]

In Section 16 “Security = Considerations”, you could consider = addressing the policy enforcement issue you've discussed in Section = 5.4.

The sentence starting with "Leakage of = sensitive information" could be, for instance, changed from = "...by using encryption" to "...by using encryption and = ensuring policy enforcement".

 

[Editorial Comment]

In Page = 9, there is a sentence "NVAs provide a service, and NVEs access = that service via an NVE-to-NVA protocol as discussed in Section = 4.3."

This current sentence is fine, but referring = Section 8 "NVE-to-NVA Protocol" (instead of Section 4.3 = "NVE State") could be better.

 

In = Section 2, definition of "VLAN": "are used in this = document denote a C-VLAN", could be "are used in this document = to denote a C-VLAN".

 

I = enjoyed reading the draft.

 

Thank = you.

Take

 

------=_NextPart_000_14AFC_01D1F542.825D8A30-- From nobody Sat Aug 13 17:07:45 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF9E12D60E; Sat, 13 Aug 2016 17:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4oG6CJImAOk; Sat, 13 Aug 2016 17:07:41 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A1BF12B006; Sat, 13 Aug 2016 17:07:41 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id f189so24806406oig.3; Sat, 13 Aug 2016 17:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=Ws7yPmarnJ8DlH48fyRKMJZEyQ1Hvweu4LijQaCSp3M=; b=s2aP5oucpn9MDJKQx/G+leWKSfXvfi45nUejvfNw0Cr8IxnOUmAW+7I19iLDU6wGCv 69nmGiaiWLXCH2IXlphCNgqnfgK1u7HocZ7P7m/PZD3ELhtUWvwHxS2CWbpoqXHQRl8c SZhBH2ruMlohQGTHItKJkI5pPVhdHUS3Kl6mbshIOcvpSX5cNudKSktL1a2QfCA/bn7U +QbJKpSSKaBAOej2a7TIwRfVYt7ztrTr1F2so0sJeOG/Kt9gdecPSqJOtk1IavoZTvFs H4xqYkN2LhpnnMx2JRiazYQyvB7vKCyFepA8/x67/meBnj4323mFkc/fpyavaEWd6rBO 4gZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Ws7yPmarnJ8DlH48fyRKMJZEyQ1Hvweu4LijQaCSp3M=; b=gviMTW2HWz5rlMJmnwjcG1ZZhOCS94NGZL2AcLHRqXond2sp6a1pXjEWYGMaUytIx7 7bvOHs5DuXuFehm/zapGd7yANVG3O/kJ520RHwI7rl/tTLPGR7N54xn2eUt138tN4Er2 F72OPkhEl9M5Y5yijlB9Xgy/Q1iOnM1vwN0EAZN/mAt8DMK+8McPowbV329xNClo14q0 RXoZdGm4ZY4nzbx3dRr6aaSXE4Elqs0GVZ0791sE6uYYWa3fOoIKHf7oxXhW8IoAoxAb P9mqxb1SHgwqfoNhQASHzS3zfFAA4+TRU2quQc06IFv2VuaiRCj35Wxojjv8gR8g+HGl N5BA== X-Gm-Message-State: AEkoouv3q87UrcriBbQCkXCaKB+xtpZ00EbsNw1uIU++mTDi3/WHE4C4vKhcZHxWfONKzTs7h0MJcZMN5LtKNQ== X-Received: by 10.202.198.78 with SMTP id w75mr11651578oif.134.1471133260509; Sat, 13 Aug 2016 17:07:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.81.227 with HTTP; Sat, 13 Aug 2016 17:07:39 -0700 (PDT) From: Radia Perlman Date: Sat, 13 Aug 2016 17:07:39 -0700 Message-ID: To: "secdir@ietf.org" , The IESG , draft-ietf-i2rs-protocol-security-requirements.all@tools.ietf.org Content-Type: multipart/alternative; boundary=001a11c17da668f8180539fce746 Archived-At: Subject: [secdir] Secdir review of draft-ietf-i2rs-protocol-security-requirements-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2016 00:07:43 -0000 --001a11c17da668f8180539fce746 Content-Type: text/plain; charset=UTF-8 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document is about the security requirements between a management station (what I assume a "I2RS client" is) and the agent on a "routing system". These include mutual authentication, transport security, atomicity. The document is well-written and ready, with nits. I haven't been following this WG, so apologies for perhaps not getting the terminology, though it might be better if every document were self contained, in defining terms, or pointing to a different document where all the terms are defined. The meaning of the term in the spec "routing system" is not obvious to me. I'm assuming it means not only routers but anything that looks at layer 3 such as load splitters and hypervisors, is that correct? Maybe the term is defined in a different document? If not, a clarifying sentence would be appreciated by readers. In section "I2RS multi-message atomicity" "this is not supported in order to simply the first version of I2RS" should be "simplify" "If insecure transport is used, then confidentiality and integrity cannot be achieved" That statement, as a sweeping statement, isn't true, since, for instance, Ethernet does not provide any confidentiality and integrity, but protocols can achieve confidentiality and integrity by doing it themselves. So perhaps the statement should be softened to say something like "I2RS does not itself provide confidentiality and integrity, so it depends on running over a secure Transport that provides these features". "All I2RS clients and I2RS agents MUST have an identity, and at least one unique identifier that uniquely identifies each party in the I2RS protocol context." This might be overly restrictive. You might want several I2RS clients acting as instances of a single identity, in which case, they might all share the same identity. " SEC-REQ-06: The I2RS protocol SHOULD assume some mechanism (IETF or private) will distribute or load identifiers so that the I2RS client/agent has these identifiers prior to the I2RS protocol establishing a connection between I2RS client and I2RS agent." Instead of "distribute or load", perhaps "configure" would be clearer? At any rate, I don't know the difference between "distribute" and "load". Radia --001a11c17da668f8180539fce746 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I have reviewed this document as part= of the security directorate's ongoing effort to review all IETF docume= nts being processed by the IESG.

These comments were written primarily for the benefit of the security ar= ea directors.

Document editors= and WG chairs should treat these comments just like any other last call co= mments.


= The document is about the security requirements between a management statio= n (what I assume a "I2RS client" is) and the agent on a "r= outing system". These include mutual authentication, transport securit= y, atomicity.

<= span lang=3D"EN-US" style=3D"font-size:11pt">

The document is well-written and ready, with nits.


I haven't been followi= ng this WG, so apologies for perhaps not getting the terminology, though it= might be better if every document were self contained, in defining terms, = or pointing to a different document where all the terms are defined.=


The meaning of= the =C2=A0term in the spec =C2=A0"routing system" is not obvio= us to me. I'm assuming it means not only routers but anything that loo= ks at layer 3 such as load splitters and hypervisors, is that correct? May= be the term is defined in a different document? If not, a clarifying sente= nce would be appreciated by readers.


In section &qu=
ot;I2RS multi-message atomicit=
y"
"this =
is not supported in ord=
er to simply the first version of I2RS" 
should be "simplify"

"If insecure transport is used, then confidentiality and integrity cannot be achieved"=

That statement, as a sweeping statement, isn't true, since,=
 for instance, Ethernet does not provide any confidentiality and integrity,=
 but protocols can achieve confidentiality and integrity by doing it themse=
lves.  So perhaps the statement should be softened to say something like &q=
uot;I2RS does not itself provide confidentiality and integrity, so it depen=
ds on running over a secure Transport that provides these features".

"All I2RS cli=
ents and I2RS agents MUST have an identity, and at least one unique identifier that uniquely identifies each party in the=
 I2RS protocol context."

Thi=
s might be overly restrictive.  You might want several I2RS clients acting =
as instances of a single identity, in which case, they might all share the =
same identity.  
&quo=
t; SEC-REQ-06: The I2RS protocol SHOULD assume some mechanism (IETF
      or private) will distribute or load identifiers so that the I2RS
      client/agent has these identifiers prior to the I2RS protocol
      establishing a connection between I2RS client and I2RS agent."

Instead of "distr=
ibute or load", perhaps "configure" would be clearer?  At an=
y rate, I don't know the difference between "distribute" and =
"load".

Rad=
ia

--001a11c17da668f8180539fce746-- From nobody Sun Aug 14 19:50:04 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550E312D60F; Sun, 14 Aug 2016 19:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkEKs3efjzHa; Sun, 14 Aug 2016 19:50:02 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 443E612D5D3; Sun, 14 Aug 2016 19:50:02 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id h186so13148525pfg.3; Sun, 14 Aug 2016 19:50:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=qfs5J22ihnXBiRJQwLRnXdTPm4wmz0xEBkCE0m+km9E=; b=H6VLHanxEOvw7vQSH/BnRCKRZYqcxTOqQKHSFt1S9Ct3jVE49Hczk97+38Z7uIqB+8 v1c+uat2bTIHqcIkyZE1cj6iS+AjZ/q3ugB0BJOMz6owLiX/MTT7Umq0p0VlqBE7rvMF q/5hQif5n8gCEhCRux041K/idF3uqtFvC4yFo+ZMfR5URdseF7sGi/eQgFRB0VqvOjE0 a/T3CAuxHlbwDnhvnh6auvWvUOpiutXtY0qzLVVwhyGoNZng80neFKCbalFEHwq+QCtQ 6jHiaprwPKYa9hEHQVrIiW2PVWGV3H3XT0DG8f1xrSEK8HLAw4mXuAVoWqnKkrwP7TZH 5Dvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=qfs5J22ihnXBiRJQwLRnXdTPm4wmz0xEBkCE0m+km9E=; b=MK7ZBpfStjKcDvUpg6Ud97CLCtCngGFDOMC4QoZN0qcXkZKSH6OsupvbOa3Zyuxbue WNbwOFrJ4B2wtgZWJWdr7CHC0aCRnzXc5W+hh68BT6GQ9KELxeiISqBD9CUZE18iMIpg ddJKP5PWLJMTJ/Ghqs3yJfwJ68a7683X69l6AUGbh3mmabyQBOGR+dsMqy7l0P2fuUsi rIVqiM7ZK5m3savmIckAabZo0/eR5Nm+YLD5p2yvLYUu5E47E3dBlyFdhDv7/isSMBDH 7egZPb3A7TcYXFY1t6y7XkybI4KZsdi6jgSDX8wnFSjo1oVKE8ln5Oc03aX35Lz4eOQE 7NOw== X-Gm-Message-State: AEkoouv91AyDkekn9Df1a/O7oy7zjADH+oAl/5DzbO5xvuAoL7/C9pACUDgL1zdvN332rA== X-Received: by 10.98.56.207 with SMTP id f198mr50130962pfa.83.1471229401289; Sun, 14 Aug 2016 19:50:01 -0700 (PDT) Received: from ?IPv6:2406:e007:7af7:1:28cc:dc4c:9703:6781? ([2406:e007:7af7:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id k66sm28624668pfc.30.2016.08.14.19.49.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Aug 2016 19:50:00 -0700 (PDT) To: Ben Laurie , "secdir@ietf.org" , draft-ietf-6man-multi-homed-host.all@ietf.org References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <62415758-095c-b133-25f7-e922d0c50653@gmail.com> Date: Mon, 15 Aug 2016 14:49:57 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] draft-ietf-6man-multi-homed-host-07 security review X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 02:50:03 -0000 Sorry, we didn't reply to this promptly due to bigger issues coming up, but thanks, and we will cover this point in the next version. Regards Brian Carpenter On 04/08/2016 22:45, Ben Laurie wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > Status: ready with nits. > > The document claims to introduce no new security exposure, but it > seems to me that it is designed to ensure routing occurs correctly in > situations where it previously didn't - this may result in unexpected > exposure of networks that previously were unreachable. > > I think this is a nit, because clearly such networks were poorly > designed in the first place, but perhaps a mention should be made? > From nobody Mon Aug 15 12:20:54 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78D112B019; Mon, 15 Aug 2016 12:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-Iv5VC4mDcU; Mon, 15 Aug 2016 12:20:49 -0700 (PDT) Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FEB1126D74; Mon, 15 Aug 2016 12:20:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.28,526,1464645600"; d="scan'208";a="41812758" Received: from post.haw-hamburg.de (HELO HUB01.mailcluster.haw-hamburg.de) ([141.22.24.50]) by mail6.is.haw-hamburg.de with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Aug 2016 21:20:43 +0200 Received: from CAS03.mailcluster.haw-hamburg.de (2002:8d16:183e::8d16:183e) by HUB01.mailcluster.haw-hamburg.de (2002:8d16:1832::8d16:1832) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 15 Aug 2016 21:20:42 +0200 Received: from [192.168.178.147] (141.22.250.35) by haw-mailer.haw-hamburg.de (141.22.24.62) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 15 Aug 2016 21:20:42 +0200 To: Russ Housley , "draft-ietf-p2psip-share.all@ietf.org" References: <46d6459124394dddbff5e9d7f48bf23b@HUB02.mailcluster.haw-hamburg.de> From: "Thomas C. Schmidt" Message-ID: <71ec7240-8b2d-2f47-034e-f10faba8ea27@haw-hamburg.de> Date: Mon, 15 Aug 2016 21:20:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <46d6459124394dddbff5e9d7f48bf23b@HUB02.mailcluster.haw-hamburg.de> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [141.22.250.35] Archived-At: Cc: Alissa Cooper , IETF SecDir Subject: Re: [secdir] Early SecDir Review of draft-ietf-p2psip-share-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 19:20:52 -0000 Russ, I'm only now coming back to this long delayed issue - sorry for that. Let me summarize the story about indexing (Section 3.1 in ShaRe): 1. The application use case for shared resources is that of a small group of peers sharing a data structure, which can be an array. Array indexing according to Sec. 3.1 uses parts of the Node-ID (the 24 least significant bits of a SHA-1 hash) to generate isolation among peers, and at the same time generate an unambiguous, unique binding between a node and the array elements it is allowed to write. 2. The threat of collisions is that this binding becomes ambiguous and - if not prevented - would cause an option for theft of resource/service. There is no threat of privilege escalation, here, as entries are signed. 3. SHA-1 is collision-resistant and the probability of collisions is expected to be low [1], but the output is not perfectly random. So I agree that the ref to the RFC 3550 calculation is a bit too optimistic. However, neither me nor a crypto colleague could find a rigorous calculation of the SHA-1 collision probability ... 4. The straight-forward counter measure against theft of resources in the case of a collision is a refusal of overwriting by the storing peer (see end of Section 6.1). This may exclude a node with colliding ID bits from participation in sharing a resource. Now I see two choices: (1) We leave it that way, i.e., clarify the text in Section 3.1 and point out that a node under collision could re-join the overlay with a different node-ID. (2) We could advise a procedure to generate non-colliding ID bits by rehashing the node-ID. I.e., a node that experiences a collision could rehash its ID to obtain new ID bits and the storing peer could validate by also iterating the hashing. (2) would complicate the whole process for considerably rare cases, why I'm in favor of (1). What would you suggest? Thanks, Thomas [1] K. Chung, M. Mitzenmacher, and S. Vadhan: Why Simple Hash Functions Work: Exploiting the Entropy in a Data Stream, Theory of Computing , vol 9, pp. 897-945. On 01.04.2016 01:21, Russ Housley wrote: > I reviewed this document for the Security Directorate after a request > by the ART AD for an early review. > > Version reviewed: draft-ietf-p2psip-share-08 > > > Summary: Not Ready (from a Security Directorate perspective) > > > Major Concerns: > > In Section 3.1, there is an algorithm for assigning index values, and > the text says that the high-order 24 bits of the Node-ID serve as a > pseudo-random identifier. Since these 24 bits are obtained from the > certificate that will be used to sign the stored data, the I think that > the same bits will be used over and over. If I got this correct, then > they are not pseudo-random. > > In addition, Section 3.1 points to RFC 3550, Section 8.1 for a > discussion of the probability of a collision. The consequences of a > collision seem to be different in the two documents. The consequences > of a collision in the index should be clearly described in this > document. > > > Minor Concerns: None > > > Nits: > > Please pick one spelling for Resource-IDs. (This is the spelling used > in RFC 6940.) However, this document sometimes uses "Resource Id". > > Section 4.1 includes several examples for array indices. All of > them are more than 32 bits: 0x123abc001, 0x123abc002, 0x123abc003, > 0x123abc004, and 0x456def001. The most straightforward solution is > to drop one of the zero digits. > > To improve readability, I think the first sentence of Section 5.1 > should read: "In certain use cases, such as conferencing, it is > desirable..." > > Section 5.1 says: > > When defining the pattern, care must be taken to avoid conflicts > arising from two user names of witch one is a substring of the other. > > I think this paragraph would be improved with an acceptable example and > a problematic example. > > In Section 5.3: s/AOR/Address of Record (AOR)/ > > In Section 6.2: s/This allows to invalidate entire subtrees/ > /This allows the invalidation of entire subtrees/ > > In Section 8, please provide a reference for RELOAD. > -- Prof. Dr. Thomas C. Schmidt Hamburg University of Applied Sciences Berliner Tor 7 Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 From nobody Mon Aug 15 12:56:15 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF6212D76D for ; Mon, 15 Aug 2016 12:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=redhoundsoftware-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ye679tp_7FvS for ; Mon, 15 Aug 2016 12:56:13 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DB2F12D768 for ; Mon, 15 Aug 2016 12:56:13 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id w38so25871910qtb.0 for ; Mon, 15 Aug 2016 12:56:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware-com.20150623.gappssmtp.com; s=20150623; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :mime-version:content-transfer-encoding; bh=dJMhGiBB0rr3mnd78VeaRF++unrNucAp9WA1as42Tec=; b=sqm/cXeAu8NMX9Q55Vpu0MB97zSSA50kWlA9e2OqVTNfXQgMs4a1inF1GnMdnJ3RXO Nin8rHFnyEGsV3DqALDNcj+qpxuu+coSdRVszHkvBgY/hPr9ZrDEIUF56rVHlvQbABHk TVRBz4HYWD2GSasKmSjvKlDO+sf26eV9Qn8AchRIzJ5vbiQTLgihVxDJVdEoK/JbpZ67 zTEgw6J7howheiNqhEbJEChm8Zrf0lhFOwBuz3C3HUCJkryaU1qxh7+dhEGriyVpaj5V NfBBprpzNND7iLAXqt/+U9hSPYHT0QShWbcvRi3Og7NWqhgoJcgFEmotsQfU11Zt03py nGlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:mime-version:content-transfer-encoding; bh=dJMhGiBB0rr3mnd78VeaRF++unrNucAp9WA1as42Tec=; b=h2J1Sd7mtCDZDFPqwnBP/riiAPeMloJvXfqUmyfClRq7Iuk60RZTUba61KyfBzznCL RrSTGXE4d8D7O8hsKzS7eY5aMuQswFOKKMdkohLF7IoCmM6w8lcpqbrPBsLm1C/0LaX9 Xzw7gS1Nm3qVaMB0cqd/GuudYYqZhCT2QXAM6MoyM4UG0gvKEUXyORFzF7KdGDbQqjxk HKT6+alGRijtg7gTzwzZ3SQOzkJI9RwDIyPWpIboCnRNhl+WeP801AuNzIjF8M39IrUP AtnthQPdQ4sdMd9h0TpYg2eHnP8MlbRJN9EsIcgt8RHUKKz4Y7dXXwISkpbjaQ7yq8tr Ia+Q== X-Gm-Message-State: AEkooutAX+cDoMaqf6/3HFGpE7/HJuiMNBwi+MP84nPsjn8QbPZF3uDkYyVLwbkLnJWn2w== X-Received: by 10.200.46.25 with SMTP id r25mr34336892qta.114.1471290972081; Mon, 15 Aug 2016 12:56:12 -0700 (PDT) Received: from [192.168.2.29] (pool-96-255-23-4.washdc.fios.verizon.net. [96.255.23.4]) by smtp.gmail.com with ESMTPSA id p2sm13249253qta.15.2016.08.15.12.56.09 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 15 Aug 2016 12:56:11 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.5.8.151023 Date: Mon, 15 Aug 2016 15:56:05 -0400 From: Carl Wallace To: Message-ID: Thread-Topic: secdir review of draft-ietf-radext-ip-port-radius-ext-10 Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Cc: iesg@ietf.org, secdir@ietf.org Subject: [secdir] secdir review of draft-ietf-radext-ip-port-radius-ext-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 19:56:14 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines three new RADIUS attributes. For devices that implement IP port ranges, these attributes are used to communicate with a RADIUS server in order to configure and report TCP/UDP ports and ICMP identifiers, as well as mapping behavior for specific hosts. I've a few questions/comments: - The Security Considerations section currently references the security considerations from 2865 and 5176. Should 6887 be included to address considerations related to the forwarding attribute? - When the port limit attribute is used, does presentation of a new "global" setting undo previously established IP specific settings (or vice versa)? - Should the IP-Port-Range attribute require at least one of IP-Port-Ext-IPv4-Addr or IP-Port-Local-Id to be present? How is the attribute used when both are absent? - The summary statement associated with the attributes in section 1 might benefit from indicating the purpose of the attribute relative to each packet type in which it may appear (for example, the purpose of a port limit info attribute is different when included in an Access-Request than in an Access-Response). - Each attribute lists applicable packet types and indicates the attribute must not appear in any other packet type. It may be worth adding a note to clarify what should happen if the attribute does appear (assuming ignore). - The UE acronym on page 30 should be expanded. - In 3.1.2, change "are previously allocated" to "were previously allocated". - In 4.1.3, is "RADIUS associate" a commonly used term? This seems like a requirement on use with CoA-Requests that should be mentioned earlier. From nobody Wed Aug 17 02:29:27 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A3312D522; Wed, 17 Aug 2016 02:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.767 X-Spam-Level: X-Spam-Status: No, score=-15.767 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfUpPnxcg1RX; Wed, 17 Aug 2016 02:29:24 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ADF412D08C; Wed, 17 Aug 2016 02:29:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19282; q=dns/txt; s=iport; t=1471426164; x=1472635764; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QQY+/YlrrRnABro/PuzV3hqpML7STqaVX2xa8lh6vWc=; b=ZBYtLic7sVe/NyH89G3Z9t9816VXzbFD9P0X8WcPCf2fWRGUhvy/M7Jm QdgiqRl/dEPJ6L5dqEAytr5C8KoCRnQMX1NIDbOh6C7Phn4ubm/Y2m1gQ XOxSg6T0LR00sPGuLhATSFuFNctejMotFwRGpLnDTmEWWI2kU00JnB4DD w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B7AgC5LbRX/5tdJa1egnZOVnwHtCmFB?= =?us-ascii?q?4F9hh0CHIFGOBQCAQEBAQEBAV4nhF4BAQUjCkwQAgEIEQQBASsCAgIwHQgCBAE?= =?us-ascii?q?NBQiIKa57kC4BAQEBAQEBAQEBAQEBAQEBAQEBAQEchiqETYQqgxeCWgWTfYVHA?= =?us-ascii?q?Y8Vj0+MOYN3AR42g3puAYUdKxl/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,529,1464652800"; d="scan'208,217";a="311153782" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Aug 2016 09:29:23 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u7H9TN1g011972 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 17 Aug 2016 09:29:23 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 17 Aug 2016 04:29:22 -0500 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1210.000; Wed, 17 Aug 2016 04:29:22 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "Brian Weis (bew)" , "secdir@ietf.org" , The IESG Thread-Topic: SecDir review of draft-ietf-tram-turn-server-discovery-08 Thread-Index: AQHR9EQtsMc8iAoZw0eiSM9NE0uIMaBM6nUQ Date: Wed, 17 Aug 2016 09:29:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.232.21.168] Content-Type: multipart/alternative; boundary="_000_e67a4ec09e8b487dbb745c09e7a52767XCHRCD017ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-tram-turn-server-discovery.all@tools.ietf.org" Subject: Re: [secdir] SecDir review of draft-ietf-tram-turn-server-discovery-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 09:29:26 -0000 --_000_e67a4ec09e8b487dbb745c09e7a52767XCHRCD017ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQnJpYW4sDQoNClRoYW5rcyBmb3IgdGhlIHJldmlldywgcmV3b3JkZWQgdGhlIHBhcmFncmFw aCBhcyBwZXIgeW91ciBzdWdnZXN0aW9uIGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBz ZWN0aW9uLg0KDQpCZXN0IFJlZ2FyZHMsDQotVGlydQ0KRnJvbTogQnJpYW4gV2VpcyAoYmV3KQ0K U2VudDogRnJpZGF5LCBBdWd1c3QgMTIsIDIwMTYgODoyMCBBTQ0KVG86IHNlY2RpckBpZXRmLm9y ZzsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQpDYzogZHJhZnQtaWV0Zi10cmFtLXR1cm4tc2Vy dmVyLWRpc2NvdmVyeS5hbGxAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFNlY0RpciByZXZpZXcg b2YgZHJhZnQtaWV0Zi10cmFtLXR1cm4tc2VydmVyLWRpc2NvdmVyeS0wOA0KDQpJIGhhdmUgcmV2 aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdz IG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vz c2VkIGJ5IHRoZSBJRVNHLiBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZv ciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMuIERvY3VtZW50IGVk aXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtl IGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQoNCkkgY29uc2lkZXIgdGhpcyBkcmFmdCB0 byBiZSBSZWFkeSB3aXRoIG5pdHMuDQoNClRVUk4gc2VydmVycyBhcmUgdXNlZCB0byBjb25uZWN0 IGRldmljZXMgcnVubmluZyBQZWVyLXRvLVBlZXIgYXBwbGljYXRpb25zLCBzdWNoIGFzIHJlYWwt dGltZSBjb21tdW5pY2F0aW9uLiBUeXBpY2FsbHkgdGhlc2UgVFVSTiBzZXJ2ZXJzIGFyZSBub3Qg dW5kZXIgYSBsb2NhbCBuZXR3b3Jr4oCZcyBhZG1pbmlzdHJhdGl2ZSBjb250cm9sIChlLmcuLCB0 aGUgZW50ZXJwcmlzZSBvciBJU1AgaG9zdGluZyB0aGUgY29tbXVuaWNhdGluZyBkZXZpY2VzLiBU aGlzIGRyYWZ0IHByb3ZpZGVzIGEgc2VydmVyIGRpc2NvdmVyeSBtZXRob2QgdG8gYSBUVVJOIHNl cnZlciB0aGF0IGlzIHVuZGVyIHRoZSBhZG1pbmlzdHJhdGl2ZSBjb250cm9sIG9mIHRoZSBsb2Nh bCBuZXR3b3JrLiBUaGVyZSBhcmUgc29tZSBzZWN1cml0eSBhbmQgb3BlcmF0aW9uYWwgYWR2YW50 YWdlcyB0byB0aGUgdXNlIG9mIGEgbG9jYWwgVFVSTiBzZXJ2ZXIsIHNpbmNlIHRoZSBsb2NhbCBz ZXJ2aWNlIGNhbiB0ZW5kIHRvIGtlZXAgdGhlIHJlYWwtdGltZSBjb21tdW5pY2F0aW9uIChvciBv dGhlciBhcHBsaWNhdGlvbikgbWVzc2FnZXMgZnJvbSBsZWF2aW5nIHRoZSBsb2NhbCBuZXR3b3Jr LiBUaGlzIGlzIHVzZWZ1bC4gVGhlIG1ldGhvZHMgZm9yIGF1dG8tZGlzY292ZXJpbmcgbG9jYWwg VFVSTiBzZXJ2ZXJzIGRpc2N1c3NlZCBpbiB0aGUgZG9jdW1lbnQgaW5jbHVkZSBETlMgU2Vydmlj ZSBSZXNvbHV0aW9uLCBETlMgU2VydmljZSBEaXNjb3ZlcnksICBhbmQgQW55Y2FzdC4NCg0KVGhl IG1haW4gc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBvZiB1c2luZyB1c2luZyBzZXJ2ZXIgZGlzY292 ZXJ5IG1ldGhvZHMgd291bGQgc2VlbSB0byBiZSBlbnN1cmluZyB0aGF0IGFuIGF1dGhvcml6ZWQg bG9jYWwgU1RVTiBzZXJ2ZXIgaGFzIGJlZW4gcmVhY2hlZC4gVGhlIFNlY3VyaXR5IENvbnNpZGVy YXRpb25zIHNlY3Rpb24gbWVudGlvbnMgU1RVTiBhdXRoZW50aWNhdGlvbiBhcyBPUFRJT05BTCBm b3Ig4oCcVFVSTiBzZXJ2ZXJzIHByb3ZpZGVkIGJ5IHRoZSBsb2NhbCBuZXR3b3JrIG9yIGJ5IHRo ZSBhY2Nlc3MgbmV0d29ya+KAnSwgYnV0ICJpdCBpcyBSRUNPTU1FTkRFRCB0aGF0IHRoZSBUVVJO IGNsaWVudCB1c2Ugb25lIG9mIHRoZSBmb2xsb3dpbmcgdGVjaG5pcXVlcyB3aXRoIChEKVRMU+KA nS4gV2hlbiAoRClUTFMgaXMgdXNlZCwgc2V2ZXJhbCBtZWNoYW5pc21zIGFyZSBkZXNjcmliZWQg d2hlcmVieSB0aGUgY2xpZW50IGNhbiBkZXRlcm1pbmUgdGhhdCBhIFNUVU4gc2VydmVyIGlzIGF1 dGhvcml6ZWQuIFRoZSByZXF1aXJlbWVudHMgbGFuZ3VhZ2UgaXMgYSBiaXQgb2JzY3VyZSwgYnV0 IHRoZSByZXN1bHQgaXMgcmVjb21tZW5kaW5nIHRoYXQgKEQpVExTIGF1dGhlbnRpY2F0aW9uIGFu ZCBhdXRob3JpemF0aW9uIGlzIHVzZWQsIHdoaWNoIGlzIGZpbmUuDQoNClRoZSBTZWN1cml0eSBD b25zaWRlcmF0aW9ucyBzZWN0aW9uIGFsc28gcmVjb21tZW5kcyB3aGF0IGEgY2xpZW50IG91Z2h0 IHRvIGRvIHdoZW4gYXV0aGVudGljYXRlZCAoRClUTFMgaXNu4oCZdCBwb3NzaWJsZS4gVGhlIHBh cmFncmFwaCBqdXN0IGJlZm9yZSBTZWN0aW9uIDkuMSBjb250YWlucyBnb29kIGFkdmljZSwgYnV0 IGl0IGNvdWxkIGJlIGNsZWFyZXIuIEZvciBleGFtcGxlIHRoZSBwYXJhZ3JhcGggY29uZnVzZXMg cHJpdmFjeSBnb2FscyB3aXRoIHRoZSBzZWN1cml0eSBnb2FsIG9mIG1pdGlnYXRpbmcgb24tcGF0 aCBpbmplY3Rpb24gb2Ygc3Bvb2ZlZCBwYWNrZXRzLiBJIHN1Z2dlc3QgcmV3b3JkaW5nIHRoaXMg cGFyYWdyYXBoIHdpdGggdGV4dCBzb21ldGhpbmcgbGlrZSB0aGlzOg0KDQogICBJbiBzb21lIGF1 dG8tZGlzY292ZXJ5IHNjZW5hcmlvcywgaXQgbWlnaHQgbm90IGJlIHBvc3NpYmxlIGZvciB0aGUN CiAgIFRVUk4gY2xpZW50IHRvIHVzZSAoRClUTFMgYXV0aGVudGljYXRpb24gdG8gdmFsaWRhdGUg dGhlIFRVUk4gc2VydmVyLg0KICAgSG93ZXZlciwgZmFsbC1iYWNrIHRvIGNsZWFyIHRleHQgaW4g c3VjaCBjYXNlcyBjb3VsZCBsZWF2ZSB0aGUgVFVSTg0KICAgY2xpZW50IG9wZW4gdG8gb24tcGF0 aCBpbmplY3Rpb24gb2Ygc3Bvb2ZlZCBUVVJOIG1lc3NhZ2VzLg0KICAgSW5zdGVhZCwgYSBUVVJO IGNsaWVudCBTSE9VTEQgZmFsbC1iYWNrIHRvIGVuY3J5cHRpb24tb25seQ0KICAgKEQpVExTIHdo ZW4gKEQpVExTIGF1dGhlbnRpY2F0aW9uIGlzIG5vdCBhdmFpbGFibGUuIEFub3RoZXIgcmVhc29u DQogICB0byBmYWxsLWJhY2sgdG8gZW5jcnlwdGlvbi1vbmx5IGlzIGZvciBwcml2YWN5LCB3aGlj aCBpcw0KICAgYW5hbG9nb3VzIHRvIFNNVFAgb3Bwb3J0dW5pc3RpYyBlbmNyeXB0aW9uDQogICBb UkZDNzQzNV0gIHdoZXJlIG9uZSBkb2VzIG5vdCByZXF1aXJlIHByaXZhY3kgYnV0IG9uZSBkZXNp cmVzIHByaXZhY3kNCiAgIHdoZW4gcG9zc2libGUuDQoNCiAgIEl0IGlzIHN1Z2dlc3RlZCB0aGF0 IGEgVFVSTiBjbGllbnQgYXR0ZW1wdCAoRClUTFMgd2l0aA0KICAgYXV0aGVudGljYXRpb24gYW5k IGVuY3J5cHRpb24sIGZhbGxpbmcgYmFjayB0byBlbmNyeXB0aW9uLW9ubHkgaWYgdGhlDQogICBU VVJOIHNlcnZlciBjYW5ub3QgYmUgYXV0aGVudGljYXRlZCB2aWEgKEQpVExTLiAgVGhlIFRVUk4g c2VydmVyDQogICBjb3VsZCBmYWxsIGJhY2sgdG8gY2xlYXIgdGV4dCBpZiBpdCAgZG9lcyBub3Qg c3VwcG9ydCB1bmF1dGhlbnRpY2F0ZWQgKEQpVExTLA0KICAgYnV0IGZhbGxiYWNrIHRvIGNsZWFy IHRleHQgaXMgTk9UIFJFQ09NTUVOREVEIGJlY2F1c2UgaXQgbWFrZXMNCiAgIHRoZSBjbGllbnQg bW9yZSBzdXNjZXB0aWJsZSB0byBtYW4taW4tdGhlLW1pZGRsZSBhdHRhY2tzIGFuZCBvbi1wYXRo DQogICBwYWNrZXQgaW5qZWN0aW9uLg0KDQoNClRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBp biBlYWNoIG9mIHRoZSBzdWItc2VjdGlvbnMgaXMgZ29vZCBhcyB3cml0dGVuLg0KDQpCcmlhbg0K DQo= --_000_e67a4ec09e8b487dbb745c09e7a52767XCHRCD017ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5IaSBCcmlhbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgdGhlIHJldmlldywgcmV3b3JkZWQgdGhlIHBhcmFncmFw aCBhcyBwZXIgeW91ciBzdWdnZXN0aW9uIGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBz ZWN0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QmVzdCBS ZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4tVGlydTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4gQnJpYW4gV2VpcyAoYmV3KQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZy aWRheSwgQXVndXN0IDEyLCAyMDE2IDg6MjAgQU08YnI+DQo8Yj5Ubzo8L2I+IHNlY2RpckBpZXRm Lm9yZzsgVGhlIElFU0cgJmx0O2llc2dAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBkcmFm dC1pZXRmLXRyYW0tdHVybi1zZXJ2ZXItZGlzY292ZXJ5LmFsbEB0b29scy5pZXRmLm9yZzxicj4N CjxiPlN1YmplY3Q6PC9iPiBTZWNEaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtdHJhbS10dXJuLXNl cnZlci1kaXNjb3ZlcnktMDg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1 cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1 bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiBUaGVzZSBjb21tZW50cyB3ZXJlIHdy aXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiZuYnNwO3RoZSBzZWN1cml0eSBhcmVh IGRpcmVjdG9ycy4gRG9jdW1lbnQNCiBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0 IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0K PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGNvbnNpZGVy IHRoaXMgZHJhZnQgdG8gYmUgPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQiPlJlYWR5IHdp dGggbml0cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UVVJOIHNlcnZlcnMgYXJlIHVzZWQgdG8gY29ubmVjdCBkZXZpY2VzIHJ1bm5pbmcgUGVl ci10by1QZWVyIGFwcGxpY2F0aW9ucywgc3VjaCBhcyByZWFsLXRpbWUgY29tbXVuaWNhdGlvbi4g VHlwaWNhbGx5IHRoZXNlIFRVUk4gc2VydmVycyBhcmUgbm90IHVuZGVyIGEgbG9jYWwgbmV0d29y a+KAmXMgYWRtaW5pc3RyYXRpdmUgY29udHJvbCAoZS5nLiwgdGhlIGVudGVycHJpc2Ugb3IgSVNQ IGhvc3RpbmcgdGhlIGNvbW11bmljYXRpbmcNCiBkZXZpY2VzLiBUaGlzIGRyYWZ0IHByb3ZpZGVz IGEgc2VydmVyIGRpc2NvdmVyeSBtZXRob2QgdG8gYSBUVVJOIHNlcnZlciB0aGF0IGlzIHVuZGVy IHRoZSBhZG1pbmlzdHJhdGl2ZSBjb250cm9sIG9mIHRoZSBsb2NhbCBuZXR3b3JrLiBUaGVyZSBh cmUgc29tZSBzZWN1cml0eSBhbmQgb3BlcmF0aW9uYWwgYWR2YW50YWdlcyB0byB0aGUgdXNlIG9m IGEgbG9jYWwgVFVSTiBzZXJ2ZXIsIHNpbmNlIHRoZSBsb2NhbCBzZXJ2aWNlIGNhbiB0ZW5kIHRv DQoga2VlcCB0aGUgcmVhbC10aW1lIGNvbW11bmljYXRpb24gKG9yIG90aGVyIGFwcGxpY2F0aW9u KSBtZXNzYWdlcyBmcm9tIGxlYXZpbmcgdGhlIGxvY2FsIG5ldHdvcmsuIFRoaXMgaXMgdXNlZnVs LiBUaGUgbWV0aG9kcyBmb3IgYXV0by1kaXNjb3ZlcmluZyBsb2NhbCBUVVJOIHNlcnZlcnMgZGlz Y3Vzc2VkIGluIHRoZSBkb2N1bWVudCBpbmNsdWRlIEROUyBTZXJ2aWNlIFJlc29sdXRpb24sIERO UyBTZXJ2aWNlIERpc2NvdmVyeSwgJm5ic3A7YW5kIEFueWNhc3QuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBtYWluIHNlY3VyaXR5IGNv bnNpZGVyYXRpb24gb2YgdXNpbmcgdXNpbmcgc2VydmVyIGRpc2NvdmVyeSBtZXRob2RzJm5ic3A7 d291bGQgc2VlbSB0byBiZSBlbnN1cmluZyB0aGF0IGFuIGF1dGhvcml6ZWQgbG9jYWwgU1RVTiBz ZXJ2ZXIgaGFzIGJlZW4gcmVhY2hlZC4gVGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rp b24gbWVudGlvbnMgU1RVTiBhdXRoZW50aWNhdGlvbiBhcyBPUFRJT05BTCBmb3Ig4oCcVFVSTg0K IHNlcnZlcnMgcHJvdmlkZWQgYnkgdGhlIGxvY2FsIG5ldHdvcmsgb3IgYnkgdGhlIGFjY2VzcyBu ZXR3b3Jr4oCdLCBidXQgJnF1b3Q7aXQgaXMgUkVDT01NRU5ERUQgdGhhdCB0aGUgVFVSTiBjbGll bnQgdXNlIG9uZSBvZiB0aGUgZm9sbG93aW5nIHRlY2huaXF1ZXMgd2l0aCAoRClUTFPigJ0uIFdo ZW4gKEQpVExTIGlzIHVzZWQsIHNldmVyYWwgbWVjaGFuaXNtcyBhcmUgZGVzY3JpYmVkIHdoZXJl YnkgdGhlIGNsaWVudCBjYW4gZGV0ZXJtaW5lIHRoYXQgYSBTVFVODQogc2VydmVyIGlzIGF1dGhv cml6ZWQuIFRoZSByZXF1aXJlbWVudHMgbGFuZ3VhZ2UgaXMgYSBiaXQgb2JzY3VyZSwgYnV0IHRo ZSByZXN1bHQgaXMgcmVjb21tZW5kaW5nIHRoYXQgKEQpVExTIGF1dGhlbnRpY2F0aW9uIGFuZCBh dXRob3JpemF0aW9uIGlzIHVzZWQsIHdoaWNoIGlzIGZpbmUuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBTZWN1cml0eSBDb25zaWRlcmF0 aW9ucyBzZWN0aW9uIGFsc28gcmVjb21tZW5kcyB3aGF0IGEgY2xpZW50IG91Z2h0IHRvIGRvIHdo ZW4gYXV0aGVudGljYXRlZCAoRClUTFMgaXNu4oCZdCBwb3NzaWJsZS4gVGhlIHBhcmFncmFwaCBq dXN0IGJlZm9yZSBTZWN0aW9uIDkuMSBjb250YWlucyBnb29kIGFkdmljZSwgYnV0IGl0IGNvdWxk IGJlIGNsZWFyZXIuIEZvciBleGFtcGxlIHRoZSBwYXJhZ3JhcGggY29uZnVzZXMNCiBwcml2YWN5 IGdvYWxzIHdpdGggdGhlIHNlY3VyaXR5IGdvYWwgb2YgbWl0aWdhdGluZyBvbi1wYXRoIGluamVj dGlvbiBvZiBzcG9vZmVkIHBhY2tldHMuIEkgc3VnZ2VzdCByZXdvcmRpbmcgdGhpcyBwYXJhZ3Jh cGggd2l0aCB0ZXh0IHNvbWV0aGluZyBsaWtlIHRoaXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDtJbiBzb21lIGF1dG8t ZGlzY292ZXJ5IHNjZW5hcmlvcywgaXQgbWlnaHQgbm90IGJlIHBvc3NpYmxlIGZvciB0aGU8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAm bmJzcDtUVVJOIGNsaWVudCB0byB1c2UgKEQpVExTIGF1dGhlbnRpY2F0aW9uIHRvIHZhbGlkYXRl IHRoZSBUVVJOIHNlcnZlci48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDtIb3dldmVyLCBmYWxsLWJhY2sgdG8gY2xlYXIgdGV4 dCBpbiBzdWNoIGNhc2VzIGNvdWxkIGxlYXZlIHRoZSBUVVJOPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7Y2xpZW50IG9wZW4g dG8gb24tcGF0aCBpbmplY3Rpb24gb2Ygc3Bvb2ZlZCBUVVJOIG1lc3NhZ2VzLiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZu YnNwO0luc3RlYWQsIGEgVFVSTiBjbGllbnQgU0hPVUxEIGZhbGwtYmFjayB0byBlbmNyeXB0aW9u LW9ubHk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 ICZuYnNwOyhEKVRMUyB3aGVuIChEKVRMUyBhdXRoZW50aWNhdGlvbiBpcyBub3QgYXZhaWxhYmxl LiBBbm90aGVyIHJlYXNvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwO3RvIGZhbGwtYmFjayB0byBlbmNyeXB0aW9uLW9ubHkg aXMgZm9yIHByaXZhY3ksIHdoaWNoIGlzPC9zcGFuPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7YW5hbG9nb3VzIHRvIFNNVFAgb3Bwb3J0dW5pc3Rp YyBlbmNyeXB0aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7W1JGQzc0MzVdICZuYnNwO3doZXJlIG9uZSBkb2VzIG5vdCBy ZXF1aXJlIHByaXZhY3kgYnV0IG9uZSBkZXNpcmVzIHByaXZhY3k8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDt3aGVuIHBvc3Np YmxlLiAmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7ICZuYnNwO0l0IGlzIHN1Z2dlc3RlZCB0aGF0IGEgVFVSTiBjbGllbnQg YXR0ZW1wdCAoRClUTFMgd2l0aDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwO2F1dGhlbnRpY2F0aW9uIGFuZCBlbmNyeXB0aW9u LCBmYWxsaW5nIGJhY2sgdG8gZW5jcnlwdGlvbi1vbmx5IGlmIHRoZTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwO1RVUk4gc2Vy dmVyIGNhbm5vdCBiZSBhdXRoZW50aWNhdGVkIHZpYSAoRClUTFMuICZuYnNwO1RoZSBUVVJOIHNl cnZlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7ICZuYnNwO2NvdWxkIGZhbGwgYmFjayB0byBjbGVhciB0ZXh0IGlmIGl0ICZuYnNwO2Rv ZXMgbm90IHN1cHBvcnQgdW5hdXRoZW50aWNhdGVkIChEKVRMUywmbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDtidXQg ZmFsbGJhY2sgdG8gY2xlYXIgdGV4dCBpcyBOT1QgUkVDT01NRU5ERUQgYmVjYXVzZSBpdCBtYWtl czwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7ICZuYnNwO3RoZSBjbGllbnQgbW9yZSBzdXNjZXB0aWJsZSB0byBtYW4taW4tdGhlLW1pZGRs ZSBhdHRhY2tzIGFuZCBvbi1wYXRoPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7cGFja2V0IGluamVjdGlvbi48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBTZWN1cml0eSBD b25zaWRlcmF0aW9ucyBpbiBlYWNoIG9mIHRoZSBzdWItc2VjdGlvbnMgaXMgZ29vZCBhcyB3cml0 dGVuLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5CcmlhbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_e67a4ec09e8b487dbb745c09e7a52767XCHRCD017ciscocom_-- From nobody Wed Aug 17 06:04:27 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED1012D780; Wed, 17 Aug 2016 06:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.767 X-Spam-Level: X-Spam-Status: No, score=-15.767 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o91mxZHljaXV; Wed, 17 Aug 2016 06:04:24 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95A0612D6AD; Wed, 17 Aug 2016 06:04:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9202; q=dns/txt; s=iport; t=1471439064; x=1472648664; h=from:to:subject:date:message-id:mime-version; bh=iSwDUVji15zZXa3EeynACvfzzGhf4rgAmLjzSNT6V0E=; b=m0sX/pI8hnyBJZeu1LKJ7cE1HYWJ6EpFYJyUe7PcjlIVCu/vJoUXbb6m PLYoBjZRq1sBnrJss8NuqxAjpnOe/v/+QpgOwUnfmmbjxZQ0yjtTVV1va qrBlL/0b13RdWInmDJbZqh9pjrWHT5jbM81Fq1RGSYEDoqT0HXPXKR4FC s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BDAgBnX7RX/4YNJK1VCYJ1ToFZi0+oW?= =?us-ascii?q?oUHgX2GO4FLOBQCAQEBAQEBAV4nhGUjSCABSgIEMCcEAYhDrjOQLgEBAQEGAQE?= =?us-ascii?q?BASOGKoIAgk2EGYMogloFmUQBjx2PSZAyAR42g3qGY38BAQE?= X-IronPort-AV: E=Sophos;i="5.28,529,1464652800"; d="scan'208,217";a="311073992" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Aug 2016 13:04:23 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u7HD4NmT020687 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 17 Aug 2016 13:04:23 GMT Received: from xch-aln-004.cisco.com (173.36.7.14) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 17 Aug 2016 08:04:23 -0500 Received: from xch-aln-004.cisco.com ([173.36.7.14]) by XCH-ALN-004.cisco.com ([173.36.7.14]) with mapi id 15.00.1210.000; Wed, 17 Aug 2016 08:04:22 -0500 From: "Klaas Wierenga (kwiereng)" To: The IESG , "secdir@ietf.org" , "draft-ietf-6man-deprecate-atomfrag-generation.all@ietf.org" Thread-Topic: review of draft-ietf-6man-deprecate-atomfrag-generation-06 Thread-Index: AQHR+IffhO+j7nLtxUCRf8HX0u4//A== Date: Wed, 17 Aug 2016 13:04:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.229.191] Content-Type: multipart/alternative; boundary="_000_etPan57b460d61be7de0613067ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [secdir] review of draft-ietf-6man-deprecate-atomfrag-generation-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 13:04:26 -0000 --_000_etPan57b460d61be7de0613067ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCg0KSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2Vj dXJpdHkgZGlyZWN0b3JhdGUncw0Kb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRv Y3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlDQpJRVNHLiAgVGhlc2UgY29tbWVudHMgd2Vy ZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlDQpzZWN1cml0eSBhcmVh IGRpcmVjdG9ycy4gIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQN CnRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0K DQoNCk5vdGU6IEkgbm90aWNlZCB0aGF0IHRoZXJlIGlzIGFsc28gYSB2ZXJzaW9uIDA3LCBhbmQg aSBoYXZlIGxvb2tlZCBhdCB0aGF0LiBNeSBjb21tZW50cyBwZXJ0YWluIHRvIGJvdGggdmVyc2lv bnMuDQoNCklQdjYgYWxsb3dzIGZvciBzcGVjaWZ5aW5nIOKAmGF0b21pYyBmcmFnbWVudHPigJks IHdoZXJlIHRoZSBwYWNrZXQgaXMgbm90IHJlYWxseSBmcmFnbWVudGVkIGJ1dCB0aGUg4oCYZnJh Z21lbnRlZOKAmSBoZWFkZXIgaXMgdG8gaW5kaWNhdGUgdGhhdCBvbiB0aGUgcGF0aCB0aGVyZSBh cmUgbmV0d29yayBlbGVtZW50cyBpbiB0aGUgcGF0aCB0aGF0IGhhdmUgYW4gTVRVIHNpemUgYmVs b3cgdGhlIG1hbmRhdG9yeSBtaW5pbXVtIG9mIDEyODAgZm9yIElQdjYgKGZvciBleGFtcGxlIElQ djQvSVB2NiB0cmFuc2xhdG9ycykuIEFjY29yZGluZyB0byBkcmFmdC1pZXRmLTZtYW4tZGVwcmVj YXRlLWF0b21mcmFnLWdlbmVyYXRpb24tMDYgdGhpcyBpbnRyb2R1Y2VzIHNlY3VyaXR5IHJpc2tz LCBhbmQgaGFzIG5vIGJlbmVmaXRzLCBhbmQgdGhlcmVmb3JlIHByb3Bvc2VzIHRvIHJlbW92ZSBh dG9taWMgZnJhZ21lbnRzIGZyb20gSVB2Ni4NCg0KSSBhbSBub3QgYXQgYWxsIGFuIElQdjYgZXhw ZXJ0LCBzbyBteSBjb21tZW50cyBtYXkgbm90IGJlIHZhbGlkIGFuZCBmZWVsIGZyZWUgdG8gaWdu b3JlIHRoZW0uIEJ1dCBJIGNhbuKAmXQgaGVscCB0aGlua2luZyB0aGF0IG11Y2ggb2YgdGhlIG1v dGl2YXRpb24gZm9yIHJlbW92YWwgb2YgdGhpcyBmZWF0dXJlIGlzIGluIHRoZSBmYWN0IHRoYXQg aW1wbGVtZW50YXRpb25zIG1pc2JlaGF2ZS4gSSBmaW5kIHRoYXQgYSB3ZWFrIGFyZ3VtZW50LiBO b3QgYmVpbmcgYW4gZXhwZXJ0LCBJIGNhbiBub3QganVkZ2Ugd2VsbCB3aGV0aGVyIHJlbW92aW5n IHRoZSBmZWF0dXJlIGlzIGhhcm1sZXNzLCBidXQgSSB3b3VsZCBiZSB2ZXJ5IGNhdXRpb3VzIHdp dGggcmVtb3ZpbmcgZXh0ZW5zaW9uIGhlYWRlcnMgZm9yIHRoYXQgcmVhc29uLg0KDQpGcmFnbWVu dGF0aW9uIGluIGl0c2VsZiBpcyBhbiBhdHRhY2sgdmVjdG9yLCBidXQgSSBkb27igJl0IHVuZGVy c3RhbmQgd2h5IHRoYXQgaXMgbW9yZSBvZiBhIHByb2JsZW0gd2l0aCBhdG9taWMgZnJhZ21lbnRz LCBhcGFydCBmcm9tIHRoZSBhZm9yZW1lbnRpb25lZCBpbXBsZW1lbnRhdGlvbiBlcnJvcnMuDQoN CkFwYXJ0IGZyb20gdGhhdCwgSSBzZWUgbm8gZ2xhcmluZyBzZWN1cml0eSBpc3N1ZXMsIHNvIGlm IHRoZXJlIGlzIGJyb2FkIGNvbnNlbnN1cyBpbiB0aGUgV0cgdGhhdCB0aGlzIGlzIHRoZSByaWdo dCB0aGluZyB0byBkbywgSSBjb25zaWRlciB0aGUgZG9jdW1lbnQgcmVhZHkuDQoNCktsYWFzDQoN Cg0KDQotLQ0KS2xhYXMgV2llcmVuZ2ENCklkZW50aXR5IEFyY2hpdGVjdA0KQ2lzY28gQ2xvdWQg U2VydmljZXMNCg== --_000_etPan57b460d61be7de0613067ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <271FC1777E57524FA2A96D5764BEE04C@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5ib2R5e2ZvbnQtZmFtaWx5OkhlbHZl dGljYSxBcmlhbDtmb250LXNpemU6MTNweH08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgc3R5bGU9 IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0 LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyI+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21m b250IiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhLEFyaWFsO2ZvbnQtc2l6ZToxM3B4OyBj b2xvcjogcmdiYSgwLDAsMCwxLjApOyBtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IGF1dG87Ij4N CkhpLDwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCIgc3R5bGU9ImZvbnQtZmFtaWx5 OkhlbHZldGljYSxBcmlhbDtmb250LXNpemU6MTNweDsgY29sb3I6IHJnYmEoMCwwLDAsMS4wKTsg bWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBhdXRvOyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgaWQ9 ImJsb29wX2N1c3RvbWZvbnQiIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EsQXJpYWw7Zm9u dC1zaXplOjEzcHg7IGNvbG9yOiByZ2JhKDAsMCwwLDEuMCk7IG1hcmdpbjogMHB4OyBsaW5lLWhl aWdodDogYXV0bzsiPg0KPHByZSBjbGFzcz0id2lraSI+SSBoYXZlIHJldmlld2VkIHRoaXMgZG9j dW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyAgDQpvbmdvaW5nIGVm Zm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUg IA0KSUVTRy4gIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBi ZW5lZml0IG9mIHRoZSAgDQpzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4gIERvY3VtZW50IGVkaXRv cnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgIA0KdGhlc2UgY29tbWVudHMganVzdCBsaWtl IGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuPC9wcmU+DQo8cHJlIGNsYXNzPSJ3aWtpIj48 YnI+PC9wcmU+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiIHN0eWxlPSJmb250 LWZhbWlseTpIZWx2ZXRpY2EsQXJpYWw7Zm9udC1zaXplOjEzcHg7IGNvbG9yOiByZ2JhKDAsMCww LDEuMCk7IG1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogYXV0bzsiPg0KTm90ZTogSSBub3RpY2Vk IHRoYXQgdGhlcmUgaXMgYWxzbyBhIHZlcnNpb24gMDcsIGFuZCBpIGhhdmUgbG9va2VkIGF0IHRo YXQuIE15IGNvbW1lbnRzIHBlcnRhaW4gdG8gYm90aCB2ZXJzaW9ucy48L2Rpdj4NCjxkaXYgaWQ9 ImJsb29wX2N1c3RvbWZvbnQiIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EsQXJpYWw7Zm9u dC1zaXplOjEzcHg7IGNvbG9yOiByZ2JhKDAsMCwwLDEuMCk7IG1hcmdpbjogMHB4OyBsaW5lLWhl aWdodDogYXV0bzsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250IiBz dHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhLEFyaWFsO2ZvbnQtc2l6ZToxM3B4OyBjb2xvcjog cmdiYSgwLDAsMCwxLjApOyBtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IGF1dG87Ij4NCklQdjYg YWxsb3dzIGZvciBzcGVjaWZ5aW5nIOKAmGF0b21pYyBmcmFnbWVudHPigJksIHdoZXJlIHRoZSBw YWNrZXQgaXMgbm90IHJlYWxseSBmcmFnbWVudGVkIGJ1dCB0aGUg4oCYZnJhZ21lbnRlZOKAmSBo ZWFkZXIgaXMgdG8gaW5kaWNhdGUgdGhhdCBvbiB0aGUgcGF0aCB0aGVyZSBhcmUgbmV0d29yayBl bGVtZW50cyBpbiB0aGUgcGF0aCB0aGF0IGhhdmUgYW4gTVRVIHNpemUgYmVsb3cgdGhlIG1hbmRh dG9yeSBtaW5pbXVtIG9mIDEyODAgZm9yIElQdjYgKGZvcg0KIGV4YW1wbGUgSVB2NC9JUHY2IHRy YW5zbGF0b3JzKS4gQWNjb3JkaW5nIHRvIGRyYWZ0LWlldGYtNm1hbi1kZXByZWNhdGUtYXRvbWZy YWctZ2VuZXJhdGlvbi0wNiB0aGlzIGludHJvZHVjZXMgc2VjdXJpdHkgcmlza3MsIGFuZCBoYXMg bm8gYmVuZWZpdHMsIGFuZCB0aGVyZWZvcmUgcHJvcG9zZXMgdG8gcmVtb3ZlIGF0b21pYyBmcmFn bWVudHMgZnJvbSBJUHY2LjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCIgc3R5bGU9 ImZvbnQtZmFtaWx5OkhlbHZldGljYSxBcmlhbDtmb250LXNpemU6MTNweDsgY29sb3I6IHJnYmEo MCwwLDAsMS4wKTsgbWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBhdXRvOyI+DQo8YnI+DQo8L2Rp dj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRp Y2EsQXJpYWw7Zm9udC1zaXplOjEzcHg7IGNvbG9yOiByZ2JhKDAsMCwwLDEuMCk7IG1hcmdpbjog MHB4OyBsaW5lLWhlaWdodDogYXV0bzsiPg0KSSBhbSBub3QgYXQgYWxsIGFuIElQdjYgZXhwZXJ0 LCBzbyBteSBjb21tZW50cyBtYXkgbm90IGJlIHZhbGlkIGFuZCBmZWVsIGZyZWUgdG8gaWdub3Jl IHRoZW0uIEJ1dCBJIGNhbuKAmXQgaGVscCB0aGlua2luZyB0aGF0IG11Y2ggb2YgdGhlIG1vdGl2 YXRpb24gZm9yIHJlbW92YWwgb2YgdGhpcyBmZWF0dXJlIGlzIGluIHRoZSBmYWN0IHRoYXQgaW1w bGVtZW50YXRpb25zIG1pc2JlaGF2ZS4gSSBmaW5kIHRoYXQgYSB3ZWFrIGFyZ3VtZW50LiBOb3Qg YmVpbmcNCiBhbiBleHBlcnQsIEkgY2FuIG5vdCBqdWRnZSB3ZWxsIHdoZXRoZXIgcmVtb3Zpbmcg dGhlIGZlYXR1cmUgaXMgaGFybWxlc3MsIGJ1dCBJIHdvdWxkIGJlIHZlcnkgY2F1dGlvdXMgd2l0 aCByZW1vdmluZyBleHRlbnNpb24gaGVhZGVycyBmb3IgdGhhdCByZWFzb24uJm5ic3A7PC9kaXY+ DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250IiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNh LEFyaWFsO2ZvbnQtc2l6ZToxM3B4OyBjb2xvcjogcmdiYSgwLDAsMCwxLjApOyBtYXJnaW46IDBw eDsgbGluZS1oZWlnaHQ6IGF1dG87Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3Vz dG9tZm9udCIgc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSxBcmlhbDtmb250LXNpemU6MTNw eDsgY29sb3I6IHJnYmEoMCwwLDAsMS4wKTsgbWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBhdXRv OyI+DQpGcmFnbWVudGF0aW9uIGluIGl0c2VsZiBpcyBhbiBhdHRhY2sgdmVjdG9yLCBidXQgSSBk b27igJl0IHVuZGVyc3RhbmQgd2h5IHRoYXQgaXMgbW9yZSBvZiBhIHByb2JsZW0gd2l0aCBhdG9t aWMgZnJhZ21lbnRzLCBhcGFydCBmcm9tIHRoZSBhZm9yZW1lbnRpb25lZCBpbXBsZW1lbnRhdGlv biBlcnJvcnMuPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250IiBzdHlsZT0iZm9udC1m YW1pbHk6SGVsdmV0aWNhLEFyaWFsO2ZvbnQtc2l6ZToxM3B4OyBjb2xvcjogcmdiYSgwLDAsMCwx LjApOyBtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IGF1dG87Ij4NCjxicj4NCjwvZGl2Pg0KPGRp diBpZD0iYmxvb3BfY3VzdG9tZm9udCIgc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSxBcmlh bDtmb250LXNpemU6MTNweDsgY29sb3I6IHJnYmEoMCwwLDAsMS4wKTsgbWFyZ2luOiAwcHg7IGxp bmUtaGVpZ2h0OiBhdXRvOyI+DQpBcGFydCBmcm9tIHRoYXQsIEkgc2VlIG5vIGdsYXJpbmcgc2Vj dXJpdHkgaXNzdWVzLCBzbyBpZiB0aGVyZSBpcyBicm9hZCBjb25zZW5zdXMgaW4gdGhlIFdHIHRo YXQgdGhpcyBpcyB0aGUgcmlnaHQgdGhpbmcgdG8gZG8sIEkgY29uc2lkZXIgdGhlIGRvY3VtZW50 IHJlYWR5LjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCIgc3R5bGU9ImZvbnQtZmFt aWx5OkhlbHZldGljYSxBcmlhbDtmb250LXNpemU6MTNweDsgY29sb3I6IHJnYmEoMCwwLDAsMS4w KTsgbWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBhdXRvOyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYg aWQ9ImJsb29wX2N1c3RvbWZvbnQiIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EsQXJpYWw7 Zm9udC1zaXplOjEzcHg7IGNvbG9yOiByZ2JhKDAsMCwwLDEuMCk7IG1hcmdpbjogMHB4OyBsaW5l LWhlaWdodDogYXV0bzsiPg0KS2xhYXM8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQi IHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EsQXJpYWw7Zm9udC1zaXplOjEzcHg7IGNvbG9y OiByZ2JhKDAsMCwwLDEuMCk7IG1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogYXV0bzsiPg0KPGJy Pg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250IiBzdHlsZT0iZm9udC1mYW1pbHk6 SGVsdmV0aWNhLEFyaWFsO2ZvbnQtc2l6ZToxM3B4OyBjb2xvcjogcmdiYSgwLDAsMCwxLjApOyBt YXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IGF1dG87Ij4NCiZuYnNwOyZuYnNwOzwvZGl2Pg0KPGJy Pg0KPGRpdiBpZD0iYmxvb3Bfc2lnbl8xNDcxNDM3OTQxOTAyMDQxODU2IiBjbGFzcz0iYmxvb3Bf c2lnbiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpoZWx2ZXRpY2EsYXJpYWw7Zm9udC1zaXpl OjEzcHgiPi0tJm5ic3A7PGJyPg0KS2xhYXMgV2llcmVuZ2E8YnI+DQpJZGVudGl0eSBBcmNoaXRl Y3Q8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OmhlbHZldGljYSxhcmlhbDtmb250LXNp emU6MTNweCI+Q2lzY28gQ2xvdWQgU2VydmljZXM8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_etPan57b460d61be7de0613067ciscocom_-- From nobody Wed Aug 17 19:13:38 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C91A412D5EC; Wed, 17 Aug 2016 19:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ve-TX5NxkgzV; Wed, 17 Aug 2016 19:13:09 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1FEF12D5BC; Wed, 17 Aug 2016 19:13:08 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.169.225; From: "Susan Hares" To: "'Radia Perlman'" , , "'The IESG'" , References: In-Reply-To: Date: Wed, 17 Aug 2016 22:11:52 -0400 Message-ID: <015701d1f8f5$eae5a6d0$c0b0f470$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0158_01D1F8D4.63D58D70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHCtNdp+3zCUnemYE+gWRpQ0UPOFqBqmqQQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-i2rs-protocol-security-requirements-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 02:13:11 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0158_01D1F8D4.63D58D70 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Radia: =20 Thank you for these excellent editorial comments. A version -08 = addresses your comments.=20 =20 From: Radia Perlman [mailto:radiaperlman@gmail.com]=20 Sent: Saturday, August 13, 2016 8:08 PM To: secdir@ietf.org; The IESG; = draft-ietf-i2rs-protocol-security-requirements.all@tools.ietf.org Subject: Secdir review of = draft-ietf-i2rs-protocol-security-requirements-06 =20 I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these comments just like any = other last call comments. =20 The document is about the security requirements between a management = station (what I assume a "I2RS client" is) and the agent on a "routing = system". These include mutual authentication, transport security, = atomicity. =20 The document is well-written and ready, with nits. >I haven't been following this WG, so apologies for perhaps not getting = the terminology, though it might be better if every document were self = contained, in >defining terms, or pointing to a different document where = all the terms are defined. 1) The meaning of the term in the spec "routing system" is not = obvious to me. I'm assuming it means not only routers but anything that = looks at layer 3 such as load splitters and hypervisors, is that = correct? Maybe the term is defined in a different document? If not, a = clarifying sentence would be appreciated by readers.\ Sue=E2=80=99s Response: Added the following definition:=20 /I2RS routing system: Layer three (L3) routing systems which include = physical routers, virtual routers (in hypervisors or load splitters), = and other devices handling L3 routing./ 2) In section "I2RS multi-message atomicity" "this is not supported in order to simply the first version of I2RS"=20 should be "simplify" =20 Added in version 7=20 =20 =20 3) "If insecure transport is used, then confidentiality and integrity = cannot be achieved" That statement, as a sweeping statement, isn't true, since, for = instance, Ethernet does not provide any confidentiality and integrity, = but protocols can achieve confidentiality and integrity by doing it = themselves. So perhaps the statement should be softened to say = something like "I2RS does not itself provide confidentiality and = integrity, so it depends on running over a secure Transport that = provides these features". =20 Sue=E2=80=99s Comment: Agreed. Here=E2=80=99s my new text.=20 =20 New text/ Since, I2RS does not itself provide confidentiality and integrity,=20 so it depends on running over a secure Transport that provides these = features.=20 =20 I2RS allows the use of an insecure transport for portions of data models = that clearly indicate insecure transport. Operators deploying I2RS must determine if they want = to populate and=20 deploy the portions of the data model which use insecure transports. / =20 =20 4) "All I2RS clients and I2RS agents MUST have an identity, and at = least one unique identifier that uniquely identifies each party in the = I2RS protocol context." =20 This might be overly restrictive. You might want several I2RS clients = acting as instances of a single identity, in which case, they might all = share the same identity. =20 =20 Sue=E2=80=99s Response: We consider that a single identity =3D a = single client. If the client has multiple instances and multiple = transports, it is still consider the same identity.=20 =20 =20 " SEC-REQ-06: The I2RS protocol SHOULD assume some mechanism (IETF or private) will distribute or load identifiers so that the I2RS client/agent has these identifiers prior to the I2RS protocol establishing a connection between I2RS client and I2RS agent." =20 Instead of "distribute or load", perhaps "configure" would be clearer? = At any rate, I don't know the difference between "distribute" and = "load". =20 Response: =20 Configure is not the right word. One example for loading the identities = is AAA.=20 =20 How about the following: =20 New:=20 /The I2RS protocol SHOULD assume some mechanism(s) (IETF or private) = will distribute the identifiers and load these into the I2RS client and = agent =20 so that the I2RS client/agent has these identifiers prior to the I2RS protocol establishing a connection=20 between I2RS client and I2RS agent. (One mechanism such mechanism is = AAA protocols.) / =20 Radia =20 =20 Thank you for your review.=20 =20 Sue=20 ------=_NextPart_000_0158_01D1F8D4.63D58D70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Radia:

 

Thank you for these excellent editorial comments.   A = version -08 addresses your comments.

 

From:= = Radia Perlman [mailto:radiaperlman@gmail.com]=
Sent: Saturday, August 13, 2016 8:08 PM
To: secdir@ietf.org; The IESG; draft-ietf-i2rs-protocol-security-requirements.all@tools.ietf.or= g
Subject: Secdir review of = draft-ietf-i2rs-protocol-security-requirements-06

 

I have reviewed this document as part of the = security directorate's ongoing effort to review all IETF documents being = processed by the IESG.

These comments were written primarily for the = benefit of the security area directors.

Document editors and WG chairs should treat = these comments just like any other last call comments.

 

The document is about the security = requirements between a management station (what I assume a = "I2RS client" is) and the = agent on a "routing system". These include mutual = authentication, transport security, atomicity.

 

The document is well-written and ready, with = nits.

>I haven't been following this WG, so = apologies for perhaps not getting the terminology, though it might be = better if every document were self contained, in >defining terms, or = pointing to a different document where all the terms are = defined.

1)      = The = meaning of the  term in the spec  "routing system" is not obvious to me. I'm = assuming it means not only routers but anything that looks at layer 3 = such as load splitters and hypervisors, is that correct? Maybe the term = is defined in a different document? If not, a clarifying sentence would = be appreciated by readers.\

S= ue=E2=80=99s Response: Added the following definition: =

/= I2RS routing system:  Layer three (L3) routing systems which = include physical routers,  virtual routers (in hypervisors or load = splitters), and other devices handling L3 = routing./

2)  In section "I2RS =
multi-message atomicity"
"this is not =
supported in order to simply the first version of I2RS" =

should be =
"simplify"
 
   Added in version 7 
 
 
3)  "If insecure =
transport is used, then confidentiality and integrity cannot be =
achieved"
That statement, as a sweeping statement, isn't =
true, since, for instance, Ethernet does not provide any confidentiality =
and integrity, but protocols can achieve confidentiality and integrity =
by doing it themselves.  So perhaps the statement should be =
softened to say something like "I2RS does not itself provide =
confidentiality and integrity, so it depends on running over a secure =
Transport that provides these =
features".
 
Sue=E2=80=99s Comment: Agreed.  =
Here=E2=80=99s my new text. 
 
New text/
Since, I2RS does not itself provide confidentiality =
and integrity, 
so =
it depends on running over a secure Transport that provides these =
features. 
 
I2RS allows the use of an insecure transport for =
portions of data models that clearly =
indicate
insecure =
transport. Operators deploying I2RS must determine if they want to =
populate and 
deploy the portions of the data model which use =
insecure transports.
/
 
 
4)  "All I2RS clients =
and I2RS agents MUST have an identity, and at least one unique =
identifier that uniquely identifies each party in the I2RS protocol =
context."
 
This might be =
overly restrictive.  You might want several I2RS clients acting as =
instances of a single identity, in which case, they might all share the =
same identity.  
 <=
/span>
 Sue=E2=80=99s =
Response:  We consider that a single identity =3D a single =
client.    If the client has multiple instances and =
multiple transports, it is still consider the same identity. =

 
 
" SEC-REQ-06: The I2RS protocol SHOULD assume =
some mechanism (IETF
      or private) will =
distribute or load identifiers so that the =
I2RS
      client/agent has =
these identifiers prior to the I2RS =
protocol
      establishing a =
connection between I2RS client and I2RS =
agent."
 
Instead of "distribute or load", perhaps =
"configure" would be clearer?  At any rate, I don't know =
the difference between "distribute" and =
"load".
 
Response:  
Configure is not the right word.  One example =
for loading the identities is AAA. 
 
How about the =
following:
 
New: 
/The I2RS protocol SHOULD assume some mechanism(s) =
(IETF or private) will
 distribute the identifiers and load these into the =
I2RS client and agent  
 so that the I2RS client/agent has =
these
 identifiers =
prior to the I2RS protocol establishing a connection =

 between =
I2RS client and I2RS agent. (One mechanism such mechanism is AAA =
protocols.)
/
 
Radia

 

 

Thank you = for your review.

 

Sue =

------=_NextPart_000_0158_01D1F8D4.63D58D70-- From nobody Fri Aug 19 02:25:24 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E20E512D88B for ; Fri, 19 Aug 2016 02:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHhqACHoM7Fh for ; Fri, 19 Aug 2016 02:25:20 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D4AF12D0AE for ; Fri, 19 Aug 2016 02:25:20 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u7J9PFVO008390 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 19 Aug 2016 12:25:15 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u7J9PFfw023537; Fri, 19 Aug 2016 12:25:15 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22454.53371.285785.487701@fireball.acr.fi> Date: Fri, 19 Aug 2016 12:25:15 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 09:25:23 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Phillip Hallam-Baker is next in the rotation. For telechat 2016-09-01 Reviewer LC end Draft Shawn Emery T 2016-08-26 draft-ietf-mpls-entropy-lsp-ping-03 Eric Osterweil T 2016-08-26 draft-ietf-httpauth-extension-08 Tom Yu T 2016-08-24 draft-ietf-6man-ipv6-mibs-obsolete-01 Last calls and special requests: Derek Atkins 2016-08-25 draft-ietf-hip-multihoming-09 Shaun Cooley 2016-08-25 draft-ietf-hip-rfc5206-bis-12 Alan DeKok 2016-04-30 draft-bradner-rfc3979bis-08 Donald Eastlake 2016-09-08 draft-ietf-mif-happy-eyeballs-extension-09 Daniel Kahn Gillmor E 2016-02-01 draft-ietf-rtcweb-security-08 Olafur Gudmundsson 2016-08-25 draft-ietf-softwire-unified-cpe-04 Warren Kumari 2016-09-06 draft-sweet-rfc2911bis-09 Matthew Miller 2016-08-06 draft-ietf-avtcore-rfc5764-mux-fixes-10 Sandy Murphy 2016-08-12 draft-ietf-tsvwg-gre-in-udp-encap-13 Rich Salz 2016-08-15 draft-ietf-isis-remaining-lifetime-04 Hannes Tschofenig E None draft-ietf-ntp-network-time-security-14 Hannes Tschofenig E None draft-ietf-ntp-cms-for-nts-message-06 Hannes Tschofenig E None draft-ietf-ntp-using-nts-for-ntp-05 Tina TSOU 2016-08-15 draft-ietf-ospf-two-part-metric-05 Brian Weis E 2016-02-01 draft-ietf-cdni-uri-signing-09 Paul Wouters 2016-09-02 draft-moriarty-pkcs1-01 Liang Xia 2016-09-02 draft-moriarty-pkcs5-v2dot1-01 Dacheng Zhang 2016-08-22 draft-ietf-core-http-mapping-12 -- kivinen@iki.fi From nobody Fri Aug 19 10:02:56 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E697C12D0B7; Fri, 19 Aug 2016 10:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.768 X-Spam-Level: X-Spam-Status: No, score=-15.768 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POJuzD2Chas2; Fri, 19 Aug 2016 10:02:53 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B510012D5A9; Fri, 19 Aug 2016 10:02:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2581; q=dns/txt; s=iport; t=1471626169; x=1472835769; h=to:from:subject:message-id:date:mime-version; bh=fXmjz9vF5jFURBPdP6MR1ViLeckP8aAbKnV4dKptl14=; b=frUQQIyYA27lguZ36k7SvzFTeTCJ19ZdiBboYUe4tugv8KuiL6MFtf79 22PUFHrQN3m1qOcJVXC7qSkBBcMWem8wdVgdxdWSB0JDoi6fczSK4522/ CPQSCFPc/B4vglC5IvLVcqIwKyCLlXpy9OEcy0ojAhogg0K1XmM9i0RvR U=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHCwCjOrdX/5BdJa1eg0SBAKMlAQEBA?= =?us-ascii?q?QEBBQGBEJQBgX2GHYFjOhICAQEBAQEBAV4nhQiBBRkVAmAMCAEBiC2qMpAAAQs?= =?us-ascii?q?XDoVjgkCHNR+CQoJaBY8UijECgz6Bc4ltgWuHa4V2hmiFVYN4JQIthBkdh2EBA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos;i="5.28,545,1464652800"; d="asc'?scan'208";a="137763249" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Aug 2016 17:02:48 +0000 Received: from [10.24.28.124] ([10.24.28.124]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u7JH2mkV028221; Fri, 19 Aug 2016 17:02:48 GMT To: secdir@ietf.org, draft-ietf-avtcore-rfc5764-mux-fixes.all@ietf.org From: Matt Miller Message-ID: Date: Fri, 19 Aug 2016 11:02:47 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="R8aHV86Swipb4o4R54l9GIlAR7j8bu4f5" Archived-At: Subject: [secdir] SecDir Review of draft-ietf-avtcore-rfc5764-mux-fixes-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 17:02:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --R8aHV86Swipb4o4R54l9GIlAR7j8bu4f5 Content-Type: multipart/mixed; boundary="vtl4T9iE5nK489fvON7moNJx23MaNt6o9" From: Matt Miller To: secdir@ietf.org, draft-ietf-avtcore-rfc5764-mux-fixes.all@ietf.org Message-ID: Subject: SecDir Review of draft-ietf-avtcore-rfc5764-mux-fixes-10 --vtl4T9iE5nK489fvON7moNJx23MaNt6o9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments that arrived on tim= e. Document: draft-ietf-avtcore-rfc5764-mux-fixes-10 Reviewer: Matthew A. Miller Review Date: 2016-08-19 IETF LC End Date: 2016-08-06 IESG Telechat date: N/A Summary: This document is ready for publication as a Standards Track document. This document updates RFC 5764 to update the receiver's demultiplexing to account for all the known packet types, and explicitly updates the IANA registries that were previously implicitly impacted, including changes in allocations of the registries to require coordination. Major issues: NONE Minor issues: NONE Nits/editorial comments: * This document uses "RFC XXXX" or "RFCXXXX" to, I assume, reference this document. It may be worth calling this out explicitly for the RFC Editor, although I don't think this requires an update to this document. --=20 - m&m Matt Miller Cisco Systems, Inc. --vtl4T9iE5nK489fvON7moNJx23MaNt6o9-- --R8aHV86Swipb4o4R54l9GIlAR7j8bu4f5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXtzu4AAoJEDWi+S0W7cO1TC4IALchH+eUIpTDx2p+n5+jIsYo X/xK3objhVvXnCQkdA7aZeLhqdKt2S6h74CP9cK9KsayvKmED4KykOkbt9BHbrFi bQWWBYlbcotor/eysgJAX/hg1zO0Fmfet6bcfYVxik+kbW1ejFBb1idI6A+4sPp9 f43u1MsaUVszjLXhGkHWKNTD6nVLUWy1PpCazyInYPO+bafcX3csBf08Z0ByVdIO opnfZYQ0UaAQAPP11jZD/+XHxRwPO0JztThlglMSh/3QrQVyf6LZDuQRYXIE1W3L cm2JEvZA6m0BIeGM1OIFJbq+x4+I0kVvCrpwMYa7bELzzgaPoq5V5QHC6AUF3e8= =SmFh -----END PGP SIGNATURE----- --R8aHV86Swipb4o4R54l9GIlAR7j8bu4f5-- From nobody Fri Aug 19 20:51:13 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69A112D599; Fri, 19 Aug 2016 20:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.768 X-Spam-Level: X-Spam-Status: No, score=-15.768 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-PAGKeCWRnk; Fri, 19 Aug 2016 20:51:09 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FD9F12D5A4; Fri, 19 Aug 2016 20:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1529; q=dns/txt; s=iport; t=1471665069; x=1472874669; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=a/Lx4plgEYxP6C/Xh4LyfVWCyxPzR1+68GFDBQMWdbU=; b=ffFmKBlJ2n/Cx4qR4vS3pVina7TM2U+hj4FgDYR819mxDKpSa/6VFC52 GNW0knxTSOJh2UPuQPSdQl6tfo4piyR4v946n+ii9C7/n25olk1ijvYq8 7l+zkVNm5s/KRdlJexXLIPtJILVluXXx2AGJxDSKFUPqZ188Y9e0wWl9Y Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B2AgAF07dX/5JdJa1eg0SBQw8Ht2yBf?= =?us-ascii?q?YYdAoFmOBQCAQEBAQEBAV4nhF4BAQQBOj8FCwIBCBQEFQkQMiUCBA4FiCkIuw4?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQEchiuBeAiCTYRAP4Jtgi8BBJlIAY8egW2NY?= =?us-ascii?q?4ZphVaDdwEeNoN6cIYvfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,548,1464652800"; d="scan'208";a="139735992" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Aug 2016 03:51:08 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u7K3p8hv014071 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 20 Aug 2016 03:51:08 GMT Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 19 Aug 2016 22:51:07 -0500 Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1210.000; Fri, 19 Aug 2016 22:51:07 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: "Matt Miller (mamille2)" Thread-Topic: SecDir Review of draft-ietf-avtcore-rfc5764-mux-fixes-10 Thread-Index: AQHR+juMiP/AUxSdb0qspiGe1MjA96BRi4IA Date: Sat, 20 Aug 2016 03:51:07 +0000 Message-ID: <23C0BC86-C76B-4E33-8255-B6D9CDEFF444@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.176.229] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-avtcore-rfc5764-mux-fixes.all@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SecDir Review of draft-ietf-avtcore-rfc5764-mux-fixes-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2016 03:51:11 -0000 Thanks for the review, Matt. You comment is duly notes. Cheers, Gonzalo > On Aug 19, 2016, at 1:02 PM, Matt Miller (mamille2) = wrote: >=20 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments that arrived on tim= e. >=20 > Document: draft-ietf-avtcore-rfc5764-mux-fixes-10 > Reviewer: Matthew A. Miller > Review Date: 2016-08-19 > IETF LC End Date: 2016-08-06 > IESG Telechat date: N/A >=20 > Summary: >=20 > This document is ready for publication as a Standards Track document. >=20 > This document updates RFC 5764 to update the receiver's demultiplexing > to account for all the known packet types, and explicitly updates the > IANA registries that were previously implicitly impacted, including > changes in allocations of the registries to require coordination. >=20 > Major issues: >=20 > NONE >=20 > Minor issues: >=20 > NONE >=20 > Nits/editorial comments: >=20 > * This document uses "RFC XXXX" or "RFCXXXX" to, I assume, reference > this document. It may be worth calling this out explicitly for the > RFC Editor, although I don't think this requires an update to this > document. >=20 >=20 > --=20 > - m&m >=20 > Matt Miller > Cisco Systems, Inc. >=20 From nobody Wed Aug 24 02:17:02 2016 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D8212B006; Wed, 24 Aug 2016 01:50:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1472028632; bh=2gWRv5Z2gRdAgxgrpahb80TAVdhipAFBh9qaz3yZoUQ=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=MJFmAOB/gtSUDAQGPsYUvBu01geKRSy1L/oURO/mzmS2Wo2rqVufXih5Z4dLVLHns p5kjKQnGypK5sPZZnzGkJ5wSJl3IPbGMOeE3Sya3HcgIH3JHmpHlYR9PG+4SqjG57A 2hSgWQ7YTwWGBwiE2pUONPgscqK0RIeVLgoY31R0= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11D312B006 for ; Wed, 24 Aug 2016 01:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.448 X-Spam-Level: X-Spam-Status: No, score=-1.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFZ4KhMbL9JH for ; Wed, 24 Aug 2016 01:50:29 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 991391288B8 for ; Wed, 24 Aug 2016 01:50:29 -0700 (PDT) Received: from [60.207.237.15] (helo=[192.168.0.246]) by raoul.w3.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1bcTtD-0009a0-Oh for new-work@ietf.org; Wed, 24 Aug 2016 08:50:28 +0000 To: new-work@ietf.org From: Xueyuan Jia Message-ID: Date: Wed, 24 Aug 2016 16:50:43 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Wed, 24 Aug 2016 02:17:01 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Technology and Policy Interest Group (TechPolig) (until 2016-09-21) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 08:50:33 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to review a draft charter for the Technology and Policy Interest Group (TechPolig): https://www.w3.org/2016/04/techpolig-charter.htm As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2016-09-21 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [1], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Daniel Dardailler, Foreseen TechPolig Staff contact . Thank you, Xueyuan Jia, W3C Marketing & Communications [1] http://www.w3.org/Consortium/Member/List _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Wed Aug 24 07:03:46 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E5612D94A; Wed, 24 Aug 2016 07:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=r4QAEHPg; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=LVQAJL8V Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXqbrct95Cs2; Wed, 24 Aug 2016 07:03:40 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72D6512D140; Wed, 24 Aug 2016 07:03:39 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 44BB0203F4; Wed, 24 Aug 2016 10:03:38 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 24 Aug 2016 10:03:38 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=Dv3uEpCGr6spGnT4KQX1tHin8Ec=; b=r4QAEH PgoktrxetSYI3sMEN2Ot+cHTRh2D6duaNeUu/81vreYj7czwft0OeP9WE/nMBYRr ele4YDk12KQfQVRStpkkK+tzcMG9gGPZs+o+ewKuRTHqluLkS9puXZiM3vSH/2il gXvZAsa/OzgTarUcWcirvFDfxUbTTF/I7FiJE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=Dv3uEpCGr6spGnT 4KQX1tHin8Ec=; b=LVQAJL8VXjMXpkg300sy075gG4HwJkkNiP1gv6oA5tUcRIL Y4Xo8YQarEV5vpXeuh/8hkpECqpwbesVisibEARlX6wN9K4CHGQ0EqoiMTLZLrzZ 91Vfofo2rDDwZ//MxwXq+tNud9t5cd0HbeCjBuKImHy/uPgOOrs8krOgIEzo= X-Sasl-enc: uJkOtaHmVB2yg/0ZGLPvjvHj7VtcL2iOYWwoWmjqYNWc 1472047417 Received: from sjc-alcoop-8816.cisco.com (unknown [128.107.241.174]) by mail.messagingengine.com (Postfix) with ESMTPA id 05C4CF29D0; Wed, 24 Aug 2016 10:03:36 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <71ec7240-8b2d-2f47-034e-f10faba8ea27@haw-hamburg.de> Date: Wed, 24 Aug 2016 10:03:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <06B65EC5-1582-4F4A-9325-47453B1ABF6C@cooperw.in> References: <46d6459124394dddbff5e9d7f48bf23b@HUB02.mailcluster.haw-hamburg.de> <71ec7240-8b2d-2f47-034e-f10faba8ea27@haw-hamburg.de> To: Russ Housley X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "Thomas C. Schmidt" , "draft-ietf-p2psip-share.all@ietf.org" , IETF SecDir Subject: Re: [secdir] Early SecDir Review of draft-ietf-p2psip-share-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 14:03:44 -0000 Russ, Any thoughts on the question Thomas poses below? Thanks, Alissa > On Aug 15, 2016, at 3:20 PM, Thomas C. Schmidt = wrote: >=20 > Russ, >=20 > I'm only now coming back to this long delayed issue - sorry for that. >=20 > Let me summarize the story about indexing (Section 3.1 in ShaRe): >=20 > 1. The application use case for shared resources is that of a small = group of peers sharing a data structure, which can be an array. Array = indexing according to Sec. 3.1 uses parts of the Node-ID (the 24 least = significant bits of a SHA-1 hash) to generate isolation among peers, and = at the same time generate an unambiguous, unique binding between a node = and the array elements it is allowed to write. >=20 > 2. The threat of collisions is that this binding becomes ambiguous and = - if not prevented - would cause an option for theft of = resource/service. There is no threat of privilege escalation, here, as = entries are signed. >=20 > 3. SHA-1 is collision-resistant and the probability of collisions is = expected to be low [1], but the output is not perfectly random. So I = agree that the ref to the RFC 3550 calculation is a bit too optimistic. = However, neither me nor a crypto colleague could find a rigorous = calculation of the SHA-1 collision probability ... >=20 > 4. The straight-forward counter measure against theft of resources in = the case of a collision is a refusal of overwriting by the storing peer = (see end of Section 6.1). This may exclude a node with colliding ID bits = from participation in sharing a resource. >=20 > Now I see two choices: >=20 > (1) We leave it that way, i.e., clarify the text in Section 3.1 and = point out that a node under collision could re-join the overlay with a = different node-ID. >=20 > (2) We could advise a procedure to generate non-colliding ID bits by = rehashing the node-ID. I.e., a node that experiences a collision could = rehash its ID to obtain new ID bits and the storing peer could validate = by also iterating the hashing. >=20 > (2) would complicate the whole process for considerably rare cases, = why I'm in favor of (1). >=20 > What would you suggest? >=20 > Thanks, > Thomas >=20 > [1] K. Chung, M. Mitzenmacher, and S. Vadhan: Why Simple Hash = Functions Work: Exploiting the Entropy in a Data Stream, Theory of = Computing , vol 9, pp. 897-945. >=20 >=20 >=20 > On 01.04.2016 01:21, Russ Housley wrote: >> I reviewed this document for the Security Directorate after a request >> by the ART AD for an early review. >>=20 >> Version reviewed: draft-ietf-p2psip-share-08 >>=20 >>=20 >> Summary: Not Ready (from a Security Directorate perspective) >>=20 >>=20 >> Major Concerns: >>=20 >> In Section 3.1, there is an algorithm for assigning index values, and >> the text says that the high-order 24 bits of the Node-ID serve as a >> pseudo-random identifier. Since these 24 bits are obtained from the >> certificate that will be used to sign the stored data, the I think = that >> the same bits will be used over and over. If I got this correct, = then >> they are not pseudo-random. >>=20 >> In addition, Section 3.1 points to RFC 3550, Section 8.1 for a >> discussion of the probability of a collision. The consequences of a >> collision seem to be different in the two documents. The = consequences >> of a collision in the index should be clearly described in this >> document. >>=20 >>=20 >> Minor Concerns: None >>=20 >>=20 >> Nits: >>=20 >> Please pick one spelling for Resource-IDs. (This is the spelling used >> in RFC 6940.) However, this document sometimes uses "Resource Id". >>=20 >> Section 4.1 includes several examples for array indices. All of >> them are more than 32 bits: 0x123abc001, 0x123abc002, 0x123abc003, >> 0x123abc004, and 0x456def001. The most straightforward solution is >> to drop one of the zero digits. >>=20 >> To improve readability, I think the first sentence of Section 5.1 >> should read: "In certain use cases, such as conferencing, it is >> desirable..." >>=20 >> Section 5.1 says: >>=20 >> When defining the pattern, care must be taken to avoid conflicts >> arising from two user names of witch one is a substring of the = other. >>=20 >> I think this paragraph would be improved with an acceptable example = and >> a problematic example. >>=20 >> In Section 5.3: s/AOR/Address of Record (AOR)/ >>=20 >> In Section 6.2: s/This allows to invalidate entire subtrees/ >> /This allows the invalidation of entire subtrees/ >>=20 >> In Section 8, please provide a reference for RELOAD. >>=20 >=20 > --=20 >=20 > Prof. Dr. Thomas C. Schmidt > =B0 Hamburg University of Applied Sciences Berliner = Tor 7 =B0 > =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, = Germany =B0 > =B0 http://www.haw-hamburg.de/inet Fon: = +49-40-42875-8452 =B0 > =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: = +49-40-42875-8409 =B0 From nobody Thu Aug 25 02:43:07 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11D512D090 for ; Thu, 25 Aug 2016 02:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBzgBG43-fBT for ; Thu, 25 Aug 2016 02:43:04 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD93D1288B8 for ; Thu, 25 Aug 2016 02:43:02 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u7P9gwvH005442 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 25 Aug 2016 12:42:58 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u7P9gwSI022421; Thu, 25 Aug 2016 12:42:58 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22462.48546.248664.375329@fireball.acr.fi> Date: Thu, 25 Aug 2016 12:42:58 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 09:43:06 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Chris Inacio is next in the rotation. For telechat 2016-09-01 Reviewer LC end Draft Shawn Emery T 2016-08-26 draft-ietf-mpls-entropy-lsp-ping-03 Russ Housley TR2016-07-06 draft-ietf-nfsv4-multi-domain-fs-reqs-09 Eric Osterweil T 2016-08-26 draft-ietf-httpauth-extension-08 Tom Yu T 2016-08-24 draft-ietf-6man-ipv6-mibs-obsolete-01 For telechat 2016-09-15 Steve Hanna T 2016-09-06 draft-ietf-pals-mc-pon-04 Christian Huitema T 2016-09-06 draft-ietf-pce-pcep-service-aware-12 For telechat 2016-09-29 Dan Harkins T 2016-09-21 draft-ietf-pals-rfc4447bis-05 Last calls and special requests: Derek Atkins 2016-08-25 draft-ietf-hip-multihoming-10 Shaun Cooley 2016-08-25 draft-ietf-hip-rfc5206-bis-12 Alan DeKok 2016-04-30 draft-bradner-rfc3979bis-08 Donald Eastlake 2016-09-08 draft-ietf-mif-happy-eyeballs-extension-09 Daniel Kahn Gillmor E 2016-02-01 draft-ietf-rtcweb-security-08 Olafur Gudmundsson 2016-08-25 draft-ietf-softwire-unified-cpe-04 Phillip Hallam-Baker 2016-09-07 draft-ietf-core-etch-02 Paul Hoffman 2016-09-09 draft-ietf-taps-transports-11 Warren Kumari 2016-09-06 draft-sweet-rfc2911bis-09 Sandy Murphy 2016-08-12 draft-ietf-tsvwg-gre-in-udp-encap-13 Hannes Tschofenig E None draft-ietf-ntp-network-time-security-14 Hannes Tschofenig E None draft-ietf-ntp-cms-for-nts-message-06 Hannes Tschofenig E None draft-ietf-ntp-using-nts-for-ntp-05 Tina TSOU 2016-08-15 draft-ietf-ospf-two-part-metric-05 Brian Weis E 2016-02-01 draft-ietf-cdni-uri-signing-09 Paul Wouters 2016-09-02 draft-moriarty-pkcs1-01 Liang Xia 2016-09-02 draft-moriarty-pkcs5-v2dot1-01 Dacheng Zhang 2016-08-22 draft-ietf-core-http-mapping-13 -- kivinen@iki.fi From nobody Thu Aug 25 08:03:28 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8ECD12D0F6 for ; Thu, 25 Aug 2016 08:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYf1fWU4D7vd for ; Thu, 25 Aug 2016 08:03:26 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D86012D0DC for ; Thu, 25 Aug 2016 08:03:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 745673005AE for ; Thu, 25 Aug 2016 10:57:23 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id HY3KZy-od3Ia for ; Thu, 25 Aug 2016 10:57:22 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id 02C35300293; Thu, 25 Aug 2016 10:57:21 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 25 Aug 2016 10:57:26 -0400 Message-Id: To: draft-ietf-nfsv4-multi-domain-fs-reqs.all@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IESG , IETF SecDir Subject: [secdir] SecDir Review of draft-ietf-nfsv4-multi-domain-fs-reqs-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 15:03:27 -0000 I reviewed this document as part of the Security Directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Security Area Directors. Document authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments. Version reviewed: draft-ietf-nfsv4-multi-domain-fs-reqs-09 Summary: Ready Thank you for rewriting the Abstract and Introduction. They are much improved. Major Concerns: None. Minor Concerns: The first paragraph in Section 3 includes: "The issues with multi-domain deployments described in this document apply ...". I do not think that "issues" is the right word. To be consistent with the title of the document, it should be talking about guidance or deployment alternatives. In Section 6.2.1, it says: Multiple security services per NFSv4 Domain is allowed, and brings the issue of mapping multiple Kerberos 5 principal@REALMs to the same local ID. Methods of achieving this are beyond the scope of this document. I think it would be better to use "need" instead of "issue". Nits: Please change "internet" to "Internet" throughout the document. In Section 2, "Stringified UID or GID" definition: Please add "of" to the last sentence, so that it reads: "See Section 5.9 of [RFC5661]." From nobody Thu Aug 25 09:02:18 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6E812D1DD; Thu, 25 Aug 2016 09:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7sVQvhCA0CM; Thu, 25 Aug 2016 09:02:15 -0700 (PDT) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A60812D0FF; Thu, 25 Aug 2016 09:02:12 -0700 (PDT) Received: by mail-yb0-x22c.google.com with SMTP id z10so17960095ybh.2; Thu, 25 Aug 2016 09:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2MEv5HvN2tcFCLDIXhDDI8RSn2Maj/XGd9pD/lXyxsY=; b=yVkMqBYpkTHdJrHLvU0Uvdz2qAz8q7gVaUzwIlGT7XrefnqbUychZ+7OsekjA1v6cV 5PgQ6yrAHY5LShbFXNM6O+xPcutiVx9GknFb8qZvvPsE8Ae4irC13+wdmMu7m/Y39P15 CMfdn6e9lgPRqKyI69gyAbbOV7RxEESfNJYg6tM0PJSxaXsWkpVjdBALmNxQOB5se79A KAY2ovGDZXXmc3c73ifbkd3d/8EGZilKP1cmCqjT0hWiRQLPejfRbY0IPyZqsLWGFQvq qVCZKErIvcBbhonyz9DSDxG9KU//bsdZnJoRDUlaQJKkMGlfpV1QIJBsBdn8YgJ/bXw1 Yi3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2MEv5HvN2tcFCLDIXhDDI8RSn2Maj/XGd9pD/lXyxsY=; b=QliroB8aUkY1YLeme7lAkeLi4KfNZ1s+56tJZuSmFlG0semx+8bsKxNdA18+ouzphs vFhzSaiBFFQLbOGx9NWj2ALR42mWX5AAq4bQVreGjwfrJwrO17w20bL58wdXc9ftoWZn QeqjdponRnfHHPudqZmeuOp80eU7wv63hZHbGR7EvsiLBByITPpPkna/RBgRFBdehmtF 5fF/3Mlfbu/HtbEmAOttExI4v2RcmcxXeoeDqtDu30J0W/ZF2yyztTTAmjzLsl/m0Ikx ECMbhutEVSxj5jTDlNC1BCHAnj5vyWsCoBVWSh0ke5zdjwDR+jrkxv4pTEmwbR+QpvDR 0PVw== X-Gm-Message-State: AEkoouvHXNqxgUo9FBlMwKqfgjAYMZYJNLMIwTL71ajq+eaWgVQrFvPLMAAbQcafLj+aq3TWImLvEluJ3ddUBA== X-Received: by 10.37.203.88 with SMTP id b85mr7445455ybg.90.1472140931251; Thu, 25 Aug 2016 09:02:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.72.132 with HTTP; Thu, 25 Aug 2016 09:02:10 -0700 (PDT) In-Reply-To: References: From: Spencer Dawkins at IETF Date: Thu, 25 Aug 2016 11:02:10 -0500 Message-ID: To: Russ Housley Content-Type: multipart/alternative; boundary=94eb2c05608e4446a0053ae78550 Archived-At: Cc: draft-ietf-nfsv4-multi-domain-fs-reqs.all@ietf.org, IESG , IETF SecDir Subject: Re: [secdir] SecDir Review of draft-ietf-nfsv4-multi-domain-fs-reqs-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 16:02:17 -0000 --94eb2c05608e4446a0053ae78550 Content-Type: text/plain; charset=UTF-8 Hi, Russ, Thank you for the review! Spencer On Thu, Aug 25, 2016 at 9:57 AM, Russ Housley wrote: > I reviewed this document as part of the Security Directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the Security Area > Directors. Document authors, document editors, and WG chairs should > treat these comments just like any other IETF Last Call comments. > > Version reviewed: draft-ietf-nfsv4-multi-domain-fs-reqs-09 > > > Summary: Ready > > Thank you for rewriting the Abstract and Introduction. They are much > improved. > > > Major Concerns: None. > > > Minor Concerns: > > The first paragraph in Section 3 includes: "The issues with multi-domain > deployments described in this document apply ...". I do not think that > "issues" is the right word. To be consistent with the title of the > document, it should be talking about guidance or deployment > alternatives. > > In Section 6.2.1, it says: > > Multiple security services per NFSv4 Domain is allowed, and brings > the issue of mapping multiple Kerberos 5 principal@REALMs to the same > local ID. Methods of achieving this are beyond the scope of this > document. > > I think it would be better to use "need" instead of "issue". > > > Nits: > > Please change "internet" to "Internet" throughout the document. > > In Section 2, "Stringified UID or GID" definition: Please add "of" to > the last sentence, so that it reads: "See Section 5.9 of [RFC5661]." > > --94eb2c05608e4446a0053ae78550 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Russ,=C2=A0

Thank you for the revie= w!

Spencer

On Thu, Aug 25, 2016 at 9:57 AM, Russ Housley <= housley@vigilsec.com> wrote:
To: Chris Lonvick , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-mmusic-sdp-mux-attributes.all@ietf.org" Thread-Topic: SECDIR review of draft-ietf-mmusic-sdp-mux-attributes-13 Thread-Index: AQHR5bltj7pCDEeP606GPrcWxOR4VKBaJ8l1 Date: Thu, 25 Aug 2016 18:07:54 +0000 Message-ID: <1472148474472.98410@cisco.com> References: <5794D308.7010401@gmail.com>,<5794D38E.90709@gmail.com> In-Reply-To: <5794D38E.90709@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.64.93] Content-Type: multipart/alternative; boundary="_000_147214847447298410ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Cullen Jennings \(fluffy\)" , "Flemming Andreasen \(fandreas\)" , Bo Burman , "Suhas Nandakumar \(snandaku\)" Subject: Re: [secdir] SECDIR review of draft-ietf-mmusic-sdp-mux-attributes-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 18:07:58 -0000 --_000_147214847447298410ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ?Hello Chris Apologies for the delayed response ( was on vacation :-) ) Please see inline for responses to your review comments (marked with [[S= uhas]] )? Thanks Suhas Nandakumar ________________________________ From: Chris Lonvick Sent: Sunday, July 24, 2016 7:41 AM To: iesg@ietf.org; secdir@ietf.org; draft-ietf-mmusic-sdp-mux-attributes.al= l@ietf.org Subject: Re: SECDIR review of draft-ietf-mmusic-sdp-mux-attributes-13 Apologies for the duplication - resending to the right alias. On 7/24/16 9:39 AM, Chris Lonvick wrote: Hi, I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the security area directors= . Document editors and WG chairs should treat these comments just like any = other last call comments. I've been rather busy and haven't had time to thoroughly review this docume= nt. But I did look at the Security Considerations section and will recommen= d that some additions be made. The Security Considerations section says, "T= his document does not add any new security considerations beyond the existi= ng considerations in the RFCs for protocols that are being multiplexed toge= ther. " (First paragraph.) I believe that it would be helpful to readers an= d implementers if the specification were to give pointers to RFCs for proto= cols that are being multiplexed together, and their security considerations= . [[Suhas]] - On further internal discussions, we think the above paragraph n= eeds to be rephrased as below to be specific on the goals of this specifica= tion. "This document does not add any new security considerations beyond the exis= ting considerations in the RTP RFCs (RFC3550 and RFC3711) referenced by th= is specification." The section continues by saying, "The ways that SRTP streams are keyed is n= ot believed to create any two-time pad vulnerability for the currently defi= ned SRTP keying mechanism." (Second paragraph.) I may not have seen it but = I don't believe that this document specifies keying for SRTP streams, but o= nly references RFC4567 (Section 5.35) and RFC4572 (Section 5.36). If that's= the case, then this document doesn't need to opine about possible vulnerab= ilities in that area; leave it to those or subsequent documents to make tha= t analysis. [[Suhas]] - Agree with you. I will delete the sentence. It would be appropriate to reiterate that the CAUTION category may produce = some problems. [[Suhas]] - Sure, will add something in the lines of below "When multiplexing SDP attributes with the category "CAUTION", the implemen= tations should be aware of possible issues as described in this specificati= on" For completeness, it may be good to include pointers to other mmusic and SD= P documents that have addressed security aspects. A statement of how that m= ay apply to this specification would be appropriate. I don't think this wou= ld need to be detailed. [[Suhas]] How about something on the lines below. "The primary security for RTP including the way it is used here is describe= d in RC3550 and RFC3711" . Best regards, Chris --_000_147214847447298410ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

​Hello Chris


   Apologies for the delayed response ( was on vacation :-) )<= br>

   

   Please see inline for responses to your review comments (ma= rked with [[Suhas]] )​ 


Thanks

Suhas Nandakumar


From: Chris Lonvick <lon= vick.ietf@gmail.com>
Sent: Sunday, July 24, 2016 7:41 AM
To: iesg@ietf.org; secdir@ietf.org; draft-ietf-mmusic-sdp-mux-attrib= utes.all@ietf.org
Subject: Re: SECDIR review of draft-ietf-mmusic-sdp-mux-attributes-1= 3
 
Apologies for the duplication - resending to the right alias.

On 7/24/16 9:39 AM, Chris Lonvick wrote:
Hi,

I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the security area directors= . Document editors and WG chairs should treat these comments just like any other last call comments.

I've been rather busy and haven't had time to thoroughly review this docume= nt. But I did look at the Security Considerations section and will recommen= d that some additions be made. The Security Considerations section says, &q= uot;This document does not add any new security considerations beyond the existing considerations in the RFCs for= protocols that are being multiplexed together. " (First paragraph.) I= believe that it would be helpful to readers and implementers if the specif= ication were to give pointers to RFCs for protocols that are being multiplexed together, and their security cons= iderations.

[[Suhas]] - On further internal discussions, we t= hink the above paragraph needs to be rephrased as below to be specific on t= he goals of this specification.
"This document does not add any new security considerations beyond the existing considerations in the RTP  RFCs (RFC3550 and RFC3= 711) referenced by this specification."


The section continues by saying, "The ways that SRTP streams are keyed= is not believed to create any two-time pad vulnerability for the currently= defined SRTP keying mechanism." (Second paragraph.) I may not have se= en it but I don't believe that this document specifies keying for SRTP streams, but only references RFC4567 (Section 5.= 35) and RFC4572 (Section 5.36). If that's the case, then this document does= n't need to opine about possible vulnerabilities in that area; leave it to = those or subsequent documents to make that analysis. 
[[Suhas]] - Agree with you. I will delete the sen= tence.

It would be appropriate to reiterate that the CAUTION category may produce = some problems.
[[Suhas]] - Sure, will add something in the lines= of below 
"When multiplexing SDP attributes with the c= ategory "CAUTION", the implementations should be aware of po= ssible issues as described in this specification"


For completeness, it may be good to include pointers to other mmusic and SD= P documents that have addressed security aspects. A statement of how that m= ay apply to this specification would be appropriate. I don't think this wou= ld need to be detailed.

[[Suhas]] How about something on the lines below. 
"The primary security for RTP including the way it is = used here is described in RC3550 and RFC3711" .

Best regards,
Chris

--_000_147214847447298410ciscocom_-- From nobody Sat Aug 27 17:55:26 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD02C12D0CD; Sat, 27 Aug 2016 17:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEKjzpDK0vTR; Sat, 27 Aug 2016 17:55:23 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0906612D0AA; Sat, 27 Aug 2016 17:55:20 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id l203so156363419oib.1; Sat, 27 Aug 2016 17:55:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=G5M9JbFNIHTyRZOqvSpPIFrhFGYcOrc+OrNxanlxip0=; b=wPjREqL8Dgwvb6tUAEvW1NJsH/PySBBgYYyZBnhu6VFyB6GlTmdzC10KtET1KbNJ8u panr6Ap3r/+fm1UkbwevF0jA3a9DPsALDul8TswD07GcG6X9jkRDbBzO8OwUA1F3PWrC m0bFe6KbcmAz6f8NQFHRJFaZm75ZGFL2UaanMJHp31aCPEVrhbYSvuk8roY1EpdLaJ05 mHueCKB+Jszg8fCxapxr8Qc6w9tVMncEETDUNb+6Rd4Pu+x47aGohPqqlnWvnTncAcJN 7fPOZB7UoHvowkMJoZNDq6n0RIkICPbA7vNkwC2KByq+B/a99li693DJrKEnDCccyDtc 7Cvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=G5M9JbFNIHTyRZOqvSpPIFrhFGYcOrc+OrNxanlxip0=; b=Uc1KmyAGwdo4TGXndLugQTODs7ckwJF7g0wcIsmcmpxdp1mVpfTL+gZDkGaQc2VQKW q422u2jPc/os6qguj3QYBUrSlfWJLMAMq03LxGITCvqSMKqWV+xPGvywE5SLFvH+DaiF i4We+FzPzyrplT/xVBvODOStqw8AakVgoBiZ+qnGD1P29C/mVv04Yb9XeLt35m68Bf1Y 1EkKl04r+UijALFT6A1mF0AZR5cpzMDEavp7iU24pBnQmdepvTGBqyo7nqVrZa5HkoTR BAFw5AzmLVaVhr6Y31Tz+NukTfR3FIHgtZpxj0ywb4ya3m4kk9uaCcdTWeytDImLVlfO 0xqQ== X-Gm-Message-State: AE9vXwM5vKkr/gckGJS26Qq10ocdbYuwNJg66hwPZla5UqeIK8xdr5AdfiiOJuiTuMGWww== X-Received: by 10.202.75.197 with SMTP id y188mr6977035oia.10.1472345719429; Sat, 27 Aug 2016 17:55:19 -0700 (PDT) Received: from Chriss-Air.attlocal.net ([2602:306:838b:1c40:4514:17e:feee:a5cf]) by smtp.googlemail.com with ESMTPSA id w83sm12143412oif.5.2016.08.27.17.55.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Aug 2016 17:55:19 -0700 (PDT) To: "Suhas Nandakumar (snandaku)" , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-mmusic-sdp-mux-attributes.all@ietf.org" References: <5794D308.7010401@gmail.com> <5794D38E.90709@gmail.com> <1472148474472.98410@cisco.com> From: Chris Lonvick Message-ID: <57C23675.9020603@gmail.com> Date: Sat, 27 Aug 2016 19:55:17 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <1472148474472.98410@cisco.com> Content-Type: multipart/alternative; boundary="------------030204060005080508080905" Archived-At: Cc: "Cullen Jennings \(fluffy\)" , "Flemming Andreasen \(fandreas\)" , Bo Burman Subject: Re: [secdir] SECDIR review of draft-ietf-mmusic-sdp-mux-attributes-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2016 00:55:25 -0000 This is a multi-part message in MIME format. --------------030204060005080508080905 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Suhas, I hope your vacation was good. :-) These edits look appropriate. Best regards, Chris On 8/25/16 1:07 PM, Suhas Nandakumar (snandaku) wrote: > > ​Hello Chris > > > Apologies for the delayed response ( was on vacation :-) ) > > > Please see inline for responses to your review comments (marked > with [[Suhas]] )​ > > > Thanks > > Suhas Nandakumar > > > ------------------------------------------------------------------------ > *From:* Chris Lonvick > *Sent:* Sunday, July 24, 2016 7:41 AM > *To:* iesg@ietf.org; secdir@ietf.org; > draft-ietf-mmusic-sdp-mux-attributes.all@ietf.org > *Subject:* Re: SECDIR review of draft-ietf-mmusic-sdp-mux-attributes-13 > Apologies for the duplication - resending to the right alias. > > On 7/24/16 9:39 AM, Chris Lonvick wrote: >> Hi, >> >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors. Document editors and WG chairs should treat >> these comments just like any other last call comments. >> >> I've been rather busy and haven't had time to thoroughly review this >> document. But I did look at the Security Considerations section and >> will recommend that some additions be made. The Security >> Considerations section says, "This document does not add any new >> security considerations beyond the existing considerations in the >> RFCs for protocols that are being multiplexed together. " (First >> paragraph.) I believe that it would be helpful to readers and >> implementers if the specification were to give pointers to RFCs for >> protocols that are being multiplexed together, and their security >> considerations. >> >> [[Suhas]] - On further internal discussions, we think the above >> paragraph needs to be rephrased as below to be specific on the goals >> of this specification. >> "This document does not add any new security considerations beyond >> the existing considerations in the RTP RFCs (RFC3550 and >> RFC3711) referenced by this specification." >> >> >> The section continues by saying, "The ways that SRTP streams are >> keyed is not believed to create any two-time pad vulnerability for >> the currently defined SRTP keying mechanism." (Second paragraph.) I >> may not have seen it but I don't believe that this document specifies >> keying for SRTP streams, but only references RFC4567 (Section 5.35) >> and RFC4572 (Section 5.36). If that's the case, then this document >> doesn't need to opine about possible vulnerabilities in that area; >> leave it to those or subsequent documents to make that analysis. >> [[Suhas]] - Agree with you. I will delete the sentence. >> >> It would be appropriate to reiterate that the CAUTION category may >> produce some problems. >> [[Suhas]] - Sure, will add something in the lines of below >> "When multiplexing SDP attributes with the category "CAUTION", the >> implementations should be aware of possible issues as described in >> this specification" >> >> >> For completeness, it may be good to include pointers to other mmusic >> and SDP documents that have addressed security aspects. A statement >> of how that may apply to this specification would be appropriate. I >> don't think this would need to be detailed. >> >> [[Suhas]] How about something on the lines below. >> "The primary security for RTP including the way it is used here is >> described in RC3550 and RFC3711" . >> >> Best regards, >> Chris > --------------030204060005080508080905 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Suhas,

I hope your vacation was good.  :-)

These edits look appropriate.

Best regards,
Chris

On 8/25/16 1:07 PM, Suhas Nandakumar (snandaku) wrote:

​Hello Chris


   Apologies for the delayed response ( was on vacation :-) )

   

   Please see inline for responses to your review comments (marked with [[Suhas]] )​ 


Thanks

Suhas Nandakumar


From: Chris Lonvick <lonvick.ietf@gmail.com>
Sent: Sunday, July 24, 2016 7:41 AM
To: iesg@ietf.org; secdir@ietf.org; draft-ietf-mmusic-sdp-mux-attributes.all@ietf.org
Subject: Re: SECDIR review of draft-ietf-mmusic-sdp-mux-attributes-13
 
Apologies for the duplication - resending to the right alias.

On 7/24/16 9:39 AM, Chris Lonvick wrote:
Hi,

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

I've been rather busy and haven't had time to thoroughly review this document. But I did look at the Security Considerations section and will recommend that some additions be made. The Security Considerations section says, "This document does not add any new security considerations beyond the existing considerations in the RFCs for protocols that are being multiplexed together. " (First paragraph.) I believe that it would be helpful to readers and implementers if the specification were to give pointers to RFCs for protocols that are being multiplexed together, and their security considerations.

[[Suhas]] - On further internal discussions, we think the above paragraph needs to be rephrased as below to be specific on the goals of this specification.
"This document does not add any new security considerations beyond the existing considerations in the RTP  RFCs (RFC3550 and RFC3711) referenced by this specification."


The section continues by saying, "The ways that SRTP streams are keyed is not believed to create any two-time pad vulnerability for the currently defined SRTP keying mechanism." (Second paragraph.) I may not have seen it but I don't believe that this document specifies keying for SRTP streams, but only references RFC4567 (Section 5.35) and RFC4572 (Section 5.36). If that's the case, then this document doesn't need to opine about possible vulnerabilities in that area; leave it to those or subsequent documents to make that analysis. 
[[Suhas]] - Agree with you. I will delete the sentence.

It would be appropriate to reiterate that the CAUTION category may produce some problems.
[[Suhas]] - Sure, will add something in the lines of below 
"When multiplexing SDP attributes with the category "CAUTION", the implementations should be aware of possible issues as described in this specification"


For completeness, it may be good to include pointers to other mmusic and SDP documents that have addressed security aspects. A statement of how that may apply to this specification would be appropriate. I don't think this would need to be detailed.

[[Suhas]] How about something on the lines below. 
"The primary security for RTP including the way it is used here is described in RC3550 and RFC3711" .

Best regards,
Chris


--------------030204060005080508080905-- From nobody Sat Aug 27 22:33:46 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7A412D5BF; Sat, 27 Aug 2016 22:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zT4IFfBB2SAn; Sat, 27 Aug 2016 22:33:42 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19AD412B053; Sat, 27 Aug 2016 22:33:41 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id k90so199380775uak.1; Sat, 27 Aug 2016 22:33:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=LQTvEKPjjsp2LtYF5mDkM0JwQqTI/lJuirkBwNuBvCw=; b=zGvrhr6YIwzapt5Nn+jSWun8N1khEg+KIUiZrfqSmuY47yH57tm4VH9/4Sq4a570UK Ly6jhX9UG4B30reSL19xmavwBT7HgTQ7zXIAlOZDDt2QgUqIGlT/JSt4MNgRBnfozInR 7t44TAz3rybVOGcBf2XrMSNa+chq4jQgwoBhY0tgdA9RK/C6xUNB50pfBt2FVO7dV8Dp vLNNt+S3oEqdWNSCfDyVRkp4GQRkkCUuP0cFs0wfL9RTTIduHZOS4SPTnm4U7RLTpeM9 ds90ImXVdFvD1KtHPfsKk4eUMakLHDFSqLsahW5etvvi3wlZwCNuNu6CWGmuYqYV2qZ7 crBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=LQTvEKPjjsp2LtYF5mDkM0JwQqTI/lJuirkBwNuBvCw=; b=gf5XY9ioKkBgHwVL+ihg3AhIGHPPQdG3xV3XyE+VEW43IuhxoxbGFS5SOqLotOfz18 sZ8E+8eJ2jWv+fm1lxk3OkwfpemTZ5f3S/8WJM13DhDbUVRv8G2dAC+YI01a0RB3ue1+ b7N7PH/g5T8YScIwEt+nbcZ2Jfmo4KBZRIPyz4m468vOr9/4a+bI28UrcZfudyndWxhj zymx/uzRaNoijvE5lg8TFXr3mJeBUOzJPdqaFrgD54fMVDIg0ctoCHZMsoTq2fEj5m86 kDMAMQa/b9irMjYbc2pWKeZQzMeZXrXzHtsR6zWTq4LPHsVD6DgFrensgAXqjyYi/E+H zOnw== X-Gm-Message-State: AE9vXwPMD80MTnvdD5jzkZuURDfXky0slF61wyb0jERhzByUUwms3Z7i2Kwg9/BsMcSzimsL4pBHjhZgE3+QsA== X-Received: by 10.159.39.136 with SMTP id b8mr2032309uab.109.1472362420604; Sat, 27 Aug 2016 22:33:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.85.21 with HTTP; Sat, 27 Aug 2016 22:33:25 -0700 (PDT) From: Donald Eastlake Date: Sun, 28 Aug 2016 01:33:25 -0400 Message-ID: To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-mif-happy-eyeballs-extension.all@ietf.org Content-Type: multipart/alternative; boundary=94eb2c1242c80f9586053b1b175a Archived-At: Subject: [secdir] SECDIR review of draft-ietf-mif-happy-eyeballs-extension-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2016 05:33:44 -0000 --94eb2c1242c80f9586053b1b175a Content-Type: text/plain; charset=UTF-8 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. The goal of this Informational draft is to suggest extensions of Happy Eyeballs (RFC 6555), originally targeted at IP protocol decisions in the a dual stack environment, to the more general case of multiple provisioning domains. The result is referred to as HE-MIF (Happy Eyeballs - Multiple Interfaces). >From a security point of view, I believe this document needs a bit more in the Security Considerations section to be ready for publication. From a general text point of view, it would benefit from an English language review (see Editorials below). *Security:* The current Security Considerations section is the following sentence "The security consideration is following the statement in [RFC6555 ] and [RFC6418 ]." Having read the Security Considerations in those RFCs, I would say they are close to covering what should be mentioned in this document but there are two additional points that I think should be covered: (1) The dependence of the Happy Eyeballs interface and IP version choice on the results of generally unsecured connection attempts means that the interface and IP protocol used could be steered by an adversaries interference with such attempts. (2) To the extent that DNS query results affect HE-MIF decisions, DNSSEC should be used when available. I would also re-write the existing Securities Considerations sentence to be something more like: "For security considerations related to Happy Eyeballs, see [RFC6555]. For Security Considerations related to multiple provisioning domains, see [RFC6418]." *Editorial:* Section 1, 2nd sentence: "a issue" -> "an issue" Section 1, 2nd paragraph: Shouldn't some of these sentences that are questions end in a question mark? Section 1, 3rd paragraph: "defined in [RFC6555 ] necessary" -> "defined in [RFC6555 ] that are necessary" Section 3: "scenarios the HE-MIF targeted to use" -> "scenarios targeted by HE-MIF" Section 4, 1st sentence: "This section provides input parameter proposal that HE-MIF should catch." -> "This section describes the recommended input parameters to the HE-MIF decision process." Section 5, last sentence of the 2nd paragraph: "to proceed the sort process." probably -> "on which to sort" Section 5.1: "mergence" -> "the merger" "worth to note" -> "worthwhile to note" or "notable" Section 5.2.3, 1st paragraph: "receive certain next hop in a RA message" First of all, should be "an RA". But next hop what? You could replace "next hop" with "next hop information" but that is a bit vague. If this means "receive the next hop address in an RA message", say that. Section 5.2.3, 2nd paragraph, 1st sentence: "When destination and source pairs are identified, it should be treated with higher priority compared to others and choose to initiate the connection in advance." does not really make sense. Probably should say something like "When destination and source pairs are identified, a connection should be initiated only to the highest priority pair or pairs." Section 5.2.3, last paragraph: "would initiate" -> "would be initiated" "most fast" -> "fastest" or possible "most expeditious" Section 7.2, 1st paragraph: "in replied ICMP" -> "in an ICMP reply" Section 7.2, 2nd paragraph: "More optimal timer may be expected." -> "A more optimal timer for the circumstances is desirable." "The memo didn't" -> "This memo doesn't" Section 7.2, 1st bullet item: "compensate the issues" -> "compensate for this issue" "it leaves a" -> "this is left to a" Section 7.2, 2nd bullet item: "in the principle of" -> "based on" Section 7.3, 2nd bullet item: "cause messy" -> "cause confusion" Other editorial: Replace "WiFi" by "Wi-Fi" throughout. "out of the document scope" -> "out of this document's scope" or "beyond the scope of this document" "beyond this document scope" -> "beyond the scope of this document" or "beyond this document's scope" Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com --94eb2c1242c80f9586053b1b175a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security= directorate's ongoing effort to review all IETF documents being proces= sed by the IESG.=C2=A0 Document editors and WG chairs should treat these co= mments just like any other last call comments.

The= goal of this Informational draft is to suggest extensions of Happy Eyeball= s (RFC 6555), originally targeted at IP protocol decisions in the a dual st= ack environment, to the more general case of multiple provisioning domains.= The result is referred to as HE-MIF (Happy Eyeballs - Multiple Interfaces)= .

From a security point of view, I believe this do= cument needs a bit more in the Security Considerations section to be ready = for publication. From a general text point of view, it would benefit from a= n English language review (see Editorials below).

= Security:
The current Security Considerations section is t= he following sentence "The security consideration is following the statement in [RFC6555<= /a>]=C2=A0and [RF= C6418]."=C2=A0Having read the Security Considerations in those RFCs, I would say = they are close to covering what should be mentioned in this document but th= ere are two additional points that I think should be covered: (1) The depen= dence of the Happy Eyeballs interface and IP version choice on the results = of generally unsecured connection attempts means that the interface and IP = protocol used could be steered by an adversaries interference with such att= empts. (2) To the extent that DNS query results affect HE-MIF decisions, DN= SSEC should be used when available.

I would also r= e-write the existing Securities Considerations sentence to be something mor= e like: "For security considerations related to Happy Eyeballs, see [R= FC6555]. For Security Considerations related to multiple provisioning domai= ns, see [RFC6418]."

Editorial:<= /div>
Section 1, 2nd sentence: "a issue" -> "an issue= "

Section 1, 2nd paragraph: Shouldn't= some of these sentences that are questions end in a question mark?

Section 1, 3rd paragraph: "defined in=C2=A0[RFC6555] necessary" -> "defined in=C2=A0[RFC6555] that are necessary"=C2=A0

S= ection 3: "scenarios the HE-MIF targeted to use" -> "scenarios targeted by=C2=A0HE-MIF"=C2=A0
=
= Section 4, 1st sentenc= e: "This s= ection provides input parameter proposal that HE-MIF should=C2=A0catch." -> "= This section describes the recommended input parameters to the HE-MIF decis= ion process."

Section 5, last sentence of the 2nd paragraph: "<= span style=3D"color:rgb(0,0,0);font-size:13.3333px">to proceed=C2=A0= the sort process."= ; probably -> "on which to sort"

Section 5.1: "mergence" -> "th= e merger"
=C2=A0 =C2=A0 =C2=A0"worth to note" -> "worthwhile to note&quo= t; or "notable"

Section 5.2.3, 1st paragraph: "receive certain next hop=C2=A0in a RA message&qu= ot; First of all, should be "an RA". But next hop what? You could= replace "next hop" with "next hop information" but tha= t is a bit vague. If this means "receive the next hop address in an RA= message", say that.

Section 5.2.3, 2nd paragraph, 1st sentence: "When destination an= d source pairs are identified, it should be=C2=A0treated with higher priority compared to = others and choose to=C2=A0initiate the connection in advance." does not really make s= ense. Probably should say something like "When destination and source = pairs are identified, a connection should be initiated only to the highest = priority pair or pairs."

Section 5.2.3, last paragraph: "would initiate" -> &= quot;would be initiated"
=C2=A0 =C2=A0 =C2=A0"most fast" -> "fastest&quo= t; or possible "most expeditious"

Section 7.2, 1st paragraph: "in replied ICMP&q= uot; -> "in an ICMP reply"

Section 7.2, 2nd paragraph: "More optimal t= imer may be expected." -> "A more optimal timer for the circum= stances is=C2=A0desirable."
=C2=A0 =C2=A0 =C2=A0"= The memo didn&#= 39;t" -> "This memo doesn't"

Section 7.2, 1st bullet item: "<= span style=3D"color:rgb(0,0,0);font-size:13.3333px">compensate the issues&q= uot; -> "compensate for this issue"
=C2=A0 =C2=A0 =C2=A0"it leaves a" -&= gt; "this is left to a"

Section 7.2, 2nd bullet item: "in the principle of"= -> "based on"

Section 7.3, 2nd bullet item: "cause messy"= -> "cause confusion"


Other editorial:

Replac= e "WiFi" by "Wi-Fi" throughout.

"out of the=C2= =A0document sco= pe" -> "out of this document's scope" or "beyond= the scope of this document"
"beyond this document scope" -> "beyond the= scope of this document" or "beyond this document's scope&quo= t;

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0Donald E= . Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2=A0155 Beaver Street, Mi= lford, MA 01757 USA
=C2=A0d3e3e3@gmail.com
--94eb2c1242c80f9586053b1b175a-- From nobody Mon Aug 29 07:19:00 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7558912D776; Mon, 29 Aug 2016 07:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3iaxeq0_12qv; Mon, 29 Aug 2016 07:18:53 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:470:e448:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E420412D772; Mon, 29 Aug 2016 07:18:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id CEFA0E203A; Mon, 29 Aug 2016 10:18:51 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 06705-01; Mon, 29 Aug 2016 10:18:48 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:2001:470:e448:2:ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 5FD2FE2039; Mon, 29 Aug 2016 10:18:48 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1472480328; bh=Modn4RjNxvqR7ZRn50KZFxKdtwXVUVieF0vDdAUZT74=; h=From:To:Cc:Subject:Date; b=DMQiRQ/73PcY+CuEd0Q8wQU1JlZY8l/QDCBpCds9h5tV9mFEUS7F30yybLH6ynpT0 L8DRHUkQpk1crLxSTUOl0H4ubnxpX6BH9F/drAP99HlMKbFXLd5SxnGPNo7Vj1AkGZ KO3S5pN1BFAFF59k+8EWebjcll+noUQChVMSHp7M= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.14.8/Submit) id u7TEIlDk031774; Mon, 29 Aug 2016 10:18:47 -0400 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Date: Mon, 29 Aug 2016 10:18:47 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: tomhend@u.washington.edu, jari.arkko@piuha.net, hip-chairs@ietf.org, mail@christianvogt.net Subject: [secdir] sec-dir review of draft-ietf-hip-multihoming-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 14:18:54 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: Ready to publish. Details: No additional comments. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon Aug 29 12:51:14 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA7012D859; Mon, 29 Aug 2016 12:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.469 X-Spam-Level: X-Spam-Status: No, score=-7.469 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8C1CRwgxqa1l; Mon, 29 Aug 2016 12:51:10 -0700 (PDT) Received: from mx144.netapp.com (mx144.netapp.com [216.240.21.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B01812D862; Mon, 29 Aug 2016 12:51:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.30,252,1470726000"; d="scan'208";a="140393077" Received: from hioexcmbx04-prd.hq.netapp.com ([10.122.105.37]) by mx144-out.netapp.com with ESMTP; 29 Aug 2016 12:50:21 -0700 Received: from HIOEXCMBX03-PRD.hq.netapp.com (10.122.105.36) by hioexcmbx04-prd.hq.netapp.com (10.122.105.37) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 29 Aug 2016 12:50:20 -0700 Received: from HIOEXCMBX03-PRD.hq.netapp.com ([::1]) by hioexcmbx03-prd.hq.netapp.com ([fe80::a009:cb7a:e519:7347%21]) with mapi id 15.00.1210.000; Mon, 29 Aug 2016 12:50:19 -0700 From: "Adamson, Andy" To: Russ Housley Thread-Topic: SecDir Review of draft-ietf-nfsv4-multi-domain-fs-reqs-09 Thread-Index: AQHR/uEAScqWPrR74UmjQi/JRyLWv6Bg1LqA Date: Mon, 29 Aug 2016 19:50:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="utf-8" Content-ID: <001CA4020E134B45B6A3DA24E0CA07A6@hq.netapp.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-nfsv4-multi-domain-fs-reqs.all@ietf.org" , IESG , IETF SecDir Subject: Re: [secdir] SecDir Review of draft-ietf-nfsv4-multi-domain-fs-reqs-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 19:51:11 -0000 DQo+IE9uIEF1ZyAyNSwgMjAxNiwgYXQgMTA6NTcgQU0sIFJ1c3MgSG91c2xleSA8aG91c2xleUB2 aWdpbHNlYy5jb20+IHdyb3RlOg0KPiANCj4gSSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBh cnQgb2YgdGhlIFNlY3VyaXR5IERpcmVjdG9yYXRlJ3Mgb25nb2luZw0KPiBlZmZvcnQgdG8gcmV2 aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuICBUaGVz ZQ0KPiBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0 aGUgU2VjdXJpdHkgQXJlYQ0KPiBEaXJlY3RvcnMuICBEb2N1bWVudCBhdXRob3JzLCBkb2N1bWVu dCBlZGl0b3JzLCBhbmQgV0cgY2hhaXJzIHNob3VsZA0KPiB0cmVhdCB0aGVzZSBjb21tZW50cyBq dXN0IGxpa2UgYW55IG90aGVyIElFVEYgTGFzdCBDYWxsIGNvbW1lbnRzLg0KPiANCj4gVmVyc2lv biByZXZpZXdlZDogZHJhZnQtaWV0Zi1uZnN2NC1tdWx0aS1kb21haW4tZnMtcmVxcy0wOQ0KPiAN Cj4gDQo+IFN1bW1hcnk6IFJlYWR5DQo+IA0KPiBUaGFuayB5b3UgZm9yIHJld3JpdGluZyB0aGUg QWJzdHJhY3QgYW5kIEludHJvZHVjdGlvbi4gIFRoZXkgYXJlIG11Y2gNCj4gaW1wcm92ZWQuDQo+ IA0KPiANCj4gTWFqb3IgQ29uY2VybnM6ICBOb25lLg0KPiANCj4gDQo+IE1pbm9yIENvbmNlcm5z Og0KPiANCj4gVGhlIGZpcnN0IHBhcmFncmFwaCBpbiBTZWN0aW9uIDMgaW5jbHVkZXM6ICJUaGUg aXNzdWVzIHdpdGggbXVsdGktZG9tYWluDQo+IGRlcGxveW1lbnRzIGRlc2NyaWJlZCBpbiB0aGlz IGRvY3VtZW50IGFwcGx5IC4uLiIuICBJIGRvIG5vdCB0aGluayB0aGF0DQo+ICJpc3N1ZXMiIGlz IHRoZSByaWdodCB3b3JkLiAgVG8gYmUgY29uc2lzdGVudCB3aXRoIHRoZSB0aXRsZSBvZiB0aGUN Cj4gZG9jdW1lbnQsIGl0IHNob3VsZCBiZSB0YWxraW5nIGFib3V0IGd1aWRhbmNlIG9yIGRlcGxv eW1lbnQNCj4gYWx0ZXJuYXRpdmVzLg0KDQpIaSBSdXNzDQoNClRoYW5rcyBmb3IgeW91ciByZXZp ZXcuDQoNClRoaXMgbGF0ZXN0IHJvdW5kIG9mIGNvbW1lbnRzIC0gaW5jbHVkaW5nIHRoZSBHZW4t QVJUIHJldmlldyBmcm9tIEJyaWFuIENhcnBlbnRlciBzaG93cyB0aGF0IHRoZXJlIGlzIHN0aWxs IGFuIGltcGVkYW5jZSBtaXMtbWF0Y2ggYmV0d2VlbiB0aGUgdGl0bGUvYWJzdHJhY3QgYW5kIHRo ZSBpbnRlbmRlZCBzdGF0dXMgb2YgU3RhbmRhcmRzIFRyYWNrIHZlcnN1cyBhbiBJbmZvcm1hdGlv bmFsIGRyYWZ0IG9yIGJlc3QgcHJhY3RpY2VzLg0KDQpJIGZlZWwgdGhhdCB0aGUgdXNlIG9mICJH dWlkZWxpbmVzIiBpbiB0aGUgdGl0bGUsIGFuZCAiZ3VpZGFuY2UiIGluIHRoZSBhYnN0cmFjdCBw b2ludCB0byBhbiBJbmZvcm1hdGlvbmFsIGRyYWZ0IHJhdGhlciB0aGFuIGEgU3RhbmRhcmRzIHRy YWNrLg0KDQpUaGlzIGRyYWZ0IGlzIGEgUHJvcG9zZWQgU3RhbmRhcmQgKG5vdCBhbiBJbmZvcm1h dGlvbmFsIG9yIEJDUCkgYmVjYXVzZSB0aGUgTVVTVCBhbmQgUkVRVUlSRUQgbm90ZWQgaW4gc2Vj dGlvbiA2IG9mIHRoZSBkb2MgYXJlIGFic29sdXRlIHJlcXVpcmVtZW50cyBmb3IgYW4gTkZTdjQg bXVsdGktZG9tYWluIGZpbGUgbmFtZSBzcGFjZSB0byB3b3JrLiBUaGVzZSBjYW4gbm90IGJlIEJD UCBhcyBhbiBORlN2NCBtdWx0aS1kb21haW4gZmlsZSBuYW1lIHNwYWNlIHdpbGwgX25vdF8gd29y ayB3aXRob3V0IHRoZXNlIHJlcXVpcmVtZW50cy4NCg0KSSBoYXZlIGNvbXBsZXRlZCBhIGRyYWZ0 LWlldGYtbmZzdjQtbXVsdGktZG9tYWluLWZzLXJlcXMtMTAgd2l0aCB0aGUgZm9sbG93aW5nIGNo YW5nZXM6DQoNCjEpIFRoZSB0aXRsZSB0byBiZSBjaGFuZ2VkIGZyb20NCg0KIk11bHRpcGxlIE5G U3Y0IERvbWFpbiBOYW1lc3BhY2UgRGVwbG95bWVudCBHdWlkZWxpbmVzIg0KDQp0bw0KDQoiTXVs dGlwbGUgTkZTdjQgRG9tYWluIE5hbWVzcGFjZSBEZXBsb3ltZW50IFJlcXVpcmVtZW50cyINCg0K DQoyKSBUaGUgZmlyc3Qgc2VudGVuY2UgaW4gdGhlIGFic3RyYWN0IChhbmQgaW4gdGhlIGludHJv ZHVjdGlvbikgdG8gYmUgY2hhbmdlZCBmcm9tDQoNCiAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMg Z3VpZGFuY2Ugb24gdGhlIGRlcGxveW1lbnQgb2YgdGhlIE5GU3Y0DQogICBwcm90b2NvbHMgZm9y IHRoZSBjb25zdHJ1Y3Rpb24gb2YgYW4gTkZTdjQgZmlsZSBuYW1lIHNwYWNlIGluDQogICBlbnZp cm9ubWVudHMgd2l0aCBtdWx0aXBsZSBORlN2NCBEb21haW5zLg0KDQp0bw0KICAgVGhpcyBkb2N1 bWVudCBwcmVzZW50cyByZXF1aXJlbWVudHMgb24gdGhlIGRlcGxveW1lbnQgb2YgdGhlIE5GU3Y0 DQogICBwcm90b2NvbHMgZm9yIHRoZSBjb25zdHJ1Y3Rpb24gb2YgYW4gTkZTdjQgZmlsZSBuYW1l IHNwYWNlIGluDQogICBlbnZpcm9ubWVudHMgd2l0aCBtdWx0aXBsZSBORlN2NCBEb21haW5zLiAN Cg0KQW5vdGhlciBjb21tb24gYXJlYSBvZiBjb21tZW50IGNvbmNlcm5lZCB0aGUg4oCcU3RhbmQt YWxvbmUgRXhhbXBsZXMiIGV4YW1wbGVzIHNlY3Rpb24gNSBhbmQgIlN0YW5kLWFsb25lIEV4YW1w bGVzIGFuZCBNdWx0aXBsZSBORlN2NCBEb21haW4gTmFtZXNwYWNlc+KAnSBzZWN0aW9uIDguIFRo ZXNlIHNlY3Rpb24gZGVzY3JpYmUgImFsdGVybmF0aXZlcyBhbmQgZGlmZmVyaW5nIHNjZW5hcmlv c+KAnSB0byBoaWdobGlnaHQgdGhlIG5lZWQgZm9yIHRoZSByZXF1aXJlbWVudHMgZGVzY3JpYmVk IGluIHNlY3Rpb24gNi4NCg0KSSBhZGRyZXNzZWQgdGhlIGV4YW1wbGUgc2VjdGlvbnMgY29tbWVu dHMgYnkgYWRkaW5nIGNsYXJpZnlpbmcgdGV4dCB0byBlYWNoIG9mIHRoZXNlIHNlY3Rpb25zIGFz IHdlbGwgYXMgbW92aW5nIHRoZSBzZWNvbmQgc2VjdGlvbiBmcm9tIDggdG8gc2VjdGlvbiA3Lg0K DQoNCkkgaGF2ZSBhbHNvIGFkZHJlc3NlZCB0aGUgcmVtYWluaW5nIGNvbW1lbnRzIGZyb20gQnJp YW4sIFJ1c3MsIEFsZXhleSBNZWxuaWtvdiwgYW5kIEthdGhsZWVuIE1vcmlhcnR5Lg0KDQpJ4oCZ bGwgdXBsb2FkIHRoZSBuZXcgZHJhZnQgc29vbi4NCg0K4oCUPkFuZHkNCg0KPiANCj4gSW4gU2Vj dGlvbiA2LjIuMSwgaXQgc2F5czoNCj4gDQo+ICAgTXVsdGlwbGUgc2VjdXJpdHkgc2VydmljZXMg cGVyIE5GU3Y0IERvbWFpbiBpcyBhbGxvd2VkLCBhbmQgYnJpbmdzDQo+ICAgdGhlIGlzc3VlIG9m IG1hcHBpbmcgbXVsdGlwbGUgS2VyYmVyb3MgNSBwcmluY2lwYWxAUkVBTE1zIHRvIHRoZSBzYW1l DQo+ICAgbG9jYWwgSUQuICBNZXRob2RzIG9mIGFjaGlldmluZyB0aGlzIGFyZSBiZXlvbmQgdGhl IHNjb3BlIG9mIHRoaXMNCj4gICBkb2N1bWVudC4NCj4gDQo+IEkgdGhpbmsgaXQgd291bGQgYmUg YmV0dGVyIHRvIHVzZSAibmVlZCIgaW5zdGVhZCBvZiAiaXNzdWUiLg0KPiANCj4gDQo+IE5pdHM6 DQo+IA0KPiBQbGVhc2UgY2hhbmdlICJpbnRlcm5ldCIgdG8gIkludGVybmV0IiB0aHJvdWdob3V0 IHRoZSBkb2N1bWVudC4NCj4gDQo+IEluIFNlY3Rpb24gMiwgIlN0cmluZ2lmaWVkIFVJRCBvciBH SUQiIGRlZmluaXRpb246ICBQbGVhc2UgYWRkICJvZiIgdG8NCj4gdGhlIGxhc3Qgc2VudGVuY2Us IHNvIHRoYXQgaXQgcmVhZHM6ICJTZWUgU2VjdGlvbiA1Ljkgb2YgW1JGQzU2NjFdLiINCj4gDQoN Cg== From nobody Mon Aug 29 13:24:39 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9150112D889 for ; Mon, 29 Aug 2016 13:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ur5V0Kf5LoDB for ; Mon, 29 Aug 2016 13:24:36 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03B8912D881 for ; Mon, 29 Aug 2016 13:24:35 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u7TKOUNo003226 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 29 Aug 2016 20:24:31 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u7TKOUa8015879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 29 Aug 2016 20:24:30 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u7TKOO4A022717; Mon, 29 Aug 2016 20:24:29 GMT Received: from [10.159.78.71] (/10.159.78.71) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 29 Aug 2016 13:24:23 -0700 References: <5770C231.9060301@oracle.com> To: "secdir@ietf.org" From: Shawn M Emery X-Forwarded-Message-Id: <5770C231.9060301@oracle.com> Message-ID: <3413ce55-8a13-9698-5985-7fecc8c8f038@oracle.com> Date: Mon, 29 Aug 2016 14:26:37 -0600 User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <5770C231.9060301@oracle.com> Content-Type: multipart/alternative; boundary="------------4B0D2A68AD9598BB987E2A73" X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: draft-ietf-mpls-entropy-lsp-ping.all@tools.ietf.org Subject: [secdir] Review of draft-ietf-mpls-entropy-lsp-ping-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 20:24:37 -0000 This is a multi-part message in MIME format. --------------4B0D2A68AD9598BB987E2A73 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft specifies multipath support in environments where Entropy Labels (ELs) are used so that Label Switched Path (LSP) Ping and Traceroute operations are possible. The security considerations section does exist and refers to the security considerations in base specifications for applicability. The sections continues that there are no new security considerations with this specification. I agree with this assertion. General comments: None. Editorial comments: s/initiator to not be able to/initiator that is unable to/ "LSPs stitched together": not for sure what "stitched" means and wasn't defined in the Terminology section. Shawn. -- --------------4B0D2A68AD9598BB987E2A73 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit 

    

      
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors. Document editors and WG chairs should treat these
comments just like any other last call comments.

This draft specifies multipath support in environments where Entropy Labels
(ELs) are used so that Label Switched Path (LSP) Ping and Traceroute
operations are possible.

The security considerations section does exist and refers to the security
considerations in base specifications for applicability.  The sections
continues that there are no new security considerations with
this specification.  I agree with this assertion.

General comments:

None.

Editorial comments:

s/initiator to not be able to/initiator that is unable to/

"LSPs stitched together": not for sure what "stitched" means and wasn't
defined in the Terminology section.

Shawn.
--


    

  


--------------4B0D2A68AD9598BB987E2A73--


From nobody Tue Aug 30 07:25:29 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1628012D93B for ; Tue, 30 Aug 2016 07:25:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTO188rDDXl3 for ; Tue, 30 Aug 2016 07:25:23 -0700 (PDT)
Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5986212D68B for ; Tue, 30 Aug 2016 07:21:51 -0700 (PDT)
Received: by mail-oi0-x232.google.com with SMTP id j203so27755200oih.2 for ; Tue, 30 Aug 2016 07:21:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wajsYqueQ+PBhsOOgeHkKIhJGBu+ta4koookhnNR5kg=; b=bCQDYd76CRZfdT1cDs3cqK3hHL7niFEzJaulRr/zF4wMGTr7luM6gnD8EDLvypaY8Z sdYUscsjHkK5UgS38tTbTRQl523Pvv4hBZ4ytvLQw9U6p35Ddc28aAnGnoCnQMvbKB8t 9HFDF1yV8n16Btht7DmCQQ8dsVB6CfTSBxxtD2Z8pm70pnKPNfmN08XWMhyUrLwZXdYF DplVomkPYj2zEmj7M2ctfn24dK4/h05pKLEdOKD2TYUgT5Y21WjlfXkiePetSw4RldqA VugYYCAlLsfLxBC2pfizALzkt/mm1P1HqGoPP+PhfjS9PmM8SZn1qYXdDOM+J7ye2yNS tUWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wajsYqueQ+PBhsOOgeHkKIhJGBu+ta4koookhnNR5kg=; b=MC9DEpKgVVyTgLC8Jq++BG6+mdN4nQS25PYdA4tptqX6BMd1IP5I89QUyPwcjkhVMw csFwZGxou9MDF/S14InvHqtFi/BXhQdOhILfcLhCLJ631KN1rNvoKp2nltKNWCT69Pqu 9ird2jjwmkWR35gjZeR/n5/9FysjdOxitUiJ306Q+3Cr0BlhP7eqjaI3kgqrKoCwguau kV1/npET4PripKz+1SYsWme5tGCudPftJoLI0SA13uu/IaxLvEZMPyC81Jl/gHPqpzKk pCRapIGoZTjvAgL+xA16B7/UGwL8nsC9U9SF2uy/Wwlrsw4NLt4GydaZP70Q0XQUFYEz g+EQ==
X-Gm-Message-State: AE9vXwO+vLYYwXRPkLeddBAPBjCk4BFG+roIF4SHEqmuD5mlIZG4J/CSo/JiOP2pLZ9LXvS1MMOMewnsL3laUA==
X-Received: by 10.157.14.84 with SMTP id n20mr1938013otd.55.1472566910780; Tue, 30 Aug 2016 07:21:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.138.35 with HTTP; Tue, 30 Aug 2016 07:21:30 -0700 (PDT)
In-Reply-To: <3413ce55-8a13-9698-5985-7fecc8c8f038@oracle.com>
References: <5770C231.9060301@oracle.com> <3413ce55-8a13-9698-5985-7fecc8c8f038@oracle.com>
From: "Andrew G. Malis" 
Date: Tue, 30 Aug 2016 22:21:30 +0800
Message-ID: 
To: Shawn M Emery 
Content-Type: multipart/alternative; boundary=001a113db5e8a02e55053b4ab3cd
Archived-At: 
Cc: draft-ietf-mpls-entropy-lsp-ping.all@tools.ietf.org, "secdir@ietf.org" 
Subject: Re: [secdir] Review of draft-ietf-mpls-entropy-lsp-ping-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Aug 2016 14:25:28 -0000

--001a113db5e8a02e55053b4ab3cd
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Shawn,

Many thanks for your review. We=E2=80=99ll fix the editorial comment. Regar=
ding LSP
stitching, this is well known to MPLS experts, but you=E2=80=99re right, th=
is
should be referenced. RFC 6424, which we already have in the references, is
an excellent reference for LSP stitching and using LSP Ping and Traceroute
over stitched LSPs. We=E2=80=99ll add [RFC6424] in the appropriate location=
s.

Thanks again,
Andy


On Tue, Aug 30, 2016 at 4:26 AM, Shawn M Emery 
wrote:

> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the security
> area directors. Document editors and WG chairs should treat these
> comments just like any other last call comments.
>
> This draft specifies multipath support in environments where Entropy Labe=
ls
> (ELs) are used so that Label Switched Path (LSP) Ping and Traceroute
> operations are possible.
>
> The security considerations section does exist and refers to the security
> considerations in base specifications for applicability.  The sections
> continues that there are no new security considerations with
> this specification.  I agree with this assertion.
>
> General comments:
>
> None.
>
> Editorial comments:
>
> s/initiator to not be able to/initiator that is unable to/
>
> "LSPs stitched together": not for sure what "stitched" means and wasn't
> defined in the Terminology section.
>
> Shawn.
> --
>
>

--001a113db5e8a02e55053b4ab3cd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Shawn,

Many thanks for your review. We=
=E2=80=99ll fix the editorial comment. Regarding LSP stitching, this is wel=
l known to MPLS experts, but you=E2=80=99re right, this should be reference=
d. RFC 6424, which we already have in the references, is an excellent refer=
ence for LSP stitching and using LSP Ping and Traceroute over stitched LSPs=
. We=E2=80=99ll add [RFC6424] in the appropriate locations.

<=
/div>
Thanks again,
Andy


On Tue, Aug 30, 2016 at 4:2=
6 AM, Shawn M Emery <shawn.emery@oracle.com> wrote:
=


 =20

   =20
 =20
  

    

    

      
I have reviewed this document as part of the security directorat=
e's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors. Document editors and WG chairs should treat these
comments just like any other last call comments.

This draft specifies multipath support in environments where Entropy Labels
(ELs) are used so that Label Switched Path (LSP) Ping and Traceroute
operations are possible.

The security considerations section does exist and refers to the security
considerations in base specifications for applicability.  The sections
continues that there are no new security considerations with
this specification.  I agree with this assertion.

General comments:

None.

Editorial comments:

s/initiator to not be able to/initiator that is unable to/

"LSPs stitched together": not for sure what "stitched" =
means and wasn't
defined in the Terminology section.

Shawn.
--


    

  






--001a113db5e8a02e55053b4ab3cd--


From nobody Wed Aug 31 03:03:11 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB14912DA93; Wed, 31 Aug 2016 03:03:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.768
X-Spam-Level: 
X-Spam-Status: No, score=-4.768 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CAlMPwNTBAd; Wed, 31 Aug 2016 03:03:04 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 357A912D0D9; Wed, 31 Aug 2016 03:03:03 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CQM67243; Wed, 31 Aug 2016 10:03:01 +0000 (GMT)
Received: from SZXEMA415-HUB.china.huawei.com (10.82.72.33) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 31 Aug 2016 11:02:58 +0100
Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.6]) by SZXEMA415-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0235.001; Wed, 31 Aug 2016 18:02:50 +0800
From: "Xialiang (Frank)" 
To: "'iesg@ietf.org'" , "'secdir@ietf.org'" ,  "draft-moriarty-pkcs5-v2dot1.all@tools.ietf.org" 
Thread-Topic: secdir review of draft-moriarty-pkcs5-v2dot1-01
Thread-Index: AdIDbtQMbJEl3m8/Q2qkTlutw9fhVA==
Date: Wed, 31 Aug 2016 10:02:50 +0000
Message-ID: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.201.116.206]
Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12AFB7711SZXEMA502MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0203.57C6AB55.00EA, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.4.6, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: d7ff7d9256b9ade65b9b6a8d5c30ccbc
Archived-At: 
Subject: [secdir] secdir review of draft-moriarty-pkcs5-v2dot1-01
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Aug 2016 10:03:07 -0000

--_000_C02846B1344F344EB4FAA6FA7AF481F12AFB7711SZXEMA502MBSchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello,

I have reviewed this document as part of the security directorate's ongoing=
 effort to review all IETF documents being processed by the IESG.  These co=
mments were written primarily for the benefit of the security area director=
s.  Document editors and WG chairs should treat these comments just like an=
y other last call comments.


This document provides recommendations for the implementation of password-b=
ased cryptography, covering key derivation functions, encryption schemes, m=
essage-authentication schemes, and ASN.1 syntax identifying the techniques.=
 And this document represents a republication of PKCS #5 v2.1 from RSA Labo=
ratories' Public-Key Cryptography Standards (PKCS) series. By publishing th=
is RFC, change control is transferred to the IETF.


In general, this draft is based on [RFC2898] (PKCS #5) and RSA new released=
 PKCS #5 V2.1 specification, and includes some minor updates to them. So, i=
t has a solid security basis. Regarding to the new introduced contents, the=
re are no more new security threats identified.


Summary: this document appears in reasonably good shape, with minor issues =
that should be addressed before publication.


Below is a series of my comments, nits for your consideration.


comments:

Section 5.1
"S    salt, an eight-octet string": This sentence is not accurate. The Salt=
 used in the PBKDF1 algorithm should be an octet string with more than 8 by=
tes length here;

section 5.2
"applied to the password P and the concatenation of the salt S and the bloc=
k index i:": this sentence seems to be not clear to explain the following s=
eries of equations, for example:
1. how to use "i" in them?
2. how to use "Salt" in them?
Would you please clarify the issue and improve the content to be more clear=
?


nits:

Abstract
1. PKCS #8 should have a reference of [PKCS8][RFC5958];
2. The second "-" in "password-based-key" should be removed;
3. If there is PKCS #5 V2.1 specification, the reference of it should be ad=
ded after the content of "PKCS #5 V2.1";

Section 1
Please split the last two words of "compatibletechniques.".

Section 2
Miss "\xor" before "bit-wise exclusive-or of two octet strings".

Section 5.1
"DK =3D Tc<0..dkLen-1>": Tc should be T_c.

Section 5.2
1. The title of Section 5.2 should be "PBKDF2";
2. A calculation equation is missed here: "F (P, S, c, i) =3D U_1 \xor U_2 =
\xor ... \xor U_c".

Section 6.1.1
The title of the Section should be "PBES1 Encryption Operation".

Appendix A.1
"for PBES1" should be changed to "for PBKDF1".


Thanks!

B.R.
Frank


--_000_C02846B1344F344EB4FAA6FA7AF481F12AFB7711SZXEMA502MBSchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hello,


 


I have reviewed this document a=
s part of the security directorate's ongoing effort to review all IETF docu=
ments being processed by the IESG.  These comments were written primar=
ily for the benefit of the security area
 directors.  Document editors and WG chairs should treat these comment=
s just like any other last call comments.


 


 


This document provides recommen=
dations for the implementation of password-based cryptography, covering key=
 derivation functions, encryption schemes, message-authentication schemes, =
and ASN.1 syntax identifying the techniques.
 And this document represents a republication of PKCS #5 v2.1 from RSA Labo=
ratories’ Public-Key Cryptography Standards (PKCS) series. By publish=
ing this RFC, change control is transferred to the IETF.<=
/p>

 


 


In general, this draft is based=
 on [RFC2898] (PKCS #5) and RSA new released PKCS #5 V2.1 specification, an=
d includes some minor updates to them. So, it has a solid security basis. R=
egarding to the new introduced contents,
 there are no more new security threats identified.


 


 


Summary: this document appears =
in reasonably good shape, with minor issues that should be addressed before=
 publication.


 


 


Below is a series of my comment=
s, nits for your consideration.


 


 


comments:


 


Section 5.1

"S    salt,=
 an eight-octet string": This sentence is not accurate. The Salt used =
in the PBKDF1 algorithm should be an octet string with more than 8 bytes le=
ngth here;


 


section 5.2

"applied to the password P=
 and the concatenation of the salt S and the block index i:": this sen=
tence seems to be not clear to explain the following series of equations, f=
or example:


1. how to use "i" in =
them?


2. how to use "Salt" =
in them?


Would you please clarify the is=
sue and improve the content to be more clear?


 


 


nits:


 


Abstract


1. PKCS #8 should have a refere=
nce of [PKCS8][RFC5958];


2. The second "-" in =
"password-based-key" should be removed;


3. If there is PKCS #5 V2.1 spe=
cification, the reference of it should be added after the content of "=
PKCS #5 V2.1";


 


Section 1


Please split the last two words=
 of "compatibletechniques.".


 


Section 2


Miss "\xor" before &q=
uot;bit-wise exclusive-or of two octet strings".


 


Section 5.1

"DK =3D Tc<0..dkLen-1&g=
t;": Tc should be T_c.


 


Section 5.2

1. The title of Section 5.2 sho=
uld be "PBKDF2";


2. A calculation equation is mi=
ssed here: "F (P, S, c, i) =3D U_1 \xor U_2 \xor ... \xor U_c".


 


Section 6.1.1=



The title of the Section should=
 be "PBES1 Encryption Operation".


 


Appendix A.1<=
/p>

"for PBES1" should be=
 changed to "for PBKDF1".


 


 


Thanks!


 


B.R.


Frank


 






--_000_C02846B1344F344EB4FAA6FA7AF481F12AFB7711SZXEMA502MBSchi_--


From nobody Wed Aug 31 07:07:55 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB9D12DBE1; Wed, 31 Aug 2016 07:07:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level: 
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=Ejb1x8Jc; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=IgM4FVYd
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rA2VD8m2wBGV; Wed, 31 Aug 2016 07:07:48 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B772E12DC70; Wed, 31 Aug 2016 06:53:18 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id D132020349; Wed, 31 Aug 2016 09:53:17 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 31 Aug 2016 09:53:17 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=V6HnEOkUxIoqbHiqySL/T8MUkv4=; b=Ejb1x8 Jcke0uxGrO5YgvswsgFJr+c3oZNX0wdJawlbFQbe8k80rBDA9uyMPCa0bDxRxD0J 3GFDFgXCDYvEu8he7ueGUOJqqueWaTrtFayiRCvKzujBHnG55eKAA/bD6f9yixsr asM7GeKnGRK6v8t4lDwhbAuXBqvg29Fj+mqI8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=V6HnEOkUxIoqbHi qySL/T8MUkv4=; b=IgM4FVYdxf2P/loZzOLrPKjC1wmaeA2g0/vUE1h0TBFlDRv nhGfyeT0ATTg0n+N928L0iMXWPi2UfuG1dLpt/jb6WznMtKOdRQqSZ0dksGoGXIU Vbk4kkLVbIkntp0X9kDCz00P11hClj+uPiY8XELQdDyocrOAt1L2q7QFZDEU=
X-Sasl-enc: yguwGFVPCDcPXeqNhfI6msU6DAw9skk5R8S56wGYHOy+ 1472651597
Received: from sjc-alcoop-8819.cisco.com (unknown [128.107.241.183]) by mail.messagingengine.com (Postfix) with ESMTPA id 99A57F29D2; Wed, 31 Aug 2016 09:53:16 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper 
In-Reply-To: <06B65EC5-1582-4F4A-9325-47453B1ABF6C@cooperw.in>
Date: Wed, 31 Aug 2016 09:53:15 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <730688AE-3DDE-4677-B4C9-A4173756175A@cooperw.in>
References: <46d6459124394dddbff5e9d7f48bf23b@HUB02.mailcluster.haw-hamburg.de> <71ec7240-8b2d-2f47-034e-f10faba8ea27@haw-hamburg.de> <06B65EC5-1582-4F4A-9325-47453B1ABF6C@cooperw.in>
To: Russ Housley 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "Thomas C. Schmidt" , "draft-ietf-p2psip-share.all@ietf.org" , IETF SecDir 
Subject: Re: [secdir] Early SecDir Review of draft-ietf-p2psip-share-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Aug 2016 14:07:54 -0000

Hi Russ,

Any update on this?

Thanks,
Alissa

> On Aug 24, 2016, at 10:03 AM, Alissa Cooper  wrote:
>=20
> Russ,
>=20
> Any thoughts on the question Thomas poses below?
>=20
> Thanks,
> Alissa
>=20
>> On Aug 15, 2016, at 3:20 PM, Thomas C. Schmidt =
 wrote:
>>=20
>> Russ,
>>=20
>> I'm only now coming back to this long delayed issue - sorry for that.
>>=20
>> Let me summarize the story about indexing (Section 3.1 in ShaRe):
>>=20
>> 1. The application use case for shared resources is that of a small =
group of peers sharing a data structure, which can be an array. Array =
indexing according to Sec. 3.1 uses parts of the Node-ID (the 24 least =
significant bits of a SHA-1 hash) to generate isolation among peers, and =
at the same time generate an unambiguous, unique binding between a node =
and the array elements it is allowed to write.
>>=20
>> 2. The threat of collisions is that this binding becomes ambiguous =
and - if not prevented - would cause an option for theft of =
resource/service. There is no threat of privilege escalation, here, as =
entries are signed.
>>=20
>> 3. SHA-1 is collision-resistant and the probability of collisions is =
expected to be low [1], but the output is not perfectly random. So I =
agree that the ref to the RFC 3550 calculation is a bit too optimistic. =
However, neither me nor a crypto colleague could find a rigorous =
calculation of the SHA-1 collision probability ...
>>=20
>> 4. The straight-forward counter measure against theft of resources in =
the case of a collision is a refusal of overwriting by the storing peer =
(see end of Section 6.1). This may exclude a node with colliding ID bits =
from participation in sharing a resource.
>>=20
>> Now I see two choices:
>>=20
>> (1) We leave it that way, i.e., clarify the text in Section 3.1 and =
point out that a node under collision could re-join the overlay with a =
different node-ID.
>>=20
>> (2) We could advise a procedure to generate non-colliding ID bits by =
rehashing the node-ID. I.e., a node that experiences a collision could =
rehash its ID to obtain new ID bits and the storing peer could validate =
by also iterating the hashing.
>>=20
>> (2) would complicate the whole process for considerably rare cases, =
why I'm in favor of (1).
>>=20
>> What would you suggest?
>>=20
>> Thanks,
>> Thomas
>>=20
>> [1] K. Chung, M. Mitzenmacher, and S. Vadhan: Why Simple Hash =
Functions Work: Exploiting the Entropy in a Data Stream, Theory of =
Computing , vol 9, pp. 897-945.
>>=20
>>=20
>>=20
>> On 01.04.2016 01:21, Russ Housley wrote:
>>> I reviewed this document for the Security Directorate after a =
request
>>> by the ART AD for an early review.
>>>=20
>>> Version reviewed: draft-ietf-p2psip-share-08
>>>=20
>>>=20
>>> Summary: Not Ready (from a Security Directorate perspective)
>>>=20
>>>=20
>>> Major Concerns:
>>>=20
>>> In Section 3.1, there is an algorithm for assigning index values, =
and
>>> the text says that the high-order 24 bits of the Node-ID serve as a
>>> pseudo-random identifier.  Since these 24 bits are obtained from the
>>> certificate that will be used to sign the stored data, the I think =
that
>>> the same bits will be used over and over.  If I got this correct, =
then
>>> they are not pseudo-random.
>>>=20
>>> In addition, Section 3.1 points to RFC 3550, Section 8.1 for a
>>> discussion of the probability of a collision.  The consequences of a
>>> collision seem to be different in the two documents.  The =
consequences
>>> of a collision in the index should be clearly described in this
>>> document.
>>>=20
>>>=20
>>> Minor Concerns:  None
>>>=20
>>>=20
>>> Nits:
>>>=20
>>> Please pick one spelling for Resource-IDs. (This is the spelling =
used
>>> in RFC 6940.)  However, this document sometimes uses "Resource Id".
>>>=20
>>> Section 4.1 includes several examples for array indices.  All of
>>> them are more than 32 bits: 0x123abc001, 0x123abc002, 0x123abc003,
>>> 0x123abc004, and 0x456def001.  The most straightforward solution is
>>> to drop one of the zero digits.
>>>=20
>>> To improve readability, I think the first sentence of Section 5.1
>>> should read: "In certain use cases, such as conferencing, it is
>>> desirable..."
>>>=20
>>> Section 5.1 says:
>>>=20
>>>  When defining the pattern, care must be taken to avoid conflicts
>>>  arising from two user names of witch one is a substring of the =
other.
>>>=20
>>> I think this paragraph would be improved with an acceptable example =
and
>>> a problematic example.
>>>=20
>>> In Section 5.3: s/AOR/Address of Record (AOR)/
>>>=20
>>> In Section 6.2: s/This allows to invalidate entire subtrees/
>>>                /This allows the invalidation of entire subtrees/
>>>=20
>>> In Section 8, please provide a reference for RELOAD.
>>>=20
>>=20
>> --=20
>>=20
>> Prof. Dr. Thomas C. Schmidt
>> =B0 Hamburg University of Applied Sciences                   Berliner =
Tor 7 =B0
>> =B0 Dept. Informatik, Internet Technologies Group    20099 Hamburg, =
Germany =B0
>> =B0 http://www.haw-hamburg.de/inet                   Fon: =
+49-40-42875-8452 =B0
>> =B0 http://www.informatik.haw-hamburg.de/~schmidt    Fax: =
+49-40-42875-8409 =B0
>=20


From nobody Wed Aug 31 15:57:25 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEAD312D7C1; Wed, 31 Aug 2016 15:57:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.769
X-Spam-Level: 
X-Spam-Status: No, score=-4.769 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D54tekHxz4_N; Wed, 31 Aug 2016 15:57:18 -0700 (PDT)
Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6646312D77D; Wed, 31 Aug 2016 15:57:18 -0700 (PDT)
X-AuditID: 1209190e-ef3ff70000000272-74-57c760cbe582
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by  (Symantec Messaging Gateway) with SMTP id A8.55.00626.BC067C75; Wed, 31 Aug 2016 18:57:17 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id u7VMvFcA023672; Wed, 31 Aug 2016 18:57:15 -0400
Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u7VMvDq0032414; Wed, 31 Aug 2016 18:57:14 -0400
From: Tom Yu 
To: , , 
Date: Wed, 31 Aug 2016 18:57:13 -0400
Message-ID: 
Lines: 11
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFIsWRmVeSWpSXmKPExsUixG6nrns24Xi4waLjPBb7vu9kt5jxZyKz xYeFD1kcmD2WLPnJFMAYxWWTkpqTWZZapG+XwJVx6kBAwSyWilmrexkbGLczdzFyckgImEgc ftYFZgsJtDFJfH6s2cXIBWRvZJTY93QWG4TzhlHi9PeL7CBVbALSEscv72ICsUUEUiVe/v3F BmILC3hITF65HGwSi4CqxIJXH8HqeQV0JRZOnw4U5+DgEeCUODGlEiIsKHFy5hMWEJtZQEvi xr+XTBMYeWYhSc1CklrAyLSKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI11gvN7NELzWldBMjKFg4 Jfl2ME5q8D7EKMDBqMTD6/DmWLgQa2JZcWXuIUZJDiYlUV61uOPhQnxJ+SmVGYnFGfFFpTmp xYcYJTiYlUR4X8QD5XhTEiurUovyYVLSHCxK4rxdMw6ECwmkJ5akZqemFqQWwWRlODiUJHj/ gDQKFqWmp1akZeaUIKSZODhBhvMADf8GNry4IDG3ODMdIn+KUZdjwY/ba5mEWPLy81KlxHmT QIoEQIoySvPg5oCjXIhx3ytGcaC3hHl9gDEvxANMEHCTXgEtYQJaUnDnMMiSkkSElFQDY3Xn Yy4F4yUrFbwvFjhO/xlg9qv6dJBO/O8Tb/u3ur6c2H26317jhUvgjieL8msfTiteuMRtnxx/ 4o3Xpt9FNW3jLv+aqaN6Z56u+rLV6XduW+d6q61/Fnup5Q1nhe/1vXeZl6pcFW3786R9Ycln 1h8m06QzBRvOVstwn8p16SrLdS//kvokWomlOCPRUIu5qDgRAOf1rYrNAgAA
Archived-At: 
Subject: [secdir]  secdir review of draft-ietf-6man-ipv6-mibs-obsolete-01
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Aug 2016 22:57:20 -0000

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

Summary: ready

The security considerations section of this document seems reasonable.
Republishing obsolete MIBs that are explicitly marked as obsolete in
their bodies sounds like a good idea.


From nobody Wed Aug 31 16:01:59 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2457E12D77D; Wed, 31 Aug 2016 16:01:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.749
X-Spam-Level: 
X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dmz2IuNzBVo; Wed, 31 Aug 2016 16:01:52 -0700 (PDT)
Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB02612D776; Wed, 31 Aug 2016 16:01:51 -0700 (PDT)
X-AuditID: 12074423-557ff70000005e87-e5-57c761def8ca
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by  (Symantec Messaging Gateway) with SMTP id 85.65.24199.ED167C75; Wed, 31 Aug 2016 19:01:50 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u7VN1ntu031018; Wed, 31 Aug 2016 19:01:50 -0400
Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u7VN1mjG001054; Wed, 31 Aug 2016 19:01:49 -0400
From: Tom Yu 
To: 
References: 
Date: Wed, 31 Aug 2016 19:01:48 -0400
In-Reply-To:  (Tom Yu's message of "Wed, 31 Aug 2016 18:57:13 -0400")
Message-ID: 
Lines: 15
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPIsWRmVeSWpSXmKPExsUixG6nonsv8Xi4wfpZJhY79/WxWcz4M5HZ 4sPChywOzB5LlvxkCmCM4rJJSc3JLEst0rdL4MrY+OEBa0E7a8WUZe2MDYydLF2MnBwSAiYS zWsWM3YxcnEICbQxSRx5chHK2cgoseLsVyjnDaPE/903GEFa2ASkJY5f3sXUxcjBISIgLPF7 MtgkZgEPiSuN89lBwsICPhKLd3OAhIUEdCX2Hz/NCmKzCKhKzP5xlxnE5hTIkFg/p5sdxOYF qtl+aB1YDY8Ap0TTkt3MEHFBiZMzn0CN15K48e8l0wRG/llIUrOQpBYwMq1ilE3JrdLNTczM KU5N1i1OTszLSy3SNdPLzSzRS00p3cQIDjsX5R2ML/u8DzEKcDAq8fA6vDkWLsSaWFZcmXuI UZKDSUmUVy3ueLgQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEd65CUA53pTEyqrUonyYlDQHi5I4 b9eMA+FCAumJJanZqakFqUUwWRkODiUJ3kKQRsGi1PTUirTMnBKENBMHJ8hwHqDhuWDDiwsS c4sz0yHypxh1ORb8uL2WSYglLz8vVUqcNykeqEgApCijNA9uDjhdCDHue8UoDvSWMO9TkFE8 wFQDN+kV0BImoCUFdw6DLClJREhJNTCqVt4J1tZ9ka0kOb+87CBj0+HHh4X9zX87NLtf779U FFcvaPzknuCxxLzHc3K+xDPtZcjU3uT6a90Ow7K9t190TV07184nf9XhjCn/4m0yXmfofX6/ LN6G42RdsdhUARUd/eu5k94vW7XWScm1acbZ+K5z7edz3QTuBm+Jz2GdxzL93n8xzRIlluKM REMt5qLiRACDMgZb8gIAAA==
Archived-At: 
Cc: draft-ietf-6man-ipv6-mibs-obsolete.all@ietf.org, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-6man-ipv6-mibs-obsolete-01
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Aug 2016 23:01:53 -0000

Sorry, resending with the correct draft email alias.

Tom Yu  writes:

> I have reviewed this document as part of the security directorate's 
> ongoing effort to review all IETF documents being processed by the 
> IESG.  These comments were written primarily for the benefit of the 
> security area directors.  Document editors and WG chairs should treat 
> these comments just like any other last call comments.
>
> Summary: ready
>
> The security considerations section of this document seems reasonable.
> Republishing obsolete MIBs that are explicitly marked as obsolete in
> their bodies sounds like a good idea.