From weiler+secdir@watson.org Wed Aug 1 12:25:23 2012 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 B7BD111E80E5 for ; Wed, 1 Aug 2012 12:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dRYyXG1krfl for ; Wed, 1 Aug 2012 12:25:22 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 94D7A11E80D7 for ; Wed, 1 Aug 2012 12:25:22 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.5/8.14.5) with ESMTP id q71JPLb2044636 for ; Wed, 1 Aug 2012 15:25:21 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.5/8.14.5/Submit) with ESMTP id q71JPLGQ044633 for ; Wed, 1 Aug 2012 15:25:21 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Wed, 1 Aug 2012 15:25:21 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Wed, 01 Aug 2012 15:25:22 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 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: Wed, 01 Aug 2012 19:25:23 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Dave Cridland is next in the rotation. For telechat 2012-08-16 Reviewer LC end Draft Sandy Murphy T 2012-07-19 draft-ietf-ospf-hybrid-bcast-and-p2mp-03 For telechat 2012-08-30 Reviewer LC end Draft Alexey Melnikov T - draft-ietf-krb-wg-kdc-model-14 Sam Weiler T - draft-ietf-nea-pt-tls-06 For telechat 2012-09-13 Alexey Melnikov T 2012-08-13 draft-ietf-storm-iscsi-cons-06 Last calls and special requests: Rob Austein 2012-08-15 draft-ietf-opsawg-automated-network-configuration-04 Rob Austein 2012-06-26 draft-ietf-bmwg-2544-as-04 Richard Barnes 2012-08-15 draft-ietf-mptcp-multiaddressed-09 Dave Cridland 2012-06-28 draft-ietf-nfsv4-federated-fs-admin-11 Warren Kumari 2012-07-11 draft-ietf-oauth-v2-threatmodel-06 Tim Polk 2012-07-23 draft-ietf-appsawg-http-forwarded-06 Eric Rescorla 2012-07-25 draft-ietf-websec-strict-transport-sec-11 Vincent Roca 2012-07-23 draft-ietf-xrblock-rtcp-xr-pdv-03 Joe Salowey 2012-08-09 draft-vegoda-cotton-rfc5735bis-02 Ondrej Sury 2012-08-13 draft-sparks-genarea-mailarch-05 Tina TSOU 2012-08-02 draft-ietf-avtcore-monarch-17 Carl Wallace 2012-08-17 draft-ietf-ccamp-rfc5787bis-05 Brian Weis 2012-08-06 draft-ietf-abfab-usecases-03 Klaas Wierenga 2012-08-15 draft-ietf-ccamp-dpm-06 Nico Williams - draft-ietf-httpbis-p5-range-20 Nico Williams 2012-08-14 draft-ietf-ippm-testplan-rfc2679-02 Tom Yu - draft-ietf-httpbis-p6-cache-20 Tom Yu 2012-08-22 draft-ietf-manet-olsrv2-15 Glen Zorn - draft-ietf-httpbis-p7-auth-20 Glen Zorn 2012-06-27 draft-hoffman-tao4677bis-16 Glen Zorn 2012-08-14 draft-ietf-mptcp-api-05 From new-work-bounces@ietf.org Tue Jul 31 13:15:01 2012 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD8621F857E; Tue, 31 Jul 2012 13:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1343765701; bh=/AkI995NmHso90G8GYn04yfEF6Gtpv8HavJoP52fLLY=; h=Date:To:MIME-Version:From:Message-ID:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=Ln6cAFU0aP4BvUQEWgaofbivS2IkVWWjg1wOnWwxki3kOH0lteN81PnxauPV1UIav JrADQmVUNu/7m1xCsCFXWsNO/XyOqaKJoq8fypGSzgLJTX/2AhWIWRQu4zLgagVL2M aG0DYVN9RtZxvxJAZVc5Gmr5We7B7LR+8RT5A9/U= 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 52A8B21F8514 for ; Tue, 31 Jul 2012 13:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.507 X-Spam-Level: X-Spam-Status: No, score=-10.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mlef-UNaz05g for ; Tue, 31 Jul 2012 13:14:58 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id C587A21F84E1 for ; Tue, 31 Jul 2012 13:14:58 -0700 (PDT) Received: from bleuazur.com ([88.173.33.195] helo=sith-wifi.sophia.w3.org) by jay.w3.org with esmtpsa (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.69) (envelope-from ) id 1SwIqH-0003Xz-H2 for new-work@ietf.org; Tue, 31 Jul 2012 16:14:57 -0400 Date: Tue, 31 Jul 2012 22:14:56 +0200 To: "new-work@ietf.org" MIME-Version: 1.0 From: "Coralie Mercier" Organization: W3C Message-ID: User-Agent: Opera Mail/12.00 (MacIntel) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Wed, 01 Aug 2012 13:34:52 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Audio Working Group (until 2012-08-31) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 20:15:01 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Rich Web Client Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the Audio Working Group: http://www.w3.org/2011/audio/charter/2012/charter-proposed.html 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 2012-08-31 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 [2], 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 Doug Schepers, Team Contact . Thank you, Coralie Mercier, W3C Communications [0] http://www.w3.org/2006/rwc/Activity.html [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Coralie Mercier - W3C Communications Team - http://www.w3.org W3C/ERCIM - B219 - 2004, rte des lucioles - 06410 Biot - FR mailto:coralie@w3.org +33492387590 http://www.w3.org/People/CMercier/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Wed Aug 1 13:31:23 2012 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A24911E8173; Wed, 1 Aug 2012 13:31:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1343853083; bh=Px4+ygYt+0DpHp8ZYdRBzHLXTYBswBAOwhkobThLF1A=; h=To:Date:MIME-Version:From:Message-ID:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=CSg5P4psEIPL8DNQETg1J0YwF4uShfFI2O2ujtyLmE9ODR6G49paOvTCxY58zNopw c8Y45YOmZxLFZbW68zlFFHHUb3RArSrbBivOpqUQU1h69AK8Mth9XY98a93s0+deLC 97y83PFp1kgVbOkt7q6yO2kYyA+3D5Qt9VqJaG84= 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 C41D911E8172 for ; Wed, 1 Aug 2012 13:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.522 X-Spam-Level: X-Spam-Status: No, score=-10.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMquNqiqYR07 for ; Wed, 1 Aug 2012 13:31:22 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 37E5111E8173 for ; Wed, 1 Aug 2012 13:31:22 -0700 (PDT) Received: from bleuazur.com ([88.173.33.195] helo=sith.local) by jay.w3.org with esmtpsa (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.69) (envelope-from ) id 1SwfZh-0003ll-AK for new-work@ietf.org; Wed, 01 Aug 2012 16:31:21 -0400 To: "new-work@ietf.org" Date: Wed, 01 Aug 2012 22:31:20 +0200 MIME-Version: 1.0 From: "Coralie Mercier" Organization: W3C Message-ID: User-Agent: Opera Mail/12.00 (MacIntel) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Wed, 01 Aug 2012 13:34:52 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: MultilingualWeb-LT Working Group (until 2012-08-31) 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, 01 Aug 2012 20:31:23 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Internationalization Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the MultilingualWeb-LT Working Group: http://www.w3.org/2012/07/mlw-lt-charter-update.html 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 2012-08-31 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 [2], 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 Felix Sasaki, Working Group co-chair and staff contact . Thank you, Coralie Mercier, W3C Communications [0] http://www.w3.org/International/ [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Coralie Mercier - W3C Communications Team - http://www.w3.org W3C/ERCIM - B219 - 2004, rte des lucioles - 06410 Biot - FR mailto:coralie@w3.org +33492387590 http://www.w3.org/People/CMercier/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From turners@ieca.com Wed Aug 1 14:17:43 2012 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 4769111E8322 for ; Wed, 1 Aug 2012 14:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.762 X-Spam-Level: X-Spam-Status: No, score=-100.762 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U85-wFZ5P5mp for ; Wed, 1 Aug 2012 14:17:42 -0700 (PDT) Received: from gateway12.websitewelcome.com (gateway12.websitewelcome.com [69.93.35.2]) by ietfa.amsl.com (Postfix) with ESMTP id B931E11E8295 for ; Wed, 1 Aug 2012 14:17:21 -0700 (PDT) Received: by gateway12.websitewelcome.com (Postfix, from userid 5007) id 059E77D4D5A98; Wed, 1 Aug 2012 16:17:22 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway12.websitewelcome.com (Postfix) with ESMTP id DCE217D4D5A39 for ; Wed, 1 Aug 2012 16:17:21 -0500 (CDT) Received: from [130.129.37.148] (port=50873 helo=dhcp-2594.meeting.ietf.org) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SwgIC-0000sc-QC for secdir@ietf.org; Wed, 01 Aug 2012 16:17:20 -0500 Message-ID: <50199CE0.4040002@ieca.com> Date: Wed, 01 Aug 2012 14:17:20 -0700 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: secdir@ietf.org References: <50199A8F.6070007@ieca.com> In-Reply-To: <50199A8F.6070007@ieca.com> X-Forwarded-Message-Id: <50199A8F.6070007@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (dhcp-2594.meeting.ietf.org) [130.129.37.148]:50873 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [secdir] Fwd: wg summary reminder X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 21:17:44 -0000 In case you're filtering sec-chairs@tools.ietf.org. spt -------- Original Message -------- Subject: wg summary reminder Please send a summary of your WG sessions to saag. Otherwise, we'll make you get up at the mic and chat about the session. spt From vincent.roca@inria.fr Wed Aug 1 14:31:47 2012 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 4C38711E8183; Wed, 1 Aug 2012 14:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.248 X-Spam-Level: X-Spam-Status: No, score=-110.248 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvAOdOmPcS4w; Wed, 1 Aug 2012 14:31:46 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfa.amsl.com (Postfix) with ESMTP id 511B011E817B; Wed, 1 Aug 2012 14:31:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,696,1336341600"; d="scan'208";a="168833452" Received: from ral054r.vpn.inria.fr ([128.93.178.54]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 01 Aug 2012 23:31:43 +0200 From: Vincent Roca Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 1 Aug 2012 23:31:44 +0200 Message-Id: <47091871-198D-4C5C-953A-919696F8CAFC@inria.fr> To: The IESG , secdir@ietf.org, draft-ietf-xrblock-rtcp-xr-pdv.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [secdir] Secdir review of draft-ietf-xrblock-rtcp-xr-pdv-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 21:31:47 -0000 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 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 authors explain this document introduces no new security considerations beyond those described in [RFC3611]. I agree there is no privacy risk, but a question I'd like the authors to discuss a little bit concerns the case where an attacker sends forged RTCP XR reports, with erroneous Packet Delay Variation values (e.g. the attacker may pretend the PDV are much smaller than the reality). I assume this may result in back playout buffer setups, isn't it? This looks like a cool way to create a DoS. Is the PDV used for other purposes, like imminent congestion detection? In that case there could be other incentives for an attacker to fake XR packets, with possible additional damages. I think a paragraph on these risks should be added. Cheers, Vincent From new-work-bounces@ietf.org Wed Aug 1 16:01:21 2012 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8183111E81A2; Wed, 1 Aug 2012 16:01:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1343862081; bh=ktWcbLNSqbB6OWDM7SfWYXMZ/xtsIAlXkX5sM1JwDlY=; h=Date:To:MIME-Version:From:Message-ID:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=kJURuIy30FUmAHnttw6Uk1ZVepBiU/ubRZRjJeAGWJjzIUjnwG3QsRX1nMmp3msbb BMjzT9suFCUEl2UQi+GGuuEbRU8PQpqCMADsGO1jIlp5EUZtauSQ/bKfZNzFotOGAD oxvI0ITYzDrYnqE82faXHLsJPAKXrd8NWJf1xWAA= 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 D487911E81A2 for ; Wed, 1 Aug 2012 16:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.533 X-Spam-Level: X-Spam-Status: No, score=-10.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQjAEi6Xhk2T for ; Wed, 1 Aug 2012 16:01:19 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6D911E8191 for ; Wed, 1 Aug 2012 16:01:18 -0700 (PDT) Received: from bleuazur.com ([88.173.33.195] helo=sith.local) by jay.w3.org with esmtpsa (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.69) (envelope-from ) id 1Swhun-0005JA-UR for new-work@ietf.org; Wed, 01 Aug 2012 19:01:18 -0400 Date: Thu, 02 Aug 2012 01:01:17 +0200 To: "new-work@ietf.org" MIME-Version: 1.0 From: "Coralie Mercier" Organization: W3C Message-ID: User-Agent: Opera Mail/12.00 (MacIntel) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Wed, 01 Aug 2012 16:02:23 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: RDFa Working Group Charter (until 2012-08-31) 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, 01 Aug 2012 23:01:22 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Semantic Web Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the RDFa Working Group Charter: http://www.w3.org/2012/06/rdfwa-wg-charter.html 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 2012-08-31 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 [2], 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 Ivan Herman, Semantic Web Activity Lead, and Team Contact . Thank you, Coralie Mercier, W3C Communications [0] https://www.w3.org/2001/sw/ [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Coralie Mercier - W3C Communications Team - http://www.w3.org W3C/ERCIM - B219 - 2004, rte des lucioles - 06410 Biot - FR mailto:coralie@w3.org +33492387590 http://www.w3.org/People/CMercier/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Thu Aug 2 00:42:45 2012 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6219721F8DB5; Thu, 2 Aug 2012 00:42:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1343893365; bh=wbiG2Xs6n/kBtELRgIMPmnv0nl+mARxGlTMZBgp0uFA=; h=From:To:Date:Message-ID:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Sender; b=dbkUvHw0j4K8Rm9tscXWbU5jn5NHrapyZYLqAOsvuZlj/GojrrUrdM/CS3XnqXJtn S+OwZ0XXB2mgCHFhDr9umh9LJuNB38W4EozNqSYopkLpGa6GokaWs6TPDdfVoNtsl4 VN4DBK2aqWJhrYi7PJqWk8DSpnoDkQoIcD/qxD6g= 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 2D34721F8DB6 for ; Thu, 2 Aug 2012 00:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcaWLcKI1CYP for ; Thu, 2 Aug 2012 00:42:40 -0700 (PDT) Received: from mora.svc.unicc.org (mora.svc.unicc.org [193.194.138.76]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFB121F8DB1 for ; Thu, 2 Aug 2012 00:42:38 -0700 (PDT) Received: from chicha.svc.unicc.org (chicha.svc.unicc.org [192.168.202.41]) by mora.svc.unicc.org (Switch-3.1.7/Switch-3.1.7) with ESMTP id q72BGWaF022253 for ; Thu, 2 Aug 2012 13:16:32 +0200 Received: from judas.svc.unicc.org (localhost.localdomain [127.0.0.1]) by chicha.svc.unicc.org (Switch-3.1.7/Switch-3.1.7) with ESMTP id q727gb93026978 for ; Thu, 2 Aug 2012 09:42:37 +0200 Received: from mailweb.itu.int ([10.81.6.61]) by judas.svc.unicc.org (Switch-3.1.7/Switch-3.1.7) with ESMTP id q727gbCZ022491 for ; Thu, 2 Aug 2012 09:42:37 +0200 Received: from TUCHM07.TUECSP.UNICC.ORG ([169.254.4.209]) by TUCHM02.TUECSP.UNICC.ORG ([169.254.2.104]) with mapi id 14.02.0298.004; Thu, 2 Aug 2012 07:42:38 +0000 From: "Scholl, Reinhard" To: "new-work@ietf.org" Thread-Topic: Proposed ITU-T TSB Director adhoc Group on Standards Education - comments on draft ToR by Wed 15 Aug 2012 Thread-Index: Ac1wgS0pC/qkSDLKQLiTISI696q2Zg== Date: Thu, 2 Aug 2012 07:42:36 +0000 Message-ID: <29FF8A687B739640BEE061640C40078D4EF5313F@TUCHM07.TUECSP.UNICC.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.81.64.161] MIME-Version: 1.0 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: multipart/mixed; boundary="===============3787327265800872924==" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Thu, 02 Aug 2012 06:23:14 -0700 Subject: [secdir] [new-work] Proposed ITU-T TSB Director adhoc Group on Standards Education - comments on draft ToR by Wed 15 Aug 2012 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 07:42:45 -0000 --===============3787327265800872924== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_29FF8A687B739640BEE061640C40078D4EF5313FTUCHM07TUECSPUN_" --_000_29FF8A687B739640BEE061640C40078D4EF5313FTUCHM07TUECSPUN_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The ITU-T Telecommunication Standardization Advisory Group (TSAG) agreed to= set up the TSB Director's Ad Hoc Group on Standards Education that shall be open to members and non-me= mbers. Below (and hyperlinked) please find the group's draft Terms of Reference. The ToR can be commented on unt= il Wednesday 15 August 2012 (please send comments to tsbtsag@itu.int). Best regards Reinhard Scholl =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Reinhard Scholl Deputy to the Director International Telecommunication Union - Telecommunication Standardization Bureau (ITU-T TSB) Place des Nations CH-1211 Geneva 20 Switzerland reinhard.scholl@itu.int office: +41 22 730 5860 mobile: +41 79 249 4846 www.itu.int/ITU-T ITU-T e-FLASH: send "subscribe" in subject to ITU-T_e-flash@itu.int Draft Terms of Reference, Composition and Working Methods of the TSB Director's Ad Hoc Group on Standards Education (30 July 2012) Background The need to address international standardization in ICT in academic curric= ula is vital for the students of today are the experts that will drive the = standardization processes of tomorrow. In this context, "standards education" is related not to technology topics,= but rather to the activities that aim at providing formal information to s= tudents at undergraduate and graduate levels on all aspects related to inte= rnational standards, standards development activities, standard strategy pl= anning, and business case studies using standards. This information include= s inter alia importance of standardization, strategies for standardization,= case studies, etc. Given the scale of the task, it is important to include= ITU-T experts in standardization, representatives of academia, as well as = other standards development organizations that are also interested in stand= ards education. 1. Terms of reference a. Perform a "gap analysis" on ICT standardization education in academi= c curricula in Universities. b. Gather information on standards education programs in relevant extern= al groups such as ISO and IEC in the context of WSC, SDOs, the IEEE, the In= stitute of Electronics, Information and Communication Engineers (IEICE), and academic-led organizations such as t= he International Cooperation for Standards Education (ICES) and the European Academy for Standardization (EURAS). c. Develop one or more deliverables to detail academic curricula for us= e by academia in standards education. d. Identify strategies to facilitate adoption of credit-eligible courses= in undergraduate and graduate programmes. e. Contribute to a programme for a tutorial on standards education to be= held during Kaleidoscope events, WSC events, etc. f. Make proposals on webinars, seminars and workshops on subjects of c= ommon interest to ITU and Academia. g. Encourage other research and academic institutions to join as ITU mem= bers. 2. Composition The group shall be open to the members and non-members and will work in an = open, inclusive and transparent manner. 3. Working Methods The Chair of the meeting is the TSB Director, or in his absence a person ap= pointed by him. The Group will decide its meeting schedule and works throug= h electronic means as far as possible. --_000_29FF8A687B739640BEE061640C40078D4EF5313FTUCHM07TUECSPUN_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The ITU-T Telecommunication Standardization Advisory = Group (TSAG) agreed to set up the TSB Director’s Ad Hoc Group on Standards Edu= cation that shall be open to members and non-members.

Below (and hyperlinked) please find the= group’s draft Terms of Refe= rence. The ToR can be commented on until Wednesday 15 August 201= 2 (please send comments to tsbtsag@itu.int).

 

Best regards

Reinhard Scholl

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Reinhard = Scholl
Deputy to the Director
International Telecommunication Union -
Telecommunication Standardization Bureau (ITU-T TSB)
Place des Nations
CH-1211 Geneva 20
Switzerland
reinhard.scholl@itu.int
office: +41 22 730 5860
mobile: +41 79 249 4846
www.itu.int/ITU-T
ITU-T e-FLASH: send "subscribe" in subject to ITU-T_e-flas= h@itu.int

 <= /p>

 

Draft Terms of Referenc= e, Composition and Working Methods of the
TSB Director’s Ad Hoc Group on Standards Education
(30 July 2012)

Background

The need to address international standardization in ICT in academic curric= ula is vital for the students of today are the experts that will drive the = standardization processes of tomorrow.

In this context, "standards education" is related not to technolo= gy topics, but rather to the activities that aim at providing formal inform= ation to students at undergraduate and graduate levels on all aspects relat= ed to international standards, standards development activities, standard strategy planning, and business case studies using st= andards. This information includes inter alia importance of standardization= , strategies for standardization, case studies, etc. Given the scale of the= task, it is important to include ITU-T experts in standardization, representatives of academia, as well as = other standards development organizations that are also interested in stand= ards education.

1.    Terms of reference

a.     Perform= a “gap analysis” on ICT standardization education in academic = curricula in Universities.

b.    Gather = information on standards education programs in relevant external groups suc= h as ISO and IEC in the context of WSC, SDOs, the IEEE, the Institute of Electronics, Information and Communication Engineers (IEICE= ), and academic-led organizations such as the International Cooperation for Standards Education (ICES) and the European Academy for S= tandardization (EURAS).

c.     Develop= one or more deliverables to detail academic curricula for use by academia = in standards education.

d.    Identif= y strategies to facilitate adoption of credit-eligible courses in undergrad= uate and graduate programmes.

e.    Contrib= ute to a programme for a tutorial on standards education to be held during = Kaleidoscope events, WSC events, etc.

f.    &nbs= p; Make pr= oposals on webinars, seminars and workshops on subjects of common interest = to ITU and Academia.

g.    Encoura= ge other research and academic institutions to join as ITU members.

2.    Composition

The group shall be open to the members and non-membe= rs and will work in an open, inclusive and transparent manner.

3.    Working Methods

The Chair of the meeting is the TSB Director, or in = his absence a person appointed by him. The Group will decide its meeting sc= hedule and works through electronic means as far as possible.

 

 

--_000_29FF8A687B739640BEE061640C40078D4EF5313FTUCHM07TUECSPUN_-- --===============3787327265800872924== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work --===============3787327265800872924==-- From rbarnes@bbn.com Thu Aug 2 11:14:46 2012 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 F329011E8216 for ; Thu, 2 Aug 2012 11:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.604 X-Spam-Level: X-Spam-Status: No, score=-106.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xP6dwcO5UvDu for ; Thu, 2 Aug 2012 11:14:45 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6661311E8215 for ; Thu, 2 Aug 2012 11:14:45 -0700 (PDT) Received: from [128.89.253.75] (port=61365) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Swzuq-0004dS-PF; Thu, 02 Aug 2012 14:14:32 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Thu, 2 Aug 2012 11:14:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <84298679-A1F2-4B9A-96ED-EE89CB010B23@bbn.com> References: To: secdir-secretary@mit.edu X-Mailer: Apple Mail (2.1278) Cc: secdir@ietf.org Subject: Re: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 18:14:46 -0000 I'm going to be on vacation until 10 Aug. Would someone mind picking up = my review this week? Glad to do an extra one later in exchange. Thanks, --Richard On Aug 1, 2012, at 12:25 PM, Samuel Weiler wrote: > Review instructions and related resources are at: > http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >=20 > Dave Cridland is next in the rotation. >=20 > For telechat 2012-08-16 >=20 > Reviewer LC end Draft > Sandy Murphy T 2012-07-19 = draft-ietf-ospf-hybrid-bcast-and-p2mp-03 >=20 >=20 > For telechat 2012-08-30 >=20 > Reviewer LC end Draft > Alexey Melnikov T - draft-ietf-krb-wg-kdc-model-14 > Sam Weiler T - draft-ietf-nea-pt-tls-06 >=20 >=20 > For telechat 2012-09-13 >=20 > Alexey Melnikov T 2012-08-13 draft-ietf-storm-iscsi-cons-06 >=20 >=20 > Last calls and special requests: >=20 > Rob Austein 2012-08-15 = draft-ietf-opsawg-automated-network-configuration-04 > Rob Austein 2012-06-26 draft-ietf-bmwg-2544-as-04 > Richard Barnes 2012-08-15 draft-ietf-mptcp-multiaddressed-09 > Dave Cridland 2012-06-28 = draft-ietf-nfsv4-federated-fs-admin-11 > Warren Kumari 2012-07-11 draft-ietf-oauth-v2-threatmodel-06 > Tim Polk 2012-07-23 = draft-ietf-appsawg-http-forwarded-06 > Eric Rescorla 2012-07-25 = draft-ietf-websec-strict-transport-sec-11 > Vincent Roca 2012-07-23 draft-ietf-xrblock-rtcp-xr-pdv-03 > Joe Salowey 2012-08-09 draft-vegoda-cotton-rfc5735bis-02 > Ondrej Sury 2012-08-13 draft-sparks-genarea-mailarch-05 > Tina TSOU 2012-08-02 draft-ietf-avtcore-monarch-17 > Carl Wallace 2012-08-17 draft-ietf-ccamp-rfc5787bis-05 > Brian Weis 2012-08-06 draft-ietf-abfab-usecases-03 > Klaas Wierenga 2012-08-15 draft-ietf-ccamp-dpm-06 > Nico Williams - draft-ietf-httpbis-p5-range-20 > Nico Williams 2012-08-14 = draft-ietf-ippm-testplan-rfc2679-02 > Tom Yu - draft-ietf-httpbis-p6-cache-20 > Tom Yu 2012-08-22 draft-ietf-manet-olsrv2-15 > Glen Zorn - draft-ietf-httpbis-p7-auth-20 > Glen Zorn 2012-06-27 draft-hoffman-tao4677bis-16 > Glen Zorn 2012-08-14 draft-ietf-mptcp-api-05 >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From alexey.melnikov@isode.com Thu Aug 2 11:23:53 2012 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 BD78C21E8122 for ; Thu, 2 Aug 2012 11:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.12 X-Spam-Level: X-Spam-Status: No, score=-102.12 tagged_above=-999 required=5 tests=[AWL=0.479, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bu2R44660k7Z for ; Thu, 2 Aug 2012 11:23:53 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id F411C21E8120 for ; Thu, 2 Aug 2012 11:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1343931910; d=isode.com; s=selector; i=@isode.com; bh=02uzq8EO1pBy2WxSrAnpIiS12MOrhGRg6SM3+HgbGyU=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=sLlEo2rmyIaGLNMdc0Y/WFFlELj9Fz5+kNSObdJY9LovJg/pAUouRBB7XbJXztUsTa7DIh rO1o7KXRFvNUjzfF6HN//U4pR1AwY9QtxqHjAnToql3zboUYQEq3eQlnU5r9dVIfQMYJ8x bVt1YDsIFr6of3Mtx8Ueq2HuCMp3ohg=; Received: from [130.129.23.230] (dhcp-17e6.meeting.ietf.org [130.129.23.230]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 2 Aug 2012 19:25:09 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <501AC5C9.3050600@isode.com> Date: Thu, 02 Aug 2012 11:24:09 -0700 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: "Richard L. Barnes" , secdir-secretary@mit.edu References: <84298679-A1F2-4B9A-96ED-EE89CB010B23@bbn.com> In-Reply-To: <84298679-A1F2-4B9A-96ED-EE89CB010B23@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: secdir@ietf.org Subject: Re: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 18:23:53 -0000 On 02/08/2012 11:14, Richard L. Barnes wrote: > I'm going to be on vacation until 10 Aug. Would someone mind picking up my review this week? Glad to do an extra one later in exchange. Ok, assign this one to me: I will ask for a favour later ;-). > Richard Barnes 2012-08-15 draft-ietf-mptcp-multiaddressed-09 From Tina.Tsou.Zouting@huawei.com Fri Aug 3 10:43:14 2012 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 CED9521F8DE8; Fri, 3 Aug 2012 10:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.983 X-Spam-Level: X-Spam-Status: No, score=-5.983 tagged_above=-999 required=5 tests=[AWL=0.616, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqc3XU1ehEiz; Fri, 3 Aug 2012 10:43:13 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0539921F8DE7; Fri, 3 Aug 2012 10:43:12 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIQ99324; Fri, 03 Aug 2012 09:43:12 -0800 (PST) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 3 Aug 2012 10:41:26 -0700 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.5]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Fri, 3 Aug 2012 10:41:20 -0700 From: Tina TSOU To: The IESG , "secdir@ietf.org" , "draft-ietf-avtcore-monarch@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-avtcore-monarch-17 Thread-Index: AQHNcZ8wwnHq2FsbBUKLVhmzYnYJXg== Date: Fri, 3 Aug 2012 17:41:20 +0000 Message-ID: References: <47091871-198D-4C5C-953A-919696F8CAFC@inria.fr> In-Reply-To: <47091871-198D-4C5C-953A-919696F8CAFC@inria.fr> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [secdir] Secdir review of draft-ietf-avtcore-monarch-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 17:43:14 -0000 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 any= other last call comments. Draft-ietf-avtcore-monarch-17 as a whole provides useful advice.=20 There are a number of editorial nits that will be provided to the authors i= n a separate E-mail. Unfortunately, the Security Considerations section fails to appreciate both= the more nuanced view and the contradiction exhibited by the same section = of RFC 3611, to which it refers. On the one hand, the measurements reported= in XR blocks could be sensitive and one might wish to provide them with co= nfidentiality. On the other hand, intermediate parties may have legitimate = reasons to view the measurements, so that end-to-end encryption is not alwa= ys desirable. It would be helpful for this document to discuss the trust models that migh= t be encountered in operation, and how confidentiality and authorized usage= could co-exist within these models. Of course, it may be legitimate to con= clude that under some circumstances such coexistence may be impossible, and= local policy may therefore be either to suppress the measurements or accep= t the consequences of their disclosure. Tina From bew@cisco.com Mon Aug 6 18:23:08 2012 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 376AB21F86BE; Mon, 6 Aug 2012 18:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vz78n7yWpItI; Mon, 6 Aug 2012 18:23:07 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECAD21F868A; Mon, 6 Aug 2012 18:23:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=2459; q=dns/txt; s=iport; t=1344302587; x=1345512187; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=DqArR7PeDv7TRXSPasFUv3jm+evbr/wQeebxrsBzasM=; b=YzBddOhfyfhAWq8XtrjwcyF7EkcQdAFgNEul80G3+DiAIcTu7Qq0TnHH o+HlU9G+Xi7eIXZ6CW4brVd4vbXYK1pA1ERoIoGTaREhPc8ZNLs5slUHA cZxHZIcsn/pFa/VH1aaDmHwNUPwPmmOHN1kVMGqmyHP6NQaHYFduwoBsY 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHltIFCrRDoG/2dsb2JhbAA8CblRgQeCOQEnPy19FAE0h2oBmyugOotbhXxgA4hNjHyOJoFmgn+BOCM X-IronPort-AV: E=Sophos;i="4.77,723,1336348800"; d="scan'208";a="51708169" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 07 Aug 2012 01:23:07 +0000 Received: from printer-xx-6080ee.cisco.com (printer-xx-6080ee.cisco.com [128.107.151.17]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q771N6Cq014351; Tue, 7 Aug 2012 01:23:06 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Aug 2012 18:23:27 -0700 Message-Id: To: secdir@ietf.org, The IESG Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Cc: draft-ietf-abfab-usecases.all@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-abfab-usecases-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 01:23:08 -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 several scenarios in which federated access = could be useful to non-web protocols. The use cases include federation = between supplier/consumers of resources (e.g., cloud services, high = performance computing, and grid), the sharing of content or resources = between an organization and selected outsiders (e.g., databases and = directories, and printing), and cooperation between multiple = organizations (e.g., smart objects). Each use case discusses the = movement from non-federated identity to the use of an ABFAB = architecture. The security considerations section states that necessary security = considerations will be documented as part of subsequent protocol = specifications. But typically there are higher level security = considerations to use cases unrelated to the details of protocols. In = this case there are likely effects of federation on the various actors = within the case entities. I note above that there are several classes of = use cases, each of which has a different trust model and set of actors = either providing or validating credentials. If converting to the ABFAB = architecture in any of the use cases results in a change of security = considerations (positive or negative) from the pre-existing = non-federated case then it would be helpful to note this to readers = considering adopting one of the ABFAB use cases. For example, when in federation between supplier/consumers of resources = are there changes in the trust model when a supplier = re-designs/re-factors their environment to use federation? Are there = security considerations for a consumer moving to federated identities = from directly supplying IDs/authentication material to previously = non-federated services? This sort of characterization would be valuable = in understanding the effects of transitioning to federation. I'm not = suggesting a full blown threat analysis (although that would be useful!) = but rather a summary of how federation affects the security of both a = provider and consumer of a resource in the various use cases. Brian= From weiler+secdir@watson.org Fri Aug 10 11:36:16 2012 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 E63EC21F8526 for ; Fri, 10 Aug 2012 11:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rs017KZGQmfh for ; Fri, 10 Aug 2012 11:36:15 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF2621F8507 for ; Fri, 10 Aug 2012 11:36:15 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.5/8.14.5) with ESMTP id q7AIaEo7088948 for ; Fri, 10 Aug 2012 14:36:14 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.5/8.14.5/Submit) with ESMTP id q7AIaDVc088940 for ; Fri, 10 Aug 2012 14:36:13 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 10 Aug 2012 14:36:13 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Fri, 10 Aug 2012 14:36:14 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 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, 10 Aug 2012 18:36:16 -0000 For those who may have missed the announcement in Vancouver, I will soon be stepping down as secdir secretary. Tero Kivinen has agreed to step into the role. For the moment, we are both doing secretarial things, so please make use of the secdir-secretary@mit.edu address to reach us. -- Sam Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Paul Hoffman is next in the rotation. For telechat 2012-08-16 Reviewer LC end Draft Derek Atkins TR2012-06-28 draft-ietf-bliss-shared-appearances-13 Rob Austein T 2012-08-15 draft-ietf-opsawg-automated-network-configuration-04 Sandy Murphy T 2012-07-19 draft-ietf-ospf-hybrid-bcast-and-p2mp-03 For telechat 2012-08-30 Warren Kumari T 2012-07-11 draft-ietf-oauth-v2-threatmodel-06 Alexey Melnikov T - draft-ietf-krb-wg-kdc-model-14 Sam Weiler T - draft-ietf-nea-pt-tls-07 Klaas Wierenga T 2012-08-15 draft-ietf-ccamp-dpm-06 For telechat 2012-09-13 Alexey Melnikov T 2012-08-13 draft-ietf-storm-iscsi-cons-06 Last calls and special requests: Rob Austein 2012-06-26 draft-ietf-bmwg-2544-as-04 Dave Cridland 2012-06-28 draft-ietf-nfsv4-federated-fs-admin-11 Dave Cridland 2012-08-23 draft-ietf-armd-problem-statement-03 Alan DeKok 2012-08-23 draft-ietf-mmusic-media-loopback-22 Donald Eastlake - draft-ietf-pce-hierarchy-fwk-04 Shawn Emery 2012-08-24 draft-ietf-dnsop-rfc4641bis-12 Tobias Gondrom 2012-08-22 draft-ietf-idr-as0-05 Phillip Hallam-Baker 2012-09-03 draft-kumaki-murai-l3vpn-rsvp-te-06 Steve Hanna 2012-08-20 draft-ietf-pwe3-mpls-eth-oam-iwk-06 Dan Harkins - draft-ietf-drinks-spp-framework-02 Sam Hartman - draft-ietf-drinks-spp-protocol-over-soap-02 Alexey Melnikov 2012-08-15 draft-ietf-mptcp-multiaddressed-09 Tim Polk 2012-07-23 draft-ietf-appsawg-http-forwarded-06 Eric Rescorla 2012-07-25 draft-ietf-websec-strict-transport-sec-11 Joe Salowey 2012-08-09 draft-vegoda-cotton-rfc5735bis-02 Ondrej Sury 2012-08-13 draft-sparks-genarea-mailarch-05 Carl Wallace 2012-08-17 draft-ietf-ccamp-rfc5787bis-05 Nico Williams - draft-ietf-httpbis-p5-range-20 Nico Williams 2012-08-14 draft-ietf-ippm-testplan-rfc2679-02 Tom Yu - draft-ietf-httpbis-p6-cache-20 Tom Yu 2012-08-22 draft-ietf-manet-olsrv2-15 Glen Zorn - draft-ietf-httpbis-p7-auth-20 Glen Zorn 2012-06-27 draft-hoffman-tao4677bis-16 Glen Zorn 2012-08-14 draft-ietf-mptcp-api-05 From jsalowey@cisco.com Tue Aug 14 09:20:04 2012 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 87AFF21F86EE; Tue, 14 Aug 2012 09:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.521 X-Spam-Level: X-Spam-Status: No, score=-110.521 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNeRGB9boGO5; Tue, 14 Aug 2012 09:20:03 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B8C4021F86EC; Tue, 14 Aug 2012 09:20:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=493; q=dns/txt; s=iport; t=1344961203; x=1346170803; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Qi/SVNWWd5eYVEUxYbL8VXdSZ68XXcEpdBVzAnC985I=; b=NKNx/tpM0l/QV8zGGs5y0U5sO3IlG6v5ZRhsg6my9bPecU6z+oUy+W/i 50w5Y7yMRLA6z8DPu3bq98HFeeZWguefsVGgcw5Ao9LdFIMWwQ15J9Uey ubR3mvaSgCcmaBNY7T6TUAqLpuR2h4kqbhfapl30w2g0eygVuL+o/Uyg/ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKB5KlCtJV2a/2dsb2JhbABFuheBB4InEgEnUQE+QicEATSHa5g0oH2QVmADlUuOKoFmgl8 X-IronPort-AV: E=Sophos;i="4.77,766,1336348800"; d="scan'208";a="111275631" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 14 Aug 2012 16:20:03 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q7EGK2MD024072 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Aug 2012 16:20:02 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0298.004; Tue, 14 Aug 2012 11:20:01 -0500 From: "Joseph Salowey (jsalowey)" To: The IESG , "secdir@ietf.org" , "draft-vegoda-cotton-rfc5735bis.all@tools.ietf.org" Thread-Topic: Secdir review of draft-vegoda-cotton-rfc5735bis-02 Thread-Index: AQHNejinJ6NvvLUA/UO+WuNpel8VMw== Date: Tue, 14 Aug 2012 16:20:01 +0000 Message-ID: <9AE81B61-5E30-47A4-83D1-3903B1B231D1@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.153] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19112.005 x-tm-as-result: No--25.669900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] Secdir review of draft-vegoda-cotton-rfc5735bis-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 16:20:04 -0000 I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. This document describes the IPv4 address spaces reserved by IANA. I believ= e the document has an adequate security considerations section.=20 From klaas@cisco.com Wed Aug 15 04:56:16 2012 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 3124C21F853B; Wed, 15 Aug 2012 04:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1sSsx4V+vmuY; Wed, 15 Aug 2012 04:56:15 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7B11621F853A; Wed, 15 Aug 2012 04:56:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=3064; q=dns/txt; s=iport; t=1345031775; x=1346241375; h=from:content-transfer-encoding:subject:message-id:date: to:mime-version; bh=Q+8KZ+r1zZfmR18dLvZk1DUZ+49K2s/tlFgSPndQZIE=; b=hRdFcLx8e5pxT1CT1tcnTZTHYIxjzZmbhUVbSknpuxJqEb8BHgnf2rXX 9bl6o2Nbi8o5TkG6+sTeHHIEVx7YqDY8ydys9+ZYd/Dg12aLWFUfEgLI+ 8VLBgvDjHal6WKhCRAEbAYLWYM8pGdi75O0QMSTjHMAp3b6TWA4zObzWR w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAL+NK1CtJXG9/2dsb2JhbABFuh2BB4I5AYIkATSHa5kdoFaQfWADlUuOKoFmgmE X-IronPort-AV: E=Sophos;i="4.77,772,1336348800"; d="scan'208";a="111778371" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 15 Aug 2012 11:56:15 +0000 Received: from rtp-vpn5-1828.cisco.com (rtp-vpn5-1828.cisco.com [10.82.239.43]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7FBuCxg014292 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Aug 2012 11:56:14 GMT From: Klaas Wierenga Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <21E590DF-6035-4790-9171-9B46F0A849E7@cisco.com> Date: Wed, 15 Aug 2012 13:56:12 +0200 To: The IESG , secdir@ietf.org, draft-ietf-ccamp-dpm.all@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) X-Mailer: Apple Mail (2.1485) Subject: [secdir] Secdir review of draft-ietf-ccamp-dpm-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 11:56:16 -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 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 a set of path delay metrics in GMPLS/MPLS-TE for = troubleshooting the delay between completion of the signalling process = and the data path establishment and is a such comprehensive. I do have = however a number of fundamental and less fundamental questions that may = be caused for my lack of familiarity with the topic at hand, so please = indulge=85. Generic: The central goal of the document appears to be to remedy the fact that = applications think that the data path is available whereas it is not. It = is to me completely unclear why: - the signalling process can not be changed to terminate only upon = availability of a data path or even easier - verifying the availability of the data path (send roundtrip packet, if = successful ok) I can see that the metrics that you are defining may be of use in the = control plane, but I fail to see how they may help the application, I = find it hard to believe that any application would make use of these = metrics beyond the binary value of "is data path available". And that is = what you cite as the reason for this draft. So please expand the goal or = argue why you need this set of metrics. Abstract: This was very hard for me to parse. For starters, "this delay" does't = seem to refer to any delay previously mentioned. In fact it took me a = while to understand that it is referring to the time lapsed between = finishing signalling and data path becoming available, I suggest = rewording to make that more clear. Section 3 (overview): please expand RRFD, RSRD, PRFD, PSFD, PSRD on first use Section 5.3 (RRFD metric parameters): What is the unit of T? UTC? Section 5.6 (RRFD discussion): It seems to me that the delays that are introduced by the time to = propagate the signal, the delay introduced by the interfaces etc. are = well in the various milliseconds range, doesn't that invalidate any = measurements in that range? Or can you argue that those introduce a = fixed delay so that variations are due to what you are trying to = measure. The same holds for the other metrics Section 11.2 (median of metric): It seems to me that the median is of little value if the majority of the = values are undefined, is that why you have tyne failure count? If so, = please say so. Section 12 (Security considerations): It is unclear to me what the result of an evil MitM manipulating values = of the metrics could do. Can they for example introduce a denial of = service by reporting high delays? Can they prioritise their own traffic = by making competitors for bandwidth think the data path is not there = yet? Hope this helps, Klaas= From adrian@olddog.co.uk Wed Aug 15 05:22:47 2012 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 4591121F8487; Wed, 15 Aug 2012 05:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDdckcDU-FhN; Wed, 15 Aug 2012 05:22:46 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 9506221F85A7; Wed, 15 Aug 2012 05:21:41 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7FCLcEE002744; Wed, 15 Aug 2012 13:21:38 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7FCLaJs002708 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Aug 2012 13:21:37 +0100 From: "Adrian Farrel" To: "'Klaas Wierenga'" , "'The IESG'" , , References: <21E590DF-6035-4790-9171-9B46F0A849E7@cisco.com> In-Reply-To: <21E590DF-6035-4790-9171-9B46F0A849E7@cisco.com> Date: Wed, 15 Aug 2012 13:21:32 +0100 Message-ID: <0bc101cd7ae0$826fcb40$874f61c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK80gJ7ycw+TYBlnPK8G7KdDShhuJV8G7oA Content-Language: en-gb Subject: Re: [secdir] Secdir review of draft-ietf-ccamp-dpm-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 12:22:47 -0000 Hi Klaas, Thanks for this. It came in after the end of IETF Last Call so the comments will get fumbled a bit. Authors: your I-D has gone forward for the IESG telechat on August 30th. If you are able to revise the I-D to pick up the comments from Klaas and can get a new version posted on or before August 23rd, please do so. Otherwise, please do not update the document yet (to give the IESG a stable target) and we will handle the comments after IESG review. Many thanks, Adrian > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Klaas > Wierenga > Sent: 15 August 2012 12:56 > To: The IESG; secdir@ietf.org; draft-ietf-ccamp-dpm.all@tools.ietf.org > Subject: Secdir review of draft-ietf-ccamp-dpm-06 > > 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. > > This document describes a set of path delay metrics in GMPLS/MPLS-TE for > troubleshooting the delay between completion of the signalling process and the > data path establishment and is a such comprehensive. I do have however a > number of fundamental and less fundamental questions that may be caused for > my lack of familiarity with the topic at hand, so please indulge.. > > Generic: > > The central goal of the document appears to be to remedy the fact that > applications think that the data path is available whereas it is not. It is to me > completely unclear why: > > - the signalling process can not be changed to terminate only upon availability of a > data path or even easier > > - verifying the availability of the data path (send roundtrip packet, if successful > ok) > > I can see that the metrics that you are defining may be of use in the control > plane, but I fail to see how they may help the application, I find it hard to believe > that any application would make use of these metrics beyond the binary value of > "is data path available". And that is what you cite as the reason for this draft. So > please expand the goal or argue why you need this set of metrics. > > Abstract: > > This was very hard for me to parse. For starters, "this delay" does't seem to refer > to any delay previously mentioned. In fact it took me a while to understand that > it is referring to the time lapsed between finishing signalling and data path > becoming available, I suggest rewording to make that more clear. > > Section 3 (overview): > > please expand RRFD, RSRD, PRFD, PSFD, PSRD on first use > > Section 5.3 (RRFD metric parameters): > > What is the unit of T? UTC? > > Section 5.6 (RRFD discussion): > > It seems to me that the delays that are introduced by the time to propagate the > signal, the delay introduced by the interfaces etc. are well in the various > milliseconds range, doesn't that invalidate any measurements in that range? Or > can you argue that those introduce a fixed delay so that variations are due to > what you are trying to measure. > > The same holds for the other metrics > > Section 11.2 (median of metric): > > It seems to me that the median is of little value if the majority of the values are > undefined, is that why you have tyne failure count? If so, please say so. > > Section 12 (Security considerations): > > It is unclear to me what the result of an evil MitM manipulating values of the > metrics could do. Can they for example introduce a denial of service by reporting > high delays? Can they prioritise their own traffic by making competitors for > bandwidth think the data path is not there yet? > > Hope this helps, > > Klaas= From sra@hactrn.net Wed Aug 15 09:43:08 2012 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 958F621E80F2; Wed, 15 Aug 2012 09:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdYRmkTRvPAC; Wed, 15 Aug 2012 09:43:08 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by ietfa.amsl.com (Postfix) with ESMTP id C3B1E21E80EE; Wed, 15 Aug 2012 09:43:07 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 817189B447; Wed, 15 Aug 2012 16:43:04 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 5762A171B6; Wed, 15 Aug 2012 12:43:04 -0400 (EDT) Date: Wed, 15 Aug 2012 12:43:04 -0400 From: Rob Austein To: draft-ietf-opsawg-automated-network-configuration.all@tools.ietf.org MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20120815164304.5762A171B6@thrintun.hactrn.net> Cc: Internet Engineering Steering Group , secdir@ietf.org Subject: [secdir] secdir review of draft-ietf-opsawg-automated-network-configuration-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 16:43:08 -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 draft is a problem statement, targeted for Informational status, discussing issues surrounding automated techniques for configuration (initial and ongoing) of large numbers of devices, both within a single organization and when crossing organizational boundaries. The draft goes into some detail about security issues involved in such configuration, and emphasizes the difficulty and importance of getting this stuff right. The Security Considerations section seems adequate, and the authors deserve credit for resisting the temptation of just sprinkling IPsec pixie dust all over a fairly hard problem space. I have no serious security concerns with this document. Minor notes, in case for whatever reason the authors need to make other changes: - The discussion of DNS-based mechanisms for finding the configuration server probably should mention DNSSEC, at least in passing. At least in theory, if done properly, DNSSEC would allow the device a reasonable level of confidence that it has at least obtained the correct IP address for the configuration server. This does not, of course, remove the need for mutual authentication when establishing the secure channel, so the lack of mention of DNSSEC in the current text is not a critical omission. - The discussion of UUIDs and shared secrets is a bit confusing. While I agree with the basic premise (that the combination of UUIDs and shared secrets may be usable in certain cases but has serious scaling issues), the discussion does not really cover the inherent weakness of authentication using such techniques. If one twists one's head into the right shape, this is indeed a scaling problem of sorts ("Three can keep a secret, if two of them are dead"), but it would be better to be explicit about the weakness of authentication when all you have are UUIDs and a shared secret. From sun.weiqiang@gmail.com Wed Aug 15 22:39:24 2012 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 99FFC21F8598; Wed, 15 Aug 2012 22:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0omlf-pZM4b0; Wed, 15 Aug 2012 22:39:23 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id A1A3E21F8597; Wed, 15 Aug 2012 22:39:23 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so994181pbb.31 for ; Wed, 15 Aug 2012 22:39:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic:in-reply-to :mime-version:content-type:content-transfer-encoding; bh=qL23on1O3JRE0/oI78bF8ouo8mySkijXkV9duO2DwQs=; b=mC1SMoVqWEDVAhGxmQ/PTTHwIhDEHB99wxb48+Ll71QAa4P2ItYLBY2lnpB3McEqfL iMHtAj3c80rsoJa/ga/UN276xgvy2M+wm2hqMJzZTy+eyzdBe1jFq251wba/fKJAh/l3 5YtfOwAV2z+XUXKdWLk4SKjLxHadOUsnVTLWcEc3RAimW6oskrnN83WvsRcu9HDInu+W 9LgsMi+On0rQzbV54SL01oyV0iaHkMEPD3M8gQCSWUjY6ws3WXIrWRl/gbLysTYlVt/s FIttEmGjdrokjSDRo834Z9DYHM2VdnkyPjHXXMuFXmT2MfZFeN019sujVfgoNf3d2PZ0 UAEQ== Received: by 10.68.227.201 with SMTP id sc9mr751684pbc.163.1345095563105; Wed, 15 Aug 2012 22:39:23 -0700 (PDT) Received: from [192.168.6.100] ([202.120.39.147]) by mx.google.com with ESMTPS id sj5sm1928732pbc.30.2012.08.15.22.39.18 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Aug 2012 22:39:21 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Thu, 16 Aug 2012 13:39:07 +0800 From: Weiqiang Sun To: Klaas Wierenga , The IESG , , Message-ID: Thread-Topic: Secdir review of draft-ietf-ccamp-dpm-06 In-Reply-To: <21E590DF-6035-4790-9171-9B46F0A849E7@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Mailman-Approved-At: Thu, 16 Aug 2012 03:04:06 -0700 Subject: Re: [secdir] Secdir review of draft-ietf-ccamp-dpm-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 05:39:24 -0000 Hello Klaas, Thanks for the careful review. Please find our responses inline. Best regards, Weiqiang On 8/15/12 7:56 PM, "Klaas Wierenga" wrote: >Generic: > >The central goal of the document appears to be to remedy the fact that >applications think that the data path is available whereas it is not. It >is to me completely unclear why: > >- the signalling process can not be changed to terminate only upon >availability of a data path or even easier According to existing RSVP-TE specifications (RFC 2205, 3029, 3473...), the signaling process is required to act upon certain data path status (e.g., successful setup/removal of a cross connection in the data plane etc). In an implementation that is fully conformant to specifications and everything works perfectly as expected, the data path should be in its desired status (i.e., consistent with the control plane status) and no dpm measurement is necessary. However, many reasons may cause inconsistency and this can not be avoided by observing the control plane messages, or changing the behavior of the control plane. For example, in one implementation, intermediate node may propagate signaling messages to the next hop, before the cross-connection configuration has been completed. (Vendors may have very good reasons to do this, when control plane performance becomes an important metric to report). > >- verifying the availability of the data path (send roundtrip packet, if >successful ok) > >I can see that the metrics that you are defining may be of use in the >control plane, but I fail to see how they may help the application, I >find it hard to believe that any application would make use of these >metrics beyond the binary value of "is data path available". And that is >what you cite as the reason for this draft. So please expand the goal or >argue why you need this set of metrics. Often, applications use signaling messages as indications of availability of data paths. In case of an un-conformant implementation, the measurement will provide the necessary information to applications on when it is safe to start sending data. > >Abstract: > >This was very hard for me to parse. For starters, "this delay" does't >seem to refer to any delay previously mentioned. In fact it took me a >while to understand that it is referring to the time lapsed between >finishing signalling and data path becoming available, I suggest >rewording to make that more clear. Good point here. I suggest the following change: Before: The existence of this delay and the possible failure of cross connection programming, if not properly treated, will result in data loss or even application failure. After: The existence of the inconsistency between the signaling messages and cross connection programing, and the possible failure of cross connection programming, if not properly treated, will result in data loss or even application failure. > >Section 3 (overview): > >please expand RRFD, RSRD, PRFD, PSFD, PSRD on first use In Section 3, we already have: o RRFD - the delay between RESV message received by ingress node and forward data path becomes ready for use. o RSRD - the delay between RESV message sent by egress node and reverse data path becomes ready for use. o PRFD - the delay between PATH message received by egress node and forward data path becomes ready for use. o PSFD - the delay between PATH message sent by ingress and forward data path becomes ready for use. o PSRD - the delay between PATH message sent by ingress and reverse data path becomes ready for use. Are you looking for something else? > >Section 5.3 (RRFD metric parameters): > >What is the unit of T? UTC? In fact we does not impose any requirement on the selection of T, as have been done in the IPPM documents (RFC 2679, 2681). To me, machine local time is more preferable. But using UTC may also be an option. > >Section 5.6 (RRFD discussion): > >It seems to me that the delays that are introduced by the time to >propagate the signal, the delay introduced by the interfaces etc. are >well in the various milliseconds range, doesn't that invalidate any >measurements in that range? Or can you argue that those introduce a fixed >delay so that variations are due to what you are trying to measure. >The same holds for the other metrics Exactly. On a set of programed cross-connections (an LSP), we get a fixed delay and hence it can be separated from the measured delay. In the current document, we have the following discussions. Hope these address your concern. o The accuracy of RRFD is also dependent on the time needed to propagate the error free signal from the ingress node to the egress node. A typical value of propagating the error free signal from the ingress node to the egress node under the same measurement setup MAY be reported. The methodology to obtain such values is outside the scope of this document. o The accuracy of this metric is also dependent on the physical layer serialization/de-serialization of the test signal for certain data path technologies. For instance, for an LSP between a pair of low speed Ethernet interfaces, the time needed to serialize/deserialize a large frame may not be negligible. In this case, it is RECOMMENDED that the ingress node uses small frames. The average length of the frame MAY be reported. > > > >Section 11.2 (median of metric): > >It seems to me that the median is of little value if the majority of the >values are undefined, is that why you have tyne failure count? If so, >please say so. The median definition still holds even though the majority of the values are undefined (and will not be counted in). To address you concern, I suggest the following text: When the number of defined values in the given sample is small, the metric median may not be typical and SHOULD be used carefully. > >Section 12 (Security considerations): > >It is unclear to me what the result of an evil MitM manipulating values >of the metrics could do. Can they for example introduce a denial of >service by reporting high delays? Can they prioritise their own traffic >by making competitors for bandwidth think the data path is not there yet? Measurements defined in this document are believed to be carried out in controlled network environments, e.g., in laboratories, so IMHO MitM attack is really out of scope. :) > >Hope this helps, Thank again! Let us know in case you have more concerns. > >Klaas From alexey.melnikov@isode.com Thu Aug 16 05:22:03 2012 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 DB2C421F8464; Thu, 16 Aug 2012 05:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.878 X-Spam-Level: X-Spam-Status: No, score=-102.878 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCUnUROgddwJ; Thu, 16 Aug 2012 05:22:03 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id BC36E21F8462; Thu, 16 Aug 2012 05:22:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1345119721; d=isode.com; s=selector; i=@isode.com; bh=DNtKJZIKC2tKy/5fppfVN9rAmsKWaOYqkz3LARpnm4M=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=jPirB2KQ3E52VZYFmu6TkyunJj2F+3fazjekdp9ULZSop62+3JJSMHhlKxktKNH3e2u1cL 1RBH5c91CloWpN53sYNq7K8ChujFJXTve3V+dGJmEaGjeUoVKJp53XMVkCkzJWWyuc6ivU joMx5foyvKgYqLuiwQWLwS9unPwSg04=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 16 Aug 2012 13:22:01 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <502CE623.6090804@isode.com> Date: Thu, 16 Aug 2012 13:22:59 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: The IESG , "secdir@ietf.org" , draft-ietf-mptcp-multiaddressed.all@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] Secdir review of draft-ietf-mptcp-multiaddressed-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 12:22:04 -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 a set of extensions to traditional TCP to support multipath operation, i.e. the ability to simultaneously use multiple (potentially disjoint) paths between peers. The protocol offers the same type of service to applications as TCP (i.e. reliable bytestream), and provides the components necessary to establish and use multiple TCP flows across paths. The Security Consideration states: The fundamental goal is for the security of MPTCP to be "no worse" than regular TCP today, and the key security requirements are: o Provide a mechanism to confirm that the parties in a subflow handshake are the same as in the original connection setup. o Provide verification that the peer can receive traffic at a new address before using it as part of a connection. o Provide replay protection, i.e. ensure that a request to add/ remove a subflow is 'fresh'. And then explains in details how these security requirements are met. I think the design and explanation is quite reasonable. The Security Considerations also mentions that the ability of negotiating a particular hashing mechanism is susceptible to bid-down attacks for on-path attackers and points out that this is also true for TCP without MPTCP extension. I think there are a couple of things missing from the Security Considerations section: Section 3.3.1 says that the same data can be sent on multiple subflows (for resiliency). What if an attacker tries to send different data on multiple subflows pretending it is the same? Is there a security consideration here? (I admit I am quite ignorant and might be missing something obvious here.) Section 3.3.1 implies that unacknowledged connection level data (received before the mapping is received) can be used for DoS? Should this be mentioned in the Section 5. Other minor comments/nits: 2.7. Notable features o To meet the threats identified in [7], the following steps are taken: keys are sent in the clear in the MP_CAPABLE messages; MP_JOIN messages are secured with HMAC-SHA1 The first mention of HMAC-SHA1 needs a reference. using those keys; and standard TCP validity checks are made on the other messages ( ensuring sequence numbers are in-window). In 3.1: This key is generated by its sender and has local meaning only, and its method of generation is implementation-specific. The key MUST be hard to guess, and it MUST be unique for the sending host at any one time. Recommendations for generating random keys are given in [11]. Connections will be indexed at each host by the token (the truncated SHA-1 hash of the key). Therefore, an implementation will require a mapping from each token to the corresponding connection, and in turn to the keys for the connection. Sounds like a good text for the Security Consideration section (maybe add a pointer from there?) [...] This exchange allows the safe passage of MPTCP options on SYN packets to be determined. If any of these options are dropped, MPTCP SHOULD "SHOULD" or "will"? Use of SHOULD doesn't seem correct here. gracefully fall back to regular single-path TCP, as documented in Section 3.6. Note that new subflows MUST NOT be established (using the process documented in Section 3.2) until a DSS option has been successfully received across the path (as documented in Section 3.3). [...] These bits negotiate capabilities in similar ways. For the 'C' bit, if either host requires the use of checksums, checksums MUST be used. In other words, the only way for checksums not to be used is if both hosts in their SYNs set C=0. This decision is confirmed by the setting of the 'C' bit in the third packet (the ACK) of the handshake. For example, if the initiator sets C=0 in the SYN, but the responder sets C=1 in the SYN/ACK, checksums MUST be used in both Is support of C=1 required in all implementations? It is also a bit unusual (at least to me) that the initiator is not able to refuse to support C=1. directions, and the initiator will set C=1 in the ACK. The decision whether to use checksums will be stored by an implementation in a per-connection binary state variable. From Sandra.Murphy@sparta.com Thu Aug 16 09:10:47 2012 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 197C021F8526; Thu, 16 Aug 2012 09:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2M6BPhHaQMR2; Thu, 16 Aug 2012 09:10:46 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0EEA321F84F4; Thu, 16 Aug 2012 09:10:37 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q7GGAaQi009455; Thu, 16 Aug 2012 11:10:37 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q7GGAZcd005377; Thu, 16 Aug 2012 11:10:36 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%21]) with mapi id 14.01.0355.002; Thu, 16 Aug 2012 12:10:30 -0400 From: "Murphy, Sandra" To: "secdir@ietf.org" , "iesg@ietf.org" Thread-Topic: secdir review of draft-ietf-ospf-hybrid-bcast-and-p2mp Thread-Index: Ac17uYA1ZqB188w9QjGy7M9E8oHAGA== Date: Thu, 16 Aug 2012 16:10:30 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F6014F@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-ospf-hybrid-bcast-and-p2mp.all@tools.ietf.org" Subject: [secdir] secdir review of draft-ietf-ospf-hybrid-bcast-and-p2mp X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 16:10:47 -0000 I have reviewed this document as part of the security directorate's =0A= ongoing effort to review all IETF documents being processed by the IESG.=0A= These comments were written primarily for the benefit of the security=0A= area directors. Document editors and WG chairs should treat these=0A= comments just like any other last call comments.=0A= =0A= This document provides a new way of communicating connectivity on a shared = network. Currently there are two methods, one used for broadcast/NBMA nets= and one used for point-multipoint networks. The broadcast net case elects= a DR that then floods a network LSA noting all routers on the net so that = LSA database synchronization uses the DR. The p2mp case establishes links = from each router to each other router on the p2mp network. The broadcast/N= BMA case does not permit different metrics for the links to each router on = the broadcast network. The p2mp case allows different metrics for the link= s between adjacent routers on the p2mp network.=0A= =0A= This draft introduces a hybrid case for broadcast/NBMA networks - using the= neighbor discovery and LSA database synchronization of the broadcast/NBMA = case but the establishment of links with different metrics of the p2mp case= . The draft specifies changes to LSAs and processing that would produce th= is hybrid behavior.=0A= =0A= The security considerations section says there are no new security vulnerab= ilities that result. OSPF authenticates all routers on a shared network (w= hether broadcast/NBMA or p2mp) with a single shared key, and this mechanism= 's changes share that authentication. OSPF does not protect against bad be= havior by legitimate participants so no misbehavior possible with these cha= nges would create new vulnerabilities.=0A= =0A= The draft introduces changes to the LSAs and behavior but does not explain = why the changes are needed or what their intent is. This makes it very har= d to understand or analyze what the effect would be. I was able to figure = out why the a router LSA type 1 link is introduced to a neighbor that is al= so mentioned by the DR (that's the combination of the broadcast discovery f= eature into the p2mp links part of the hybrid). But I was not able to figu= re out other changes, such as why it was necessary to introduce type 3 stub= network links for the router's subnet. Perhaps the authors expect that re= aders will be so intimately familiar with OSPF design that the motivation f= or each change will be obvious. But it does make readers work hard.=0A= =0A= Section 5 considers cases where some routers on a broadcast network follow = the hybrid behavior and other follow the broadcast/NBMA behavior. OSPF wor= ks on the assumption that all routers share the same dataset and therefore = each will compute shortest paths that will not introduce loops. In this c= ase, not all routers will be working from the same dataset of links, raisin= g concern about loops. Section 5 (briefly) says that in this case there wo= uld be "no traffic traversing certain pairs of routers" but no loops. I c= an understand that enough to believe it. But I am not as confident that = a router that produces both the network LSA and a router LSA with the p2mp = links could not confuse the situation sufficiently to produce loops. I won= der if the authors have considered that case. I'm sorry that I was not abl= e to devote the time to the shortest path computation to resolve this lack = of confidence for myself.=0A= =0A= NOTE: this concern would be a case of mis-behavior by a valid participant a= nd OSPF is well understood to be unprotected from such mis-behavior. This = is NOT a newly introduced security concern.=0A= =0A= section 4.5 says "the DR MUST NOT generate a network LSA for the interface.= " OSPF's specs in general do not recommend reporting errors, or I would su= ggest a new error report if a network LSA were spotted on an interface that= was designated as hybrid.=0A= =0A= --Sandy=0A= =0A= Nits:=0A= =0A= page 3:=0A= =0A= network. Further, it mandates establishment of adjacencies to all=0A= all configured or discovered neighbors on the network.=0A= =0A= "all all" -> "all"=0A= =0A= page 8=0A= =0A= o If a router is in state DROther on the interface, it MUST consider=0A= an adjacency to non-DR and non-BDR neighbors as reestablished when=0A= the neighbor state reaches 2-Way.=0A= =0A= I think there is a separate adjacency for each neighbor, not one for all ne= ighbors, so I think this should be something like:=0A= =0A= o If a router is in state DROther on the interface, it MUST consider=0A= an adjacency to a non-DR or non-BDR neighbor as reestablished when=0A= the neighbor state reaches 2-Way.=0A= =0A= =0A= =0A= =0A= =0A= From bill.wu@huawei.com Thu Aug 16 19:40:04 2012 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 D303C21F8505; Thu, 16 Aug 2012 19:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.89 X-Spam-Level: X-Spam-Status: No, score=-3.89 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGSZUvp6fkX4; Thu, 16 Aug 2012 19:40:03 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 90F8721F84F8; Thu, 16 Aug 2012 19:40:03 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJM11471; Thu, 16 Aug 2012 18:40:03 -0800 (PST) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 16 Aug 2012 19:38:54 -0700 Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 16 Aug 2012 19:38:52 -0700 Received: from w53375 (10.138.41.149) by SZXEML414-HUB.china.huawei.com (10.82.67.153) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 17 Aug 2012 10:38:37 +0800 Message-ID: <4020C2CA83FF4CCBA473B46A240BBFD6@china.huawei.com> From: Qin Wu To: Vincent Roca , The IESG , , References: <47091871-198D-4C5C-953A-919696F8CAFC@inria.fr> Date: Fri, 17 Aug 2012 10:38:36 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_016D_01CD7C64.75451D50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Subject: Re: [secdir] Secdir review of draft-ietf-xrblock-rtcp-xr-pdv-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 02:40:05 -0000 ------=_NextPart_000_016D_01CD7C64.75451D50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGksVmluY2VudDoNClRoYW5rIGZvciB5b3VyIHJldmlldywgcGxlYXNlIHNlZSBteSBjb21tZW50 cyBpbmxpbmUgYmVsb3cuDQoNClJlZ2FyZHMhDQotUWluDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdl IC0tLS0tIA0KRnJvbTogIlZpbmNlbnQgUm9jYSIgPHZpbmNlbnQucm9jYUBpbnJpYS5mcj4NClRv OiAiVGhlIElFU0ciIDxpZXNnQGlldGYub3JnPjsgPHNlY2RpckBpZXRmLm9yZz47IDxkcmFmdC1p ZXRmLXhyYmxvY2stcnRjcC14ci1wZHYuYWxsQHRvb2xzLmlldGYub3JnPg0KQ2M6ICJWaW5jZW50 IFJvY2EiIDx2aW5jZW50LnJvY2FAaW5yaWEuZnI+DQpTZW50OiBUaHVyc2RheSwgQXVndXN0IDAy LCAyMDEyIDU6MzEgQU0NClN1YmplY3Q6IFNlY2RpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi14cmJs b2NrLXJ0Y3AteHItcGR2LTAzDQoNCg0KPiBIZWxsbywNCj4gDQo+IEkgaGF2ZSByZXZpZXdlZCB0 aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3MNCj4gb25n b2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQg YnkgdGhlDQo+IElFU0cuICBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZv ciB0aGUgYmVuZWZpdCBvZiB0aGUNCj4gc2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMuIERvY3VtZW50 IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQNCj4gdGhlc2UgY29tbWVudHMganVz dCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQo+IA0KPiANCj4gVGhlIGF1dGhv cnMgZXhwbGFpbiB0aGlzIGRvY3VtZW50IGludHJvZHVjZXMgbm8gbmV3IHNlY3VyaXR5DQo+IGNv bnNpZGVyYXRpb25zIGJleW9uZCB0aG9zZSBkZXNjcmliZWQgaW4gW1JGQzM2MTFdLg0KPiBJIGFn cmVlIHRoZXJlIGlzIG5vIHByaXZhY3kgcmlzaywgYnV0IGEgcXVlc3Rpb24gSSdkIGxpa2UgdGhl IGF1dGhvcnMNCj4gdG8gZGlzY3VzcyBhIGxpdHRsZSBiaXQgY29uY2VybnMgdGhlIGNhc2Ugd2hl cmUgYW4gYXR0YWNrZXIgc2VuZHMNCj4gZm9yZ2VkIFJUQ1AgWFIgcmVwb3J0cywgd2l0aCBlcnJv bmVvdXMgUGFja2V0IERlbGF5IFZhcmlhdGlvbiB2YWx1ZXMNCj4gKGUuZy4gdGhlIGF0dGFja2Vy IG1heSBwcmV0ZW5kIHRoZSBQRFYgYXJlIG11Y2ggc21hbGxlciB0aGFuIHRoZSByZWFsaXR5KS4N Cj4gSSBhc3N1bWUgdGhpcyBtYXkgcmVzdWx0IGluIGJhY2sgcGxheW91dCBidWZmZXIgc2V0dXBz LCBpc24ndCBpdD8gVGhpcw0KPiBsb29rcyBsaWtlIGEgY29vbCB3YXkgdG8gY3JlYXRlIGEgRG9T Lg0KDQpbUWluXTogSW4gc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBzZWN0aW9uIGluIFJGQzM2MTEs IGl0IHNhaWQ6DQoiDQpUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgdGhhdCBhcHBseSB0byBS VENQIHJlcG9ydHMgW1JGQzM1NTBdIGFsc28gYXBwbHkNCiB0byBYUiByZXBvcnRzLiANCiINCklu IFNlY3VyaXR5IGNvbnNpZGVyYXRpb24gc2VjdGlvbiBpbiBSRkMzNTUwLCBpdCBzYWlkOg0KIg0K ICAgUlRQIHN1ZmZlcnMgZnJvbSB0aGUgc2FtZSBzZWN1cml0eSBsaWFiaWxpdGllcyBhcyB0aGUg dW5kZXJseWluZw0KICAgcHJvdG9jb2xzLiAgRm9yIGV4YW1wbGUsIGFuIGltcG9zdG9yIGNhbiBm YWtlIHNvdXJjZSBvciBkZXN0aW5hdGlvbg0KICAgbmV0d29yayBhZGRyZXNzZXMsIG9yIGNoYW5n ZSB0aGUgaGVhZGVyIG9yIHBheWxvYWQuICBXaXRoaW4gUlRDUCwgdGhlDQogICBDTkFNRSBhbmQg TkFNRSBpbmZvcm1hdGlvbiBtYXkgYmUgdXNlZCB0byBpbXBlcnNvbmF0ZSBhbm90aGVyDQogICBw YXJ0aWNpcGFudC4gIEluIGFkZGl0aW9uLCBSVFAgbWF5IGJlIHNlbnQgdmlhIElQIG11bHRpY2Fz dCwgd2hpY2gNCiAgIHByb3ZpZGVzIG5vIGRpcmVjdCBtZWFucyBmb3IgYSBzZW5kZXIgdG8ga25v dyBhbGwgdGhlIHJlY2VpdmVycyBvZg0KICAgdGhlIGRhdGEgc2VudCBhbmQgdGhlcmVmb3JlIG5v IG1lYXN1cmUgb2YgcHJpdmFjeS4gIFJpZ2h0bHkgb3Igbm90LA0KICAgdXNlcnMgbWF5IGJlIG1v cmUgc2Vuc2l0aXZlIHRvIHByaXZhY3kgY29uY2VybnMgd2l0aCBhdWRpbyBhbmQgdmlkZW8NCiAg IGNvbW11bmljYXRpb24gdGhhbiB0aGV5IGhhdmUgYmVlbiB3aXRoIG1vcmUgdHJhZGl0aW9uYWwg Zm9ybXMgb2YNCiAgIG5ldHdvcmsgY29tbXVuaWNhdGlvbiBbMzNdLiAgVGhlcmVmb3JlLCB0aGUg dXNlIG9mIHNlY3VyaXR5DQogICBtZWNoYW5pc21zIHdpdGggUlRQIGlzIGltcG9ydGFudC4gIFRo ZXNlIG1lY2hhbmlzbXMgYXJlIA0KICAgZGlzY3Vzc2VkIGluICBTZWN0aW9uIDkuDQoNCiINClRo YXQgaXMgdG8gc2F5LCB5b3VyIGNvbmNlcm5zIGhhcyBhbHJlYWR5IGJlZW4gdGFrZW4gaW4gYWNj b3VudGVkIGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9uIHNlY3Rpb24gaW4gUkZDMzU1MC4N Cg0KRnVydGhlcm1vcmUsIEluIHNlY3Rpb24gOSBvZiBSRkMzNTUwLCBpdCBzYWlkOg0KIg0KICAg TG93ZXIgbGF5ZXIgcHJvdG9jb2xzIG1heSBldmVudHVhbGx5IHByb3ZpZGUgYWxsIHRoZSBzZWN1 cml0eQ0KICAgc2VydmljZXMgdGhhdCBtYXkgYmUgZGVzaXJlZCBmb3IgYXBwbGljYXRpb25zIG9m IFJUUCwgaW5jbHVkaW5nDQogICBhdXRoZW50aWNhdGlvbiwgaW50ZWdyaXR5LCBhbmQgY29uZmlk ZW50aWFsaXR5LiAgVGhlc2Ugc2VydmljZXMgaGF2ZQ0KICAgYmVlbiBzcGVjaWZpZWQgZm9yIElQ IGluIFsyN10uICBTaW5jZSB0aGUgaW5pdGlhbCBhdWRpbyBhbmQgdmlkZW8NCiAgIGFwcGxpY2F0 aW9ucyB1c2luZyBSVFAgbmVlZGVkIGEgY29uZmlkZW50aWFsaXR5IHNlcnZpY2UgYmVmb3JlIHN1 Y2gNCiAgIHNlcnZpY2VzIHdlcmUgYXZhaWxhYmxlIGZvciB0aGUgSVAgbGF5ZXIsIHRoZSBjb25m aWRlbnRpYWxpdHkgc2VydmljZQ0KICAgZGVzY3JpYmVkIGluIHRoZSBuZXh0IHNlY3Rpb24gd2Fz IGRlZmluZWQgZm9yIHVzZSB3aXRoIFJUUCBhbmQgUlRDUC4NCiAgIFRoYXQgZGVzY3JpcHRpb24g aXMgaW5jbHVkZWQgaGVyZSB0byBjb2RpZnkgZXhpc3RpbmcgcHJhY3RpY2UuICBOZXcNCiAgIGFw cGxpY2F0aW9ucyBvZiBSVFAgTUFZIGltcGxlbWVudCB0aGlzIFJUUC1zcGVjaWZpYyBjb25maWRl bnRpYWxpdHkNCiAgIHNlcnZpY2UgZm9yIGJhY2t3YXJkIGNvbXBhdGliaWxpdHksIGFuZC9vciB0 aGV5IE1BWSBpbXBsZW1lbnQNCiAgIGFsdGVybmF0aXZlIHNlY3VyaXR5IHNlcnZpY2VzLiAgVGhl IG92ZXJoZWFkIG9uIHRoZSBSVFAgcHJvdG9jb2wgZm9yDQogICB0aGlzIGNvbmZpZGVudGlhbGl0 eSBzZXJ2aWNlIGlzIGxvdywgc28gdGhlIHBlbmFsdHkgd2lsbCBiZSBtaW5pbWFsDQogICBpZiB0 aGlzIHNlcnZpY2UgaXMgb2Jzb2xldGVkIGJ5IG90aGVyIHNlcnZpY2VzIGluIHRoZSBmdXR1cmUu DQoNCiAgIEFsdGVybmF0aXZlbHksIG90aGVyIHNlcnZpY2VzLCBvdGhlciBpbXBsZW1lbnRhdGlv bnMgb2Ygc2VydmljZXMgYW5kDQogICBvdGhlciBhbGdvcml0aG1zIG1heSBiZSBkZWZpbmVkIGZv ciBSVFAgaW4gdGhlIGZ1dHVyZS4gIEluDQogICBwYXJ0aWN1bGFyLCBhbiBSVFAgcHJvZmlsZSBj YWxsZWQgU2VjdXJlIFJlYWwtdGltZSBUcmFuc3BvcnQgUHJvdG9jb2wNCiAgIChTUlRQKSBbMjhd IGlzIGJlaW5nIGRldmVsb3BlZCB0byBwcm92aWRlIGNvbmZpZGVudGlhbGl0eSBvZiB0aGUgUlRQ DQogICBwYXlsb2FkIHdoaWxlIGxlYXZpbmcgdGhlIFJUUCBoZWFkZXIgaW4gdGhlIGNsZWFyIHNv IHRoYXQgbGluay1sZXZlbA0KICAgaGVhZGVyIGNvbXByZXNzaW9uIGFsZ29yaXRobXMgY2FuIHN0 aWxsIG9wZXJhdGUuICBJdCBpcyBleHBlY3RlZCB0aGF0DQogICBTUlRQIHdpbGwgYmUgdGhlIGNv cnJlY3QgY2hvaWNlIGZvciBtYW55IGFwcGxpY2F0aW9ucy4gIFNSVFAgaXMgYmFzZWQNCiAgIG9u IHRoZSBBZHZhbmNlZCBFbmNyeXB0aW9uIFN0YW5kYXJkIChBRVMpIGFuZCBwcm92aWRlcyBzdHJv bmdlcg0KICAgc2VjdXJpdHkgdGhhbiB0aGUgc2VydmljZSBkZXNjcmliZWQgaGVyZS4gIE5vIGNs YWltIGlzIG1hZGUgdGhhdCB0aGUNCiAgIG1ldGhvZHMgcHJlc2VudGVkIGhlcmUgYXJlIGFwcHJv cHJpYXRlIGZvciBhIHBhcnRpY3VsYXIgc2VjdXJpdHkNCiAgIG5lZWQuICBBIHByb2ZpbGUgbWF5 IHNwZWNpZnkgd2hpY2ggc2VydmljZXMgYW5kIGFsZ29yaXRobXMgc2hvdWxkIGJlDQogICBvZmZl cmVkIGJ5IGFwcGxpY2F0aW9ucywgYW5kIG1heSBwcm92aWRlIGd1aWRhbmNlIGFzIHRvIHRoZWly DQogICBhcHByb3ByaWF0ZSB1c2UuDQoNCiAgIEtleSBkaXN0cmlidXRpb24gYW5kIGNlcnRpZmlj YXRlcyBhcmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcw0KICAgZG9jdW1lbnQuDQoNCg0KIg0K RG9lcyB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBzZWN0aW9uIGRlc2NyaWJlZCBpbiBSRkMz NTUwIGFkZHJlc3MgeW91ciBjb25jZXJuPw0KDQoNCj4gSXMgdGhlIFBEViB1c2VkIGZvciBvdGhl ciBwdXJwb3NlcywgbGlrZSBpbW1pbmVudCBjb25nZXN0aW9uIGRldGVjdGlvbj8NCj4gSW4gdGhh dCBjYXNlIHRoZXJlIGNvdWxkIGJlIG90aGVyIGluY2VudGl2ZXMgZm9yIGFuIGF0dGFja2VyIHRv IGZha2UgWFINCj4gcGFja2V0cywgd2l0aCBwb3NzaWJsZSBhZGRpdGlvbmFsIGRhbWFnZXMuIA0K DQpbUWluXTpUaGUgUERWIHJldmVhbHMgdGhlIHZhcmlhdGlvbnMgaW4gbGF0ZW5jeSBjYXVzZWQg YnkgY29uZ2VzdGlvbiwgcm91dGUgY2hhbmdlcywgcXVldWluZywgZXRjLg0KVGhhdCBpcyB0byBz YXksIHlvdSBjYW4gbm90IHNpbXBseSB1c2luZyBQRFYgcmVwb3J0aW5nIHRvIGRldGVjdCBjb25n ZXN0aW9uLiBQbGVhc2UgY29ycmVjdCBtZSBpZiANCkkgYW0gd3JvbmcuDQoNCj4gSSB0aGluayBh IHBhcmFncmFwaCBvbiB0aGVzZSByaXNrcyBzaG91bGQgYmUgYWRkZWQuDQo+IA0KPiBDaGVlcnMs DQo+IA0KPiAgIFZpbmNlbnQ= ------=_NextPart_000_016D_01CD7C64.75451D50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgbmFtZT1HRU5FUkFUT1Ig Y29udGVudD0iTVNIVE1MIDguMDAuNjAwMS4xOTI1OCI+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZPg0KPERJVj5IaSxWaW5jZW50OjwvRElWPg0KPERJVj5UaGFuayBmb3IgeW91ciBy ZXZpZXcsIHBsZWFzZSBzZWUgbXkgY29tbWVudHMgaW5saW5lIGJlbG93LjwvRElWPg0KPERJVj4m bmJzcDs8L0RJVj4NCjxESVY+UmVnYXJkcyE8L0RJVj4NCjxESVY+LVFpbjwvRElWPg0KPERJVj4t LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KPERJVj5Gcm9tOiAiVmluY2VudCBSb2NhIiAm bHQ7PEEgDQpocmVmPSJtYWlsdG86dmluY2VudC5yb2NhQGlucmlhLmZyIj52aW5jZW50LnJvY2FA aW5yaWEuZnI8L0E+Jmd0OzwvRElWPg0KPERJVj5UbzogIlRoZSBJRVNHIiAmbHQ7PEEgaHJlZj0i bWFpbHRvOmllc2dAaWV0Zi5vcmciPmllc2dAaWV0Zi5vcmc8L0E+Jmd0OzsgDQombHQ7PEEgaHJl Zj0ibWFpbHRvOnNlY2RpckBpZXRmLm9yZyI+c2VjZGlyQGlldGYub3JnPC9BPiZndDs7ICZsdDs8 QSANCmhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1wZHYuYWxsQHRvb2xz LmlldGYub3JnIj5kcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1wZHYuYWxsQHRvb2xzLmlldGYu b3JnPC9BPiZndDs8L0RJVj4NCjxESVY+Q2M6ICJWaW5jZW50IFJvY2EiICZsdDs8QSANCmhyZWY9 Im1haWx0bzp2aW5jZW50LnJvY2FAaW5yaWEuZnIiPnZpbmNlbnQucm9jYUBpbnJpYS5mcjwvQT4m Z3Q7PC9ESVY+DQo8RElWPlNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMDIsIDIwMTIgNTozMSBBTTwv RElWPg0KPERJVj5TdWJqZWN0OiBTZWNkaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYteHJibG9jay1y dGNwLXhyLXBkdi0wMzwvRElWPjwvRElWPg0KPERJVj48QlI+PC9ESVY+DQo8RElWPiZndDsgSGVs bG8sPEJSPiZndDsgPEJSPiZndDsgSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFy dCBvZiB0aGUgDQpzZWN1cml0eSBkaXJlY3RvcmF0ZSdzPEJSPiZndDsgb25nb2luZyBlZmZvcnQg dG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyANCnByb2Nlc3NlZCBieSB0aGU8QlI+ Jmd0OyBJRVNHLiZuYnNwOyBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZv ciANCnRoZSBiZW5lZml0IG9mIHRoZTxCUj4mZ3Q7IHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiBE b2N1bWVudCBlZGl0b3JzIGFuZCBXRyANCmNoYWlycyBzaG91bGQgdHJlYXQ8QlI+Jmd0OyB0aGVz ZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCANCmNvbW1lbnRzLjxCUj4m Z3Q7IDxCUj4mZ3Q7IDxCUj4mZ3Q7IFRoZSBhdXRob3JzIGV4cGxhaW4gdGhpcyBkb2N1bWVudCBp bnRyb2R1Y2VzIA0Kbm8gbmV3IHNlY3VyaXR5PEJSPiZndDsgY29uc2lkZXJhdGlvbnMgYmV5b25k IHRob3NlIGRlc2NyaWJlZCBpbiANCltSRkMzNjExXS48QlI+Jmd0OyBJIGFncmVlIHRoZXJlIGlz IG5vIHByaXZhY3kgcmlzaywgYnV0IGEgcXVlc3Rpb24gSSdkIGxpa2UgdGhlIA0KYXV0aG9yczxC Uj4mZ3Q7IHRvIGRpc2N1c3MgYSBsaXR0bGUgYml0IGNvbmNlcm5zIHRoZSBjYXNlIHdoZXJlIGFu IGF0dGFja2VyIA0Kc2VuZHM8QlI+Jmd0OyBmb3JnZWQgUlRDUCBYUiByZXBvcnRzLCB3aXRoIGVy cm9uZW91cyBQYWNrZXQgRGVsYXkgVmFyaWF0aW9uIA0KdmFsdWVzPEJSPiZndDsgKGUuZy4gdGhl IGF0dGFja2VyIG1heSBwcmV0ZW5kIHRoZSBQRFYgYXJlIG11Y2ggc21hbGxlciB0aGFuIHRoZSAN CnJlYWxpdHkpLjxCUj4mZ3Q7IEkgYXNzdW1lIHRoaXMgbWF5IHJlc3VsdCBpbiBiYWNrIHBsYXlv dXQgYnVmZmVyIHNldHVwcywgaXNuJ3QgDQppdD8gVGhpczxCUj4mZ3Q7IGxvb2tzIGxpa2UgYSBj b29sIHdheSB0byBjcmVhdGUgYSBEb1MuPEJSPjwvRElWPg0KPERJVj5bUWluXTombmJzcDtJbiBz ZWN1cml0eSBjb25zaWRlcmF0aW9uIHNlY3Rpb24gaW4gUkZDMzYxMSwgaXQgc2FpZDo8L0RJVj4N CjxESVY+IjwvRElWPg0KPERJVj48U1RST05HPlRoZSBzZWN1cml0eSZuYnNwO2NvbnNpZGVyYXRp b25zIHRoYXQgYXBwbHkgdG8gUlRDUCByZXBvcnRzIA0KW1JGQzM1NTBdIGFsc28gYXBwbHk8QlI+ Jm5ic3A7dG8gWFIgcmVwb3J0cy4gPC9TVFJPTkc+PC9ESVY+DQo8RElWPiI8L0RJVj4NCjxESVY+ SW4gU2VjdXJpdHkgY29uc2lkZXJhdGlvbiBzZWN0aW9uIGluIFJGQzM1NTAsIGl0IHNhaWQ6PC9E SVY+DQo8RElWPiI8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7IFJUUCBzdWZmZXJzIGZyb20gdGhl IHNhbWUgc2VjdXJpdHkgbGlhYmlsaXRpZXMgYXMgdGhlIA0KdW5kZXJseWluZzxCUj4mbmJzcDsm bmJzcDsgcHJvdG9jb2xzLiZuYnNwOyBGb3IgZXhhbXBsZSwgPFNUUk9ORz5hbiBpbXBvc3RvciBj YW4gDQpmYWtlPC9TVFJPTkc+IHNvdXJjZSBvciBkZXN0aW5hdGlvbjxCUj4mbmJzcDsmbmJzcDsg bmV0d29yayBhZGRyZXNzZXMsIG9yIGNoYW5nZSANCnRoZSBoZWFkZXIgPFNUUk9ORz5vciBwYXls b2FkPC9TVFJPTkc+LiZuYnNwOyBXaXRoaW4gUlRDUCwgdGhlPEJSPiZuYnNwOyZuYnNwOyANCkNO QU1FIGFuZCBOQU1FIGluZm9ybWF0aW9uIG1heSBiZSB1c2VkIHRvIGltcGVyc29uYXRlIGFub3Ro ZXI8QlI+Jm5ic3A7Jm5ic3A7IA0KcGFydGljaXBhbnQuJm5ic3A7IEluIGFkZGl0aW9uLCBSVFAg bWF5IGJlIHNlbnQgdmlhIElQIG11bHRpY2FzdCwgDQp3aGljaDxCUj4mbmJzcDsmbmJzcDsgcHJv dmlkZXMgbm8gZGlyZWN0IG1lYW5zIGZvciBhIHNlbmRlciB0byBrbm93IGFsbCB0aGUgDQpyZWNl aXZlcnMgb2Y8QlI+Jm5ic3A7Jm5ic3A7IHRoZSBkYXRhIHNlbnQgYW5kIHRoZXJlZm9yZSBubyBt ZWFzdXJlIG9mIA0KcHJpdmFjeS4mbmJzcDsgUmlnaHRseSBvciBub3QsPEJSPiZuYnNwOyZuYnNw OyB1c2VycyBtYXkgYmUgbW9yZSBzZW5zaXRpdmUgdG8gDQpwcml2YWN5IGNvbmNlcm5zIHdpdGgg YXVkaW8gYW5kIHZpZGVvPEJSPiZuYnNwOyZuYnNwOyBjb21tdW5pY2F0aW9uIHRoYW4gdGhleSAN CmhhdmUgYmVlbiB3aXRoIG1vcmUgdHJhZGl0aW9uYWwgZm9ybXMgb2Y8QlI+Jm5ic3A7Jm5ic3A7 IG5ldHdvcmsgY29tbXVuaWNhdGlvbiANCls8QSB0aXRsZT0nIlNlY3VyaXR5IFNlcnZpY2VzIGZv ciBNdWx0aW1lZGlhIENvbmZlcmVuY2luZyInIA0KaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjMzU1MCNyZWYtMzMiPjMzPC9BPl0uJm5ic3A7IA0KPFNUUk9ORz5UaGVyZWZvcmUs IHRoZSB1c2Ugb2Ygc2VjdXJpdHk8QlI+Jm5ic3A7Jm5ic3A7IG1lY2hhbmlzbXMgd2l0aCBSVFAg aXMgDQppbXBvcnRhbnQuJm5ic3A7IFRoZXNlIG1lY2hhbmlzbXMgYXJlIDwvU1RST05HPjwvRElW Pg0KPERJVj48U1RST05HPiZuYnNwOyZuYnNwOyBkaXNjdXNzZWQgaW4mbmJzcDsgPC9TVFJPTkc+ PEEgDQpocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzNTUwI3NlY3Rpb24tOSI+ PFNUUk9ORz5TZWN0aW9uIA0KOTwvU1RST05HPjwvQT48U1RST05HPi48QlI+PC9ESVY+PC9TVFJP Tkc+DQo8RElWPiI8L0RJVj4NCjxESVY+VGhhdCBpcyB0byBzYXksIHlvdXIgY29uY2VybnMgaGFz IGFscmVhZHkgYmVlbiB0YWtlbiBpbiBhY2NvdW50ZWQgaW4gdGhlIA0Kc2VjdXJpdHkgY29uc2lk ZXJhdGlvbiBzZWN0aW9uIGluIFJGQzM1NTAuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJ Vj5GdXJ0aGVybW9yZSwgSW4gc2VjdGlvbiA5IG9mIFJGQzM1NTAsIGl0IHNhaWQ6PC9ESVY+DQo8 RElWPiI8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7PFNUUk9ORz4gTG93ZXIgbGF5ZXIgcHJvdG9j b2xzIG1heSBldmVudHVhbGx5IHByb3ZpZGUgYWxsIHRoZSANCnNlY3VyaXR5PEJSPiZuYnNwOyZu YnNwOyBzZXJ2aWNlcyB0aGF0IG1heSBiZSBkZXNpcmVkIGZvciBhcHBsaWNhdGlvbnMgb2YgUlRQ LCANCmluY2x1ZGluZzxCUj4mbmJzcDsmbmJzcDsgYXV0aGVudGljYXRpb24sIGludGVncml0eSwg YW5kIA0KY29uZmlkZW50aWFsaXR5LjwvU1RST05HPiZuYnNwOyBUaGVzZSBzZXJ2aWNlcyBoYXZl PEJSPiZuYnNwOyZuYnNwOyBiZWVuIA0Kc3BlY2lmaWVkIGZvciBJUCBpbiBbPEEgDQp0aXRsZT0n IlNlY3VyaXR5IEFyY2hpdGVjdHVyZSBmb3IgdGhlIEludGVybmV0IFByb3RvY29sIicgDQpocmVm PSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzNTUwI3JlZi0yNyI+Mjc8L0E+XS4mbmJz cDsgU2luY2UgdGhlIA0KaW5pdGlhbCBhdWRpbyBhbmQgdmlkZW88QlI+Jm5ic3A7Jm5ic3A7IGFw cGxpY2F0aW9ucyB1c2luZyBSVFAgbmVlZGVkIGEgDQpjb25maWRlbnRpYWxpdHkgc2VydmljZSBi ZWZvcmUgc3VjaDxCUj4mbmJzcDsmbmJzcDsgc2VydmljZXMgd2VyZSBhdmFpbGFibGUgZm9yIA0K dGhlIElQIGxheWVyLCB0aGUgY29uZmlkZW50aWFsaXR5IHNlcnZpY2U8QlI+Jm5ic3A7Jm5ic3A7 IGRlc2NyaWJlZCBpbiB0aGUgbmV4dCANCnNlY3Rpb24gd2FzIGRlZmluZWQgZm9yIHVzZSB3aXRo IFJUUCBhbmQgUlRDUC48QlI+Jm5ic3A7Jm5ic3A7IFRoYXQgZGVzY3JpcHRpb24gDQppcyBpbmNs dWRlZCBoZXJlIHRvIGNvZGlmeSBleGlzdGluZyBwcmFjdGljZS4mbmJzcDsgTmV3PEJSPiZuYnNw OyZuYnNwOyANCmFwcGxpY2F0aW9ucyBvZiBSVFAgTUFZIGltcGxlbWVudCB0aGlzIFJUUC1zcGVj aWZpYyANCmNvbmZpZGVudGlhbGl0eTxCUj4mbmJzcDsmbmJzcDsgc2VydmljZSBmb3IgYmFja3dh cmQgY29tcGF0aWJpbGl0eSwgYW5kL29yIHRoZXkgDQpNQVkgaW1wbGVtZW50PEJSPiZuYnNwOyZu YnNwOyBhbHRlcm5hdGl2ZSBzZWN1cml0eSBzZXJ2aWNlcy4mbmJzcDsgVGhlIG92ZXJoZWFkIA0K b24gdGhlIFJUUCBwcm90b2NvbCBmb3I8QlI+Jm5ic3A7Jm5ic3A7IHRoaXMgY29uZmlkZW50aWFs aXR5IHNlcnZpY2UgaXMgbG93LCBzbyANCnRoZSBwZW5hbHR5IHdpbGwgYmUgbWluaW1hbDxCUj4m bmJzcDsmbmJzcDsgaWYgdGhpcyBzZXJ2aWNlIGlzIG9ic29sZXRlZCBieSANCm90aGVyIHNlcnZp Y2VzIGluIHRoZSBmdXR1cmUuPEJSPjxCUj4mbmJzcDsmbmJzcDsgQWx0ZXJuYXRpdmVseSwgb3Ro ZXIgc2VydmljZXMsIA0Kb3RoZXIgaW1wbGVtZW50YXRpb25zIG9mIHNlcnZpY2VzIGFuZDxCUj4m bmJzcDsmbmJzcDsgb3RoZXIgYWxnb3JpdGhtcyBtYXkgYmUgDQpkZWZpbmVkIGZvciBSVFAgaW4g dGhlIGZ1dHVyZS4mbmJzcDsgSW48QlI+Jm5ic3A7Jm5ic3A7IHBhcnRpY3VsYXIsIDxTVFJPTkc+ YW4gDQpSVFAgcHJvZmlsZSBjYWxsZWQgU2VjdXJlIFJlYWwtdGltZSBUcmFuc3BvcnQgUHJvdG9j b2w8QlI+Jm5ic3A7Jm5ic3A7IChTUlRQKSANCls8L1NUUk9ORz48QSB0aXRsZT0nIlNlY3VyZSBS ZWFsLXRpbWUgVHJhbnNwb3J0IFByb3RvY29sIicgDQpocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmMzNTUwI3JlZi0yOCI+PFNUUk9ORz4yODwvU1RST05HPjwvQT48U1RST05HPl0g DQppcyBiZWluZyBkZXZlbG9wZWQgdG8gcHJvdmlkZSBjb25maWRlbnRpYWxpdHkgb2YgdGhlIFJU UDxCUj4mbmJzcDsmbmJzcDsgcGF5bG9hZCANCndoaWxlIGxlYXZpbmcgdGhlIFJUUCBoZWFkZXIg aW4gdGhlIGNsZWFyIHNvIHRoYXQgbGluay1sZXZlbDxCUj4mbmJzcDsmbmJzcDsgDQpoZWFkZXIg Y29tcHJlc3Npb24gYWxnb3JpdGhtcyBjYW4gc3RpbGwgb3BlcmF0ZS4mbmJzcDs8L1NUUk9ORz4g SXQgaXMgZXhwZWN0ZWQgDQp0aGF0PEJSPiZuYnNwOyZuYnNwOyBTUlRQIHdpbGwgYmUgdGhlIGNv cnJlY3QgY2hvaWNlIGZvciBtYW55IA0KYXBwbGljYXRpb25zLiZuYnNwOyBTUlRQIGlzIGJhc2Vk PEJSPiZuYnNwOyZuYnNwOyBvbiB0aGUgQWR2YW5jZWQgRW5jcnlwdGlvbiANClN0YW5kYXJkIChB RVMpIGFuZCBwcm92aWRlcyBzdHJvbmdlcjxCUj4mbmJzcDsmbmJzcDsgc2VjdXJpdHkgdGhhbiB0 aGUgc2VydmljZSANCmRlc2NyaWJlZCBoZXJlLiZuYnNwOyBObyBjbGFpbSBpcyBtYWRlIHRoYXQg dGhlPEJSPiZuYnNwOyZuYnNwOyBtZXRob2RzIA0KcHJlc2VudGVkIGhlcmUgYXJlIGFwcHJvcHJp YXRlIGZvciBhIHBhcnRpY3VsYXIgc2VjdXJpdHk8QlI+Jm5ic3A7Jm5ic3A7IA0KbmVlZC4mbmJz cDsgQSBwcm9maWxlIG1heSBzcGVjaWZ5IHdoaWNoIHNlcnZpY2VzIGFuZCBhbGdvcml0aG1zIHNo b3VsZCANCmJlPEJSPiZuYnNwOyZuYnNwOyBvZmZlcmVkIGJ5IGFwcGxpY2F0aW9ucywgYW5kIG1h eSBwcm92aWRlIGd1aWRhbmNlIGFzIHRvIA0KdGhlaXI8QlI+Jm5ic3A7Jm5ic3A7IGFwcHJvcHJp YXRlIHVzZS48QlI+PEJSPiZuYnNwOyZuYnNwOyBLZXkgZGlzdHJpYnV0aW9uIGFuZCANCmNlcnRp ZmljYXRlcyBhcmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpczxCUj4mbmJzcDsmbmJzcDsgDQpk b2N1bWVudC48QlI+PEJSPjwvRElWPg0KPERJVj4iPC9ESVY+DQo8RElWPkRvZXMgdGhlIHNlY3Vy aXR5IGNvbnNpZGVyYXRpb24gc2VjdGlvbiBkZXNjcmliZWQgaW4gUkZDMzU1MCBhZGRyZXNzIHlv dXIgDQpjb25jZXJuPzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT0mIzIzNDM1OyYjMjAz MDc7PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEJSPiZndDsgSXMgdGhlIFBEViB1c2VkIGZv ciBvdGhlciBwdXJwb3NlcywgbGlrZSBpbW1pbmVudCBjb25nZXN0aW9uIA0KZGV0ZWN0aW9uPzxC Uj4mZ3Q7IEluIHRoYXQgY2FzZSB0aGVyZSBjb3VsZCBiZSBvdGhlciBpbmNlbnRpdmVzIGZvciBh biBhdHRhY2tlciANCnRvIGZha2UgWFI8QlI+Jmd0OyBwYWNrZXRzLCB3aXRoIHBvc3NpYmxlIGFk ZGl0aW9uYWwgZGFtYWdlcy4gPEJSPjwvRElWPg0KPERJVj5bUWluXTpUaGUgUERWIHJldmVhbHMg dGhlIHZhcmlhdGlvbnMgaW4gbGF0ZW5jeSBjYXVzZWQgYnkgY29uZ2VzdGlvbiwgcm91dGUgDQpj aGFuZ2VzLCBxdWV1aW5nLCBldGMuPC9ESVY+DQo8RElWPlRoYXQgaXMgdG8gc2F5LCB5b3UgY2Fu IG5vdCBzaW1wbHkgdXNpbmcgUERWIHJlcG9ydGluZyB0byBkZXRlY3QgDQpjb25nZXN0aW9uLiBQ bGVhc2UgY29ycmVjdCBtZSBpZiA8L0RJVj4NCjxESVY+SSBhbSB3cm9uZy48L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz48L0ZPTlQ+PEZPTlQgc2l6ZT0yIGZh Y2U9JiMyMzQzNTsmIzIwMzA3Oz48L0ZPTlQ+PEJSPiZndDsgSSB0aGluayBhIA0KcGFyYWdyYXBo IG9uIHRoZXNlIHJpc2tzIHNob3VsZCBiZSBhZGRlZC48QlI+Jmd0OyA8QlI+Jmd0OyBDaGVlcnMs PEJSPiZndDsgDQo8QlI+Jmd0OyZuYnNwOyZuYnNwOyBWaW5jZW50PC9ESVY+PC9CT0RZPjwvSFRN TD4NCg== ------=_NextPart_000_016D_01CD7C64.75451D50-- From paul.hoffman@vpnc.org Sat Aug 18 18:18:59 2012 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 F2E5221F84CD; Sat, 18 Aug 2012 18:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMXbSEMge7Xw; Sat, 18 Aug 2012 18:18:58 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 39C3321F84CE; Sat, 18 Aug 2012 18:18:58 -0700 (PDT) Received: from [10.20.30.108] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q7J1ItuG093132 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 18 Aug 2012 18:18:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 18 Aug 2012 18:18:55 -0700 Message-Id: <14DB90CC-BF75-4EBC-8348-29E85D678DDE@vpnc.org> To: drinks@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) X-Mailer: Apple Mail (2.1485) Cc: secdir Subject: [secdir] Secdir review of draft-ietf-drinks-spp-framework X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2012 01:18:59 -0000 Greetings. I have been requested to review = draft-ietf-drinks-spp-framework for the Security Directorate. This = review is being done during WG Last Call instead of IETF Last Call as a = special request. I note that literally no one has spoken up in the WG = during WG Last Call since it began three weeks ago. SPPF is a protocol for provisioning session establishment data into data = registries and SIP service providers. Well, actually it's not. It is a = description of the data format and some handwaving about how to = transport that data. The mandatory-to-implement transport is listed in a = different document, draft-ietf-drinks-spp-protocol-over-soap (for which = there is no reference in this document...). The transport protocol requirements listed in section 4 of this document = are fairly generic, as are the security requirements. The descriptions = of the transport requirements are fine. The security requirements are = not so great: while servers MUST be able to authenticate clients, = confidentiality and integrity protection SHOULD be provided. Given that = the mandatory-to implement transport is SOAP, this approximately = translates to "must do some sort or minimal client authentication, = should consider using TLS but lots of clients and servers probably won't = actually do it". I think that undershoots moderns security practices, = which would have TLS be mandatory. Even though this is a security review, I cannot resist a non-security = question: SOAP? In 2012? Really? --Paul Hoffman From tobias.gondrom@gondrom.org Sun Aug 19 02:23:30 2012 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 3C34B21F8503 for ; Sun, 19 Aug 2012 02:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.62 X-Spam-Level: X-Spam-Status: No, score=-96.62 tagged_above=-999 required=5 tests=[AWL=-1.259, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2NPH1BjpqUS for ; Sun, 19 Aug 2012 02:23:29 -0700 (PDT) Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6777121F84CE for ; Sun, 19 Aug 2012 02:23:29 -0700 (PDT) Received: (qmail 17879 invoked from network); 19 Aug 2012 11:23:27 +0200 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO ?192.168.1.65?) (94.194.102.93) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 19 Aug 2012 11:23:27 +0200 Message-ID: <5030B08F.6080806@gondrom.org> Date: Sun, 19 Aug 2012 10:23:27 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: iesg@ietf.org, secdir@ietf.org, draft-ietf-idr-as0.all@tools.ietf.org Content-Type: multipart/alternative; boundary="------------040302070908030001080501" Subject: [secdir] Secdir review of draft-ietf-idr-as0 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2012 09:23:30 -0000 This is a multi-part message in MIME format. --------------040302070908030001080501 Content-Type: text/plain; charset=ISO-8859-1; 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 very short document describes an update to 4271, proscribing the use of AS 0 in BGP OPEN and AS_PATH / AS4_PATH BGP attribute. I believe the document does not introduce new security problems and has an adequate security considerations section. Nits: please note that the doc has normative references to current work in progress drafts: draft-ietf-idr-error-handling-01 and draft-ietf-idr-rfc4893bis-06 It has to wait for these docs to finish in order to proceed. Best regards, Tobias --------------040302070908030001080501 Content-Type: text/html; charset=ISO-8859-1 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 very short document describes an update to 4271, proscribing the use of AS 0 in BGP OPEN and AS_PATH / AS4_PATH BGP attribute.
I believe the document does not introduce new security problems and has an adequate security considerations section.

Nits: please note that the doc has normative references to current work in progress drafts:
draft-ietf-idr-error-handling-01 and draft-ietf-idr-rfc4893bis-06
It has to wait for these docs to finish in order to proceed.

Best regards, Tobias --------------040302070908030001080501-- From carl@redhoundsoftware.com Sun Aug 19 15:16:05 2012 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 6EB9421F8607 for ; Sun, 19 Aug 2012 15:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2ByMCizsxBb for ; Sun, 19 Aug 2012 15:16:05 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id D0A3621F85F9 for ; Sun, 19 Aug 2012 15:16:04 -0700 (PDT) Received: by qcac10 with SMTP id c10so4600076qca.31 for ; Sun, 19 Aug 2012 15:16:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=bTOJbPfzgAyVYvqOdqeoNfBiyRQN9JtfVl99q8nCPHw=; b=H2sGSVELsd21vKnb3P5vuxliX+SZU48YlmdeMJw9ckYe+AJb8DQ4aKVAfAW6IBgj35 joeTrfkhZ/ywknEc/kbTytgGOn9lqfwDwe8zr1Vus0zs+PJWHl4fDIpNcyc+WgrxyIoz YfuYxKbs8baKunUqptDKaNZpdZztmFm9tnaX/sq8YmmEanVQlSKJ6P31MSM6YHIr78YR aVOXAkWpTUlb2x56Wi68TmyBWSNj/II6uqi7TBPNrfgJTUSFRfPvpbwsWFXQB6qCjwSp jOLX1jGHUQuUUOv3IhPMZ7h6WdshskGra+5+39iMr0KjiDzO+dQiZpYPxmmAxsnXncaN WgHA== Received: by 10.229.135.4 with SMTP id l4mr10957368qct.39.1345414564074; Sun, 19 Aug 2012 15:16:04 -0700 (PDT) Received: from [192.168.1.5] (pool-173-79-118-111.washdc.fios.verizon.net. [173.79.118.111]) by mx.google.com with ESMTPS id t15sm14999524qaa.10.2012.08.19.15.16.01 (version=SSLv3 cipher=OTHER); Sun, 19 Aug 2012 15:16:03 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Sun, 19 Aug 2012 18:16:03 -0400 From: Carl Wallace To: Message-ID: Thread-Topic: secdir review of draft-ietf-ccamp-rfc5787bis Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQlmT13EuR+4mcJq5h+GY/oRQ/ecgfVZ/zWzne/SPmWdWA12hz/LXhWEozEsPsuxaVo0AqYX Cc: The IESG , "secdir@ietf.org" Subject: [secdir] secdir review of draft-ietf-ccamp-rfc5787bis X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2012 22:16:05 -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 obsoletes RFC 5787 and updates RFC 5786. Though this document is from an area with which I have no expertise, I found it clear and easy to follow. I found no security issues. One minor nit, it'd be helpful if Appendix C provided more detail about the nature of how this draft updates RFC 5786. From shanna@juniper.net Mon Aug 20 18:54:40 2012 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 B981911E809A; Mon, 20 Aug 2012 18:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.688 X-Spam-Level: X-Spam-Status: No, score=-105.688 tagged_above=-999 required=5 tests=[AWL=-0.892, BAYES_00=-2.599, LONGWORDS=1.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUnIPwh0n7-4; Mon, 20 Aug 2012 18:54:40 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 07FE211E80A2; Mon, 20 Aug 2012 18:54:33 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUDLqWUszum0DhLRRdi2pL8CUCnUVSEUw@postini.com; Mon, 20 Aug 2012 18:54:40 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 20 Aug 2012 18:54:16 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 20 Aug 2012 21:54:15 -0400 From: Stephen Hanna To: "iesg@ietf.org" , "draft-ietf-pwe3-mpls-eth-oam-iwk.all@tools.ietf.org" Date: Mon, 20 Aug 2012 21:54:14 -0400 Thread-Topic: secdir review of draft-ietf-pwe3-mpls-eth-oam-iwk-06 Thread-Index: Ac1/P93G5CAAbzJ/TqG6VlMDs0ODyQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "secdir@ietf.org" Subject: [secdir] secdir review of draft-ietf-pwe3-mpls-eth-oam-iwk-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 01:54:40 -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 how underlying defects in individual circuits or pseudowires should be mapped in order to provide emulated Ethernet service. I know very little about this area but I have reviewed the document and the primary references. Apparently, pseudowires provide little security themselves although supplemental security mechanisms may be used. In that context, this document seems to add no new security concerns. If security measures are not used, OAM messages can be fabricated, modified, or viewed in transit but this is arguably no worse than the lack of protection for all the other traffic flowing over pseudowires. The Security Considerations section in this document mainly points to the Security Considerations sections in several more fundamental documents. Those sections clearly describe the threats inherent in this design so I see no need for changes to this document. Thanks, Steve From weiler+secdir@watson.org Tue Aug 21 08:13:13 2012 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 4E96421F86A4 for ; Tue, 21 Aug 2012 08:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFX2uhfwukeE for ; Tue, 21 Aug 2012 08:13:12 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 80CC321F86B8 for ; Tue, 21 Aug 2012 08:13:12 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.5/8.14.5) with ESMTP id q7LFDB9o040932 for ; Tue, 21 Aug 2012 11:13:11 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.5/8.14.5/Submit) with ESMTP id q7LFDBnC040929 for ; Tue, 21 Aug 2012 11:13:11 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 21 Aug 2012 11:13:11 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Tue, 21 Aug 2012 11:13:12 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 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: Tue, 21 Aug 2012 15:13:13 -0000 For those who may have missed the announcement in Vancouver, I will soon be stepping down as secdir secretary. Tero Kivinen has agreed to step into the role. For the moment, we are both doing secretarial things, so please make use of the secdir-secretary@mit.edu address to reach us. -- Sam Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Catherine Meadows is next in the rotation. For telechat 2012-08-30 Reviewer LC end Draft Rob Austein T 2012-06-26 draft-ietf-bmwg-2544-as-05 Dave Cridland T 2012-08-23 draft-ietf-armd-problem-statement-03 Shawn Emery T 2012-08-24 draft-ietf-dnsop-rfc4641bis-12 Warren Kumari T 2012-07-11 draft-ietf-oauth-v2-threatmodel-07 Chris Lonvick T 2012-08-27 draft-ietf-v6ops-wireline-incremental-ipv6-05 Alexey Melnikov T - draft-ietf-krb-wg-kdc-model-14 Tim Polk T 2012-07-23 draft-ietf-appsawg-http-forwarded-07 Ondrej Sury T 2012-08-13 draft-sparks-genarea-mailarch-05 Sam Weiler T - draft-ietf-nea-pt-tls-07 Nico Williams T 2012-08-14 draft-ietf-ippm-testplan-rfc2679-02 For telechat 2012-09-13 Alexey Melnikov T 2012-08-13 draft-ietf-storm-iscsi-cons-06 Last calls and special requests: Dave Cridland 2012-06-28 draft-ietf-nfsv4-federated-fs-admin-11 Alan DeKok 2012-08-23 draft-ietf-mmusic-media-loopback-22 Donald Eastlake 2012-08-24 draft-ietf-pce-hierarchy-fwk-04 Phillip Hallam-Baker 2012-09-03 draft-kumaki-murai-l3vpn-rsvp-te-06 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-02 Leif Johansson 2012-08-29 draft-ietf-ccamp-assoc-ext-04 Charlie Kaufman 2012-08-29 draft-ietf-eai-mailinglistbis-05 Scott Kelly - draft-ietf-httpbis-p5-range-20 Stephen Kent - draft-ietf-httpbis-p7-auth-20 Tero Kivinen - draft-ietf-httpbis-p6-cache-20 Warren Kumari 2012-09-03 draft-ietf-mpls-entropy-label-05 Julien Laganier 2012-08-29 draft-ietf-sieve-imap-sieve-06 Eric Rescorla 2012-07-25 draft-ietf-websec-strict-transport-sec-12 Tom Yu 2012-08-22 draft-ietf-manet-olsrv2-15 Glen Zorn 2012-06-27 draft-hoffman-tao4677bis-16 Glen Zorn 2012-08-14 draft-ietf-mptcp-api-05 From bill.wu@huawei.com Tue Aug 21 21:12:23 2012 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 EFDF811E80AE; Tue, 21 Aug 2012 21:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.342 X-Spam-Level: X-Spam-Status: No, score=-3.342 tagged_above=-999 required=5 tests=[AWL=-0.509, BAYES_00=-2.599, FAKE_REPLY_C=2.012, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umrqsz7o8V2V; Tue, 21 Aug 2012 21:12:23 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id CCAEE11E80AD; Tue, 21 Aug 2012 21:12:22 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfwdlp01-ep.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJT09846; Tue, 21 Aug 2012 20:12:22 -0800 (PST) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 21 Aug 2012 21:05:13 -0700 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 21 Aug 2012 21:05:11 -0700 Received: from w53375 (10.138.41.149) by szxeml411-hub.china.huawei.com (10.82.67.138) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 22 Aug 2012 12:05:01 +0800 Message-ID: From: Qin Wu To: , , The IESG , Tina TSOU Date: Wed, 22 Aug 2012 12:05:00 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0127_01CD805E.5B00C270" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Subject: Re: [secdir] Secdir review of draft-ietf-avtcore-monarch-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 04:12:24 -0000 ------=_NextPart_000_0127_01CD805E.5B00C270 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksVGVuYToNClRoZSBzZWN1cml0eSBzZWN0aW9uIG9mIG1vbmFyY2ggZHJhZnQgaXMgY29uc2lz dGVudCB3aXRoIFJGQzM2MTEgYW5kIGRvZXNuJ3QgY29uZmxpY3Qgd2l0aCB0aGUgc2VjdXJpdHkg c2VjdGlvbiBvZiBSRkMzNjExLg0KVGhlIDJuZCBwYXJhZ3JhcGggaW4gc2VjdXJpdHkgc2VjdGlv biBvZiBtb25hcmNoIGRyYWZ0LCAgaXQgdGFsa3MgYWJvdXQgc2Vuc2l0aXZlIGluZm9ybWF0aW9u IGV4cG9zdGluZywgd2hpY2ggc2FpZDoNCiINCiAgIEluIFJUUCBzZXNzaW9ucywgYSBSVFAgc3lz dGVtIG1heSB1c2UgaXRzIG93biBTU1JDIHRvIHNlbmQgaXRzDQogICBtb25pdG9yaW5nIHJlcG9y dHMgdG93YXJkcyBpdHMgbmV4dC1uZWlnaGJvdXIgUlRQIHN5c3RlbS4gIE90aGVyIFJUUA0KICAg c3lzdGVtIGluIHRoZSBzZXNzaW9uIG1heSBoYXZlIGEgY2hvaWNlIGFzIHRvIHdoZXRoZXIgdGhl eSBmb3J3YXJkDQogICB0aGlzIFJUUCBzeXN0ZW0ncyBSVENQIHBhY2tldHMuICBUaGlzIHByZXNl bnQgYSBzZWN1cml0eSBpc3N1ZSBzaW5jZQ0KICAgdGhlIGluZm9ybWF0aW9uIGluIHRoZSByZXBv cnQgbWF5IGJlIGV4cG9zZWQgYnkgdGhlIG90aGVyIFJUUCBzeXN0ZW0NCiAgIHRvIGFueSBtYWxp Y2lvdXMgbm9kZS4gIFRoZXJlZm9yZSBpZiB0aGUgaW5mb3JtYXRpb24gaXMgY29uc2lkZXJlZCBh cw0KICAgc2Vuc2l0aXZlLCB0aGUgbW9uaXRvcmluZyByZXBvcnQgc2hvdWxkIGJlIGVuY3J5cHRl ZC4NCg0KIg0KdGhlIHJlc29sdXRpb24gaXMgdG8gdXNlIGVuY3J5cHRpb24uDQogDQpJbiB0aGUg NnRoIHBhcmFncmFwaCBpbiBzZWN1cml0eSBzZWN0aW9uIG9mIFJGQzM2MTEsIGl0IHRhbGtzIGFi b3V0IGRpc2FkdmFudGFnZSBvZiBlbmNyeXB0aW9uIG9mDQpYUiBibG9jaywgd2hpY2ggc2FpZDoN CiINCiAgIEFueSBlbmNyeXB0aW9uIG9yIGZpbHRlcmluZyBvZiBYUiByZXBvcnQgYmxvY2tzIGVu dGFpbHMgYSBsb3NzIG9mDQogICBtb25pdG9yaW5nIGluZm9ybWF0aW9uIHRvIHRoaXJkIHBhcnRp ZXMuICBGb3IgZXhhbXBsZSwgYSBuZXR3b3JrIHRoYXQNCiAgIGVzdGFibGlzaGVzIGEgdHVubmVs IHRvIGVuY3J5cHQgVm9JUCBSZXBvcnQgQmxvY2tzIGRlbmllcyB0aGF0DQogICBpbmZvcm1hdGlv biB0byB0aGUgc2VydmljZSBwcm92aWRlcnMgdHJhdmVyc2VkIGJ5IHRoZSB0dW5uZWwuICBUaGUN CiAgIHNlcnZpY2UgcHJvdmlkZXJzIGNhbm5vdCB0aGVuIG1vbml0b3Igb3IgcmVzcG9uZCB0byB0 aGUgcXVhbGl0eSBvZg0KICAgdGhlIFZvSVAgY2FsbHMgdGhhdCB0aGV5IGNhcnJ5LCBwb3RlbnRp YWxseSBjcmVhdGluZyBwcm9ibGVtcyBmb3IgdGhlDQogICBuZXR3b3JrJ3MgdXNlcnMuICBBcyBh IGRlZmF1bHQsIFhSIHBhY2tldHMgc2hvdWxkIG5vdCBiZSBlbmNyeXB0ZWQgb3INCiAgIGZpbHRl cmVkLg0KIg0KUkZDMzYxMSBzYWlkLCBpdCBpcyBhdCBkZWZhdWx0IHRvIHNldCBYUiBwYWNrZXQg bm8gZW5jcnlwdGVkLiBCdXQgaXQgZG9lc24ndCBzYXkgZW5jcnlwdGlvbiBpcyBwcm9oaWJpdGVk IGluIGFueSBjaXJjdW1zdGFuY2UuDQoNClRvIGNsZWFyIHlvdXIgY29uZnVzaW9uIHRvIHRoaXMs IEkgbGlrZSB0byBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgY2hhbmdlIHRvIHRoZSAybmQgcGFyYWdy YXBoIGluIHNlY3VyaXR5IHNlY3Rpb24gb2YgbW9uYXJjaCBkcmFmdA0KT0xEIFRFWFQ6DQoiDQpU aGVyZWZvcmUgaWYgdGhlIGluZm9ybWF0aW9uIGlzIGNvbnNpZGVyZWQgYXMNCiBzZW5zaXRpdmUs IHRoZSBtb25pdG9yaW5nIHJlcG9ydCBzaG91bGQgYmUgZW5jcnlwdGVkLg0KIg0KDQpORVcgVEVY VDoNCiINClRoZXJlZm9yZSBpZiB0aGUgaW5mb3JtYXRpb24gaXMgY29uc2lkZXJlZCBhcw0Kc2Vu c2l0aXZlLCBlbmNyeXB0aW9uIG9mIHRoZSBtb25pdG9yaW5nIHJlcG9ydCBpcyByZWNvbW1lbmRl ZC4NCiINCkhvcGUgdGhpcyBhZGRyZXNzZXMgeW91ciBjb21tZW50cy4NCg0KUmVnYXJkcyENCi1R aW4NCg0KPlRvOiBUaGUgSUVTRyA8aWVzZyBhdCBpZXRmLm9yZz4sICJzZWNkaXIgYXQgaWV0Zi5v cmciIDxzZWNkaXIgYXQgaWV0Zi5vcmc+LCAiZHJhZnQtaWV0Zi1hdnRjb3JlLW1vbmFyY2ggYXQg dG9vbHMuaWV0Zi5vcmciIDxkcmFmdC1pZXRmLWF2dGNvcmUtbW9uYXJjaCBhdCB0b29scy5pZXRm Lm9yZz4gDQo+U3ViamVjdDogW3NlY2Rpcl0gU2VjZGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLWF2 dGNvcmUtbW9uYXJjaC0xNyANCj5Gcm9tOiBUaW5hIFRTT1UgPFRpbmEuVHNvdS5ab3V0aW5nIGF0 IGh1YXdlaS5jb20+IA0KDQo+SGVsbG8sDQoNCj5JIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVu dCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRv IHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiAg VGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2Yg dGhlID5zZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4gRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hh aXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3Qg Y2FsbCBjb21tZW50cy4NCg0KPkRyYWZ0LWlldGYtYXZ0Y29yZS1tb25hcmNoLTE3IGFzIGEgd2hv bGUgcHJvdmlkZXMgdXNlZnVsIGFkdmljZS4gDQo+VGhlcmUgYXJlIGEgbnVtYmVyIG9mIGVkaXRv cmlhbCBuaXRzIHRoYXQgd2lsbCBiZSBwcm92aWRlZCB0byB0aGUgYXV0aG9ycyBpbiBhIHNlcGFy YXRlIEUtbWFpbC4NCg0KPlVuZm9ydHVuYXRlbHksIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9u cyBzZWN0aW9uIGZhaWxzIHRvIGFwcHJlY2lhdGUgYm90aCB0aGUgbW9yZSBudWFuY2VkIHZpZXcg YW5kIHRoZSBjb250cmFkaWN0aW9uIGV4aGliaXRlZCBieSB0aGUgc2FtZSBzZWN0aW9uIG9mIFJG QyAzNjExLCB0byB3aGljaCBpdCByZWZlcnMuIE9uIHRoZSBvbmUgaGFuZCwgdGhlID5tZWFzdXJl bWVudHMgcmVwb3J0ZWQgaW4gWFIgYmxvY2tzIGNvdWxkIGJlIHNlbnNpdGl2ZSBhbmQgb25lIG1p Z2h0IHdpc2ggdG8gcHJvdmlkZSB0aGVtIHdpdGggY29uZmlkZW50aWFsaXR5LiBPbiB0aGUgb3Ro ZXIgaGFuZCwgaW50ZXJtZWRpYXRlIHBhcnRpZXMgbWF5IGhhdmUgbGVnaXRpbWF0ZSByZWFzb25z IHRvIHZpZXcgdGhlID5tZWFzdXJlbWVudHMsIHNvIHRoYXQgZW5kLXRvLWVuZCBlbmNyeXB0aW9u IGlzIG5vdCBhbHdheXMgZGVzaXJhYmxlLg0KDQo+SXQgd291bGQgYmUgaGVscGZ1bCBmb3IgdGhp cyBkb2N1bWVudCB0byBkaXNjdXNzIHRoZSB0cnVzdCBtb2RlbHMgdGhhdCBtaWdodCBiZSBlbmNv dW50ZXJlZCBpbiBvcGVyYXRpb24sIGFuZCBob3cgY29uZmlkZW50aWFsaXR5IGFuZCBhdXRob3Jp emVkIHVzYWdlIGNvdWxkIGNvLWV4aXN0IHdpdGhpbiB0aGVzZSBtb2RlbHMuIE9mIGNvdXJzZSwg aXQgbWF5ID5iZSBsZWdpdGltYXRlIHRvIGNvbmNsdWRlIHRoYXQgdW5kZXIgc29tZSBjaXJjdW1z dGFuY2VzIHN1Y2ggY29leGlzdGVuY2UgbWF5IGJlIGltcG9zc2libGUsIGFuZCBsb2NhbCBwb2xp Y3kgbWF5IHRoZXJlZm9yZSBiZSBlaXRoZXIgdG8gc3VwcHJlc3MgdGhlIG1lYXN1cmVtZW50cyBv ciBhY2NlcHQgdGhlIGNvbnNlcXVlbmNlcyBvZiB0aGVpciA+ZGlzY2xvc3VyZS4NCg0KPlRpbmE= ------=_NextPart_000_0127_01CD805E.5B00C270 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250 ZW50PSJNU0hUTUwgOC4wMC42MDAxLjE5MjU4Ij4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFEPg0K PEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PkhpLFRlbmE6PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PlRoZSBzZWN1cml0eSBzZWN0aW9uIG9mIG1vbmFyY2ggZHJhZnQgaXMgDQpjb25zaXN0ZW50IHdp dGggUkZDMzYxMSBhbmQgZG9lc24ndCBjb25mbGljdCB3aXRoIHRoZSBzZWN1cml0eSBzZWN0aW9u IG9mIA0KUkZDMzYxMS48QlI+VGhlIDJuZCBwYXJhZ3JhcGggaW4gc2VjdXJpdHkgc2VjdGlvbiBv ZiBtb25hcmNoIGRyYWZ0LCZuYnNwOyBpdCANCnRhbGtzIGFib3V0IHNlbnNpdGl2ZSBpbmZvcm1h dGlvbiBleHBvc3RpbmcsIHdoaWNoIHNhaWQ6PEJSPiI8QlI+Jm5ic3A7Jm5ic3A7IEluIA0KUlRQ IHNlc3Npb25zLCBhIFJUUCBzeXN0ZW0gbWF5IHVzZSBpdHMgb3duIFNTUkMgdG8gc2VuZCBpdHM8 QlI+Jm5ic3A7Jm5ic3A7IA0KbW9uaXRvcmluZyByZXBvcnRzIHRvd2FyZHMgaXRzIG5leHQtbmVp Z2hib3VyIFJUUCBzeXN0ZW0uJm5ic3A7IE90aGVyIA0KUlRQPEJSPiZuYnNwOyZuYnNwOyBzeXN0 ZW0gaW4gdGhlIHNlc3Npb24gbWF5IGhhdmUgYSBjaG9pY2UgYXMgdG8gd2hldGhlciB0aGV5IA0K Zm9yd2FyZDxCUj4mbmJzcDsmbmJzcDsgdGhpcyBSVFAgc3lzdGVtJ3MgUlRDUCBwYWNrZXRzLiZu YnNwOyBUaGlzIHByZXNlbnQgYSANCnNlY3VyaXR5IGlzc3VlIHNpbmNlPEJSPiZuYnNwOyZuYnNw OyB0aGUgaW5mb3JtYXRpb24gaW4gdGhlIHJlcG9ydCBtYXkgYmUgDQpleHBvc2VkIGJ5IHRoZSBv dGhlciBSVFAgc3lzdGVtPEJSPiZuYnNwOyZuYnNwOyB0byBhbnkgbWFsaWNpb3VzIG5vZGUuJm5i c3A7IA0KVGhlcmVmb3JlIGlmIHRoZSBpbmZvcm1hdGlvbiBpcyBjb25zaWRlcmVkIGFzPEJSPiZu YnNwOyZuYnNwOyBzZW5zaXRpdmUsIHRoZSANCm1vbml0b3JpbmcgcmVwb3J0IHNob3VsZCBiZSBl bmNyeXB0ZWQuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4i PEJSPnRoZSByZXNvbHV0aW9uIGlzIHRvIHVzZSANCmVuY3J5cHRpb24uPEJSPiZuYnNwOzxCUj5J biB0aGUgNnRoIHBhcmFncmFwaCBpbiBzZWN1cml0eSBzZWN0aW9uIG9mIFJGQzM2MTEsIGl0IA0K dGFsa3MgYWJvdXQgZGlzYWR2YW50YWdlIG9mIGVuY3J5cHRpb24gb2Y8QlI+WFIgYmxvY2ssIHdo aWNoIA0Kc2FpZDo8QlI+IjxCUj4mbmJzcDsmbmJzcDsgQW55IGVuY3J5cHRpb24gb3IgZmlsdGVy aW5nIG9mIFhSIHJlcG9ydCBibG9ja3MgDQplbnRhaWxzIGEgbG9zcyBvZjxCUj4mbmJzcDsmbmJz cDsgbW9uaXRvcmluZyBpbmZvcm1hdGlvbiB0byB0aGlyZCBwYXJ0aWVzLiZuYnNwOyANCkZvciBl eGFtcGxlLCBhIG5ldHdvcmsgdGhhdDxCUj4mbmJzcDsmbmJzcDsgZXN0YWJsaXNoZXMgYSB0dW5u ZWwgdG8gZW5jcnlwdCBWb0lQIA0KUmVwb3J0IEJsb2NrcyBkZW5pZXMgdGhhdDxCUj4mbmJzcDsm bmJzcDsgaW5mb3JtYXRpb24gdG8gdGhlIHNlcnZpY2UgcHJvdmlkZXJzIA0KdHJhdmVyc2VkIGJ5 IHRoZSB0dW5uZWwuJm5ic3A7IFRoZTxCUj4mbmJzcDsmbmJzcDsgc2VydmljZSBwcm92aWRlcnMg Y2Fubm90IHRoZW4gDQptb25pdG9yIG9yIHJlc3BvbmQgdG8gdGhlIHF1YWxpdHkgb2Y8QlI+Jm5i c3A7Jm5ic3A7IHRoZSBWb0lQIGNhbGxzIHRoYXQgdGhleSANCmNhcnJ5LCBwb3RlbnRpYWxseSBj cmVhdGluZyBwcm9ibGVtcyBmb3IgdGhlPEJSPiZuYnNwOyZuYnNwOyBuZXR3b3JrJ3MgDQp1c2Vy cy4mbmJzcDsgQXMgYSBkZWZhdWx0LCBYUiBwYWNrZXRzIHNob3VsZCBub3QgYmUgZW5jcnlwdGVk IG9yPEJSPiZuYnNwOyZuYnNwOyANCmZpbHRlcmVkLjxCUj4iPEJSPlJGQzM2MTEgc2FpZCwgaXQg aXMgYXQgZGVmYXVsdCB0byBzZXQgWFIgcGFja2V0IG5vIGVuY3J5cHRlZC4gDQpCdXQgaXQgZG9l c24ndCBzYXkgZW5jcnlwdGlvbiBpcyBwcm9oaWJpdGVkIGluIGFueSANCmNpcmN1bXN0YW5jZS48 QlI+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPlRvIGNs ZWFyIHlvdXIgY29uZnVzaW9uIHRvIHRoaXMsIEkgbGlrZSB0byANCnByb3Bvc2UgdGhlIGZvbGxv d2luZyBjaGFuZ2UgdG8gdGhlIDJuZCBwYXJhZ3JhcGggaW4gc2VjdXJpdHkgc2VjdGlvbiBvZiBt b25hcmNoIA0KZHJhZnQ8QlI+T0xEIFRFWFQ6PEJSPiI8QlI+VGhlcmVmb3JlIGlmIHRoZSBpbmZv cm1hdGlvbiBpcyBjb25zaWRlcmVkIA0KYXM8QlI+Jm5ic3A7c2Vuc2l0aXZlLCB0aGUgbW9uaXRv cmluZyByZXBvcnQgc2hvdWxkIGJlIGVuY3J5cHRlZC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+TkVXIFRFWFQ6PEJSPiI8QlI+VGhlcmVmb3JlIGlmIHRoZSBpbmZvcm1h dGlvbiANCmlzIGNvbnNpZGVyZWQgYXM8QlI+c2Vuc2l0aXZlLCBlbmNyeXB0aW9uIG9mIHRoZSBt b25pdG9yaW5nIHJlcG9ydCBpcyANCnJlY29tbWVuZGVkLjxCUj4iPC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkhvcGUgdGhpcyBhZGRyZXNzZXMgeW91ciAN CmNvbW1lbnRzLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ UmVnYXJkcyE8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ LVFpbjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jmd0O1Rv OiBUaGUgSUVTRyAmbHQ7aWVzZyBhdCBpZXRmLm9yZyZndDssIA0KInNlY2RpciBhdCBpZXRmLm9y ZyIgJmx0O3NlY2RpciBhdCBpZXRmLm9yZyZndDssICJkcmFmdC1pZXRmLWF2dGNvcmUtbW9uYXJj aCBhdCANCnRvb2xzLmlldGYub3JnIiAmbHQ7ZHJhZnQtaWV0Zi1hdnRjb3JlLW1vbmFyY2ggYXQg dG9vbHMuaWV0Zi5vcmcmZ3Q7IA0KPEJSPiZndDtTdWJqZWN0OiBbc2VjZGlyXSBTZWNkaXIgcmV2 aWV3IG9mIGRyYWZ0LWlldGYtYXZ0Y29yZS1tb25hcmNoLTE3IA0KPEJSPiZndDtGcm9tOiBUaW5h IFRTT1UgJmx0O1RpbmEuVHNvdS5ab3V0aW5nIGF0IGh1YXdlaS5jb20mZ3Q7IDwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jmd0O0hlbGxvLDwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jmd0O0kgaGF2ZSByZXZpZXdlZCB0 aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgDQp0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyBvbmdv aW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIA0KcHJvY2Vzc2Vk IGJ5IHRoZSBJRVNHLiZuYnNwOyBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5 IGZvciB0aGUgDQpiZW5lZml0IG9mIHRoZSAmZ3Q7c2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMuIERv Y3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyANCnNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50 cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy48L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZndDtEcmFmdC1pZXRmLWF2dGNvcmUtbW9u YXJjaC0xNyBhcyBhIHdob2xlIA0KcHJvdmlkZXMgdXNlZnVsIGFkdmljZS4gPEJSPiZndDtUaGVy ZSBhcmUgYSBudW1iZXIgb2YgZWRpdG9yaWFsIG5pdHMgdGhhdCB3aWxsIA0KYmUgcHJvdmlkZWQg dG8gdGhlIGF1dGhvcnMgaW4gYSBzZXBhcmF0ZSBFLW1haWwuPC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mZ3Q7VW5mb3J0dW5hdGVseSwgdGhlIFNlY3VyaXR5 IENvbnNpZGVyYXRpb25zIA0Kc2VjdGlvbiBmYWlscyB0byBhcHByZWNpYXRlIGJvdGggdGhlIG1v cmUgbnVhbmNlZCB2aWV3IGFuZCB0aGUgY29udHJhZGljdGlvbiANCmV4aGliaXRlZCBieSB0aGUg c2FtZSBzZWN0aW9uIG9mIFJGQyAzNjExLCB0byB3aGljaCBpdCByZWZlcnMuIE9uIHRoZSBvbmUg aGFuZCwgDQp0aGUgJmd0O21lYXN1cmVtZW50cyByZXBvcnRlZCBpbiBYUiBibG9ja3MgY291bGQg YmUgc2Vuc2l0aXZlIGFuZCBvbmUgbWlnaHQgd2lzaCANCnRvIHByb3ZpZGUgdGhlbSB3aXRoIGNv bmZpZGVudGlhbGl0eS4gT24gdGhlIG90aGVyIGhhbmQsIGludGVybWVkaWF0ZSBwYXJ0aWVzIA0K bWF5IGhhdmUgbGVnaXRpbWF0ZSByZWFzb25zIHRvIHZpZXcgdGhlICZndDttZWFzdXJlbWVudHMs IHNvIHRoYXQgZW5kLXRvLWVuZCANCmVuY3J5cHRpb24gaXMgbm90IGFsd2F5cyBkZXNpcmFibGUu PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjwvRk9OVD4m bmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mZ3Q7SXQgd291 bGQgYmUgaGVscGZ1bCBmb3IgdGhpcyBkb2N1bWVudCB0byANCmRpc2N1c3MgdGhlIHRydXN0IG1v ZGVscyB0aGF0IG1pZ2h0IGJlIGVuY291bnRlcmVkIGluIG9wZXJhdGlvbiwgYW5kIGhvdyANCmNv bmZpZGVudGlhbGl0eSBhbmQgYXV0aG9yaXplZCB1c2FnZSBjb3VsZCBjby1leGlzdCB3aXRoaW4g dGhlc2UgbW9kZWxzLiBPZiANCmNvdXJzZSwgaXQgbWF5ICZndDtiZSBsZWdpdGltYXRlIHRvIGNv bmNsdWRlIHRoYXQgdW5kZXIgc29tZSBjaXJjdW1zdGFuY2VzIHN1Y2ggDQpjb2V4aXN0ZW5jZSBt YXkgYmUgaW1wb3NzaWJsZSwgYW5kIGxvY2FsIHBvbGljeSBtYXkgdGhlcmVmb3JlIGJlIGVpdGhl ciB0byANCnN1cHByZXNzIHRoZSBtZWFzdXJlbWVudHMgb3IgYWNjZXB0IHRoZSBjb25zZXF1ZW5j ZXMgb2YgdGhlaXIgDQomZ3Q7ZGlzY2xvc3VyZS48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPiZndDtUaW5hPC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0127_01CD805E.5B00C270-- From Tina.Tsou.Zouting@huawei.com Tue Aug 21 21:45:03 2012 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 86B6C11E80D2; Tue, 21 Aug 2012 21:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.072 X-Spam-Level: X-Spam-Status: No, score=-6.072 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ioKN-u2i1L+U; Tue, 21 Aug 2012 21:44:53 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2970211E80A2; Tue, 21 Aug 2012 21:44:52 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJJ11701; Tue, 21 Aug 2012 20:44:50 -0800 (PST) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 21 Aug 2012 21:39:37 -0700 Received: from dfweml513-mbx.china.huawei.com ([169.254.3.159]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.003; Tue, 21 Aug 2012 21:39:29 -0700 From: Tina TSOU To: Qin Wu Thread-Topic: [secdir] Secdir review of draft-ietf-avtcore-monarch-17 Thread-Index: AQHNgBtTN3CPcwvDt0SdX/BDBNBFzZdlQAPe Date: Wed, 22 Aug 2012 04:39:28 +0000 Message-ID: <58D08DCC-37CD-4DE9-A574-719F5409153C@huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_58D08DCC37CD4DE9A574719F5409153Chuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: The IESG , "draft-ietf-avtcore-monarch@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-avtcore-monarch-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 04:45:03 -0000 --_000_58D08DCC37CD4DE9A574719F5409153Chuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is what I meant: which parties trust each other? The other parties will be excluded from receiving the measurements. What does each case imply in terms of requirements for key management? To be concrete, one case is where only the end systems trust each other. In that case, one assumes that no intermediate systems are required, and clearly third-party monitors are excluded from receiving the information. Keys have to be negotiated directly between the end systems. A second case is where intermediate systems are also trusted. Here a hop-by= -hop security model is practical, where keys are negotiated between success= ive neighbours along the path. An alternative would be a group key manageme= nt scheme (RFC 6407), such that all participants receive the same session-b= ased key. The choice between these schemes would depend amongst other thing= s on whether the communication spans multiple trust domains. In this case, = third-party monitors are still excluded. A final case is where third party monitors are allowed access to the RTCP f= lows. In this case, the basic issue is how to arrange for participation of = the third party monitor in key negotiation. If it is introduced in man-in-t= he-middle fashion into negotiations between its upstream and downstream nei= ghbours, care has to be taken that no compromised device can do the same th= ing. A group key management scheme including the third party monitor and it= s neighbours might safer. An interesting side-issue is whether devices might be partially trusted, so= that they are allowed access to some information but not the rest. This pr= obably lies beyond the scope of the present document, but please give it a = moment's thought. Tina On Aug 21, 2012, at 9:05 PM, "Qin Wu" > wrote: Hi,Tena: The security section of monarch draft is consistent with RFC3611 and doesn'= t conflict with the security section of RFC3611. The 2nd paragraph in security section of monarch draft, it talks about sen= sitive information exposting, which said: " In RTP sessions, a RTP system may use its own SSRC to send its monitoring reports towards its next-neighbour RTP system. Other RTP system in the session may have a choice as to whether they forward this RTP system's RTCP packets. This present a security issue since the information in the report may be exposed by the other RTP system to any malicious node. Therefore if the information is considered as sensitive, the monitoring report should be encrypted. " the resolution is to use encryption. In the 6th paragraph in security section of RFC3611, it talks about disadva= ntage of encryption of XR block, which said: " Any encryption or filtering of XR report blocks entails a loss of monitoring information to third parties. For example, a network that establishes a tunnel to encrypt VoIP Report Blocks denies that information to the service providers traversed by the tunnel. The service providers cannot then monitor or respond to the quality of the VoIP calls that they carry, potentially creating problems for the network's users. As a default, XR packets should not be encrypted or filtered. " RFC3611 said, it is at default to set XR packet no encrypted. But it doesn'= t say encryption is prohibited in any circumstance. To clear your confusion to this, I like to propose the following change to = the 2nd paragraph in security section of monarch draft OLD TEXT: " Therefore if the information is considered as sensitive, the monitoring report should be encrypted. " NEW TEXT: " Therefore if the information is considered as sensitive, encryption of the monitoring report is recommended. " Hope this addresses your comments. Regards! -Qin >To: The IESG >, "secdir at ietf.org" >, "draft-ietf-avtcore-mo= narch at tools.ietf.org" > >Subject: [secdir] Secdir review of draft-ietf-avtcore-monarch-17 >From: Tina TSOU > >Hello, >I have reviewed this document as part of the security directorate's ongoin= g effort to review all IETF documents being processed by the IESG. These c= omments were written primarily for the benefit of the >security area direct= ors. Document editors and WG chairs should treat these comments just like a= ny other last call comments. >Draft-ietf-avtcore-monarch-17 as a whole provides useful advice. >There are a number of editorial nits that will be provided to the authors = in a separate E-mail. >Unfortunately, the Security Considerations section fails to appreciate bot= h the more nuanced view and the contradiction exhibited by the same section= of RFC 3611, to which it refers. On the one hand, the >measurements report= ed in XR blocks could be sensitive and one might wish to provide them with = confidentiality. On the other hand, intermediate parties may have legitimat= e reasons to view the >measurements, so that end-to-end encryption is not a= lways desirable. >It would be helpful for this document to discuss the trust models that mig= ht be encountered in operation, and how confidentiality and authorized usag= e could co-exist within these models. Of course, it may >be legitimate to c= onclude that under some circumstances such coexistence may be impossible, a= nd local policy may therefore be either to suppress the measurements or acc= ept the consequences of their >disclosure. >Tina --_000_58D08DCC37CD4DE9A574719F5409153Chuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Here is what I meant: which parties trust each other? The other partie= s
will be excluded from receiving the measurements. What does each case=
imply in terms of requirements for key management?

To be concrete, one case is where only the end systems trust each oth= er.
In that case, one assumes that no intermediate systems are required, = and
clearly third-party monitors are excluded from receiving the information. Keys have to be negotiated directly between the end syst= ems.

A second case is where intermediate systems are also trusted. Here a = hop-by-hop security model is practical, where keys are negotiated between s= uccessive neighbours along the path. An alternative would be a group key ma= nagement scheme (RFC 6407), such that all participants receive the same session-based key. The choice betwe= en these schemes would depend amongst other things on whether the communica= tion spans multiple trust domains. In this case, third-party monitors are s= till excluded.

A final case is where third party monitors are allowed access to the = RTCP flows. In this case, the basic issue is how to arrange for participati= on of the third party monitor in key negotiation. If it is introduced in ma= n-in-the-middle fashion into negotiations between its upstream and downstream neighbours, care has to be taken that = no compromised device can do the same thing. A group key management scheme = including the third party monitor and its neighbours might safer.
An interesting side-issue is whether devices might be partially trusted, so= that they are allowed access to some information but not the rest. This pr= obably lies beyond the scope of the present document, but please give it a = moment's thought.

Tina

On Aug 21, 2012, at 9:05 PM, "Qin Wu" <bill.wu@huawei.com> wrote:

Hi,Tena:
The security section of monarch draft i= s consistent with RFC3611 and doesn't conflict with the security section of= RFC3611.
The 2nd paragraph in security section of monarch draft,  it talks abou= t sensitive information exposting, which said:
"
   In RTP sessions, a RTP system may use its own SSRC to send its=
   monitoring reports towards its next-neighbour RTP system. = ; Other RTP
   system in the session may have a choice as to whether they for= ward
   this RTP system's RTCP packets.  This present a security = issue since
   the information in the report may be exposed by the other RTP = system
   to any malicious node.  Therefore if the information is c= onsidered as
   sensitive, the monitoring report should be encrypted.
 
"
the resolution is to use encryption.
 
In the 6th paragraph in security section of RFC3611, it talks about disadva= ntage of encryption of
XR block, which said:
"
   Any encryption or filtering of XR report blocks entails a loss= of
   monitoring information to third parties.  For example, a = network that
   establishes a tunnel to encrypt VoIP Report Blocks denies that=
   information to the service providers traversed by the tunnel.&= nbsp; The
   service providers cannot then monitor or respond to the qualit= y of
   the VoIP calls that they carry, potentially creating problems = for the
   network's users.  As a default, XR packets should not be = encrypted or
   filtered.
"
RFC3611 said, it is at default to set XR packet no encrypted. But it doesn'= t say encryption is prohibited in any circumstance.
To clear your confusion to this, I like= to propose the following change to the 2nd paragraph in security section o= f monarch draft
OLD TEXT:
"
Therefore if the information is considered as
 sensitive, the monitoring report should be encrypted.
"
 
NEW TEXT:
"
Therefore if the information is considered as
sensitive, encryption of the monitoring report is recommended.
"
Hope this addresses your comments.
 
Regards!
-Qin
 
>To: The IESG <iesg at ietf.org>, "secdir at ietf.org&= quot; <secdir at ietf.org>, "draft-ietf-avtcore-monarch at tools.ietf.org" <draft-ietf-avtcore-monarch at tools.ietf.org>
>Subject: [secdir] Secdir review of draft-ietf-avtcore-monarch-17
>From: Tina TSOU <Tina.Tsou.Zouting at = huawei.com>
 
>Hello,
 
>I have reviewed this document as pa= rt of the security directorate's ongoing effort to review all IETF document= s 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 o= ther last call comments.
 
>Draft-ietf-avtcore-monarch-17 as a = whole provides useful advice.
>There are a number of editorial nits that will be provided to the autho= rs in a separate E-mail.
 
>Unfortunately, the Security Conside= rations section fails to appreciate both the more nuanced view and the cont= radiction exhibited by the same section of RFC 3611, to which it refers. On= the one hand, the >measurements reported in XR blocks could be sensitive and one might wish to provide them with co= nfidentiality. On the other hand, intermediate parties may have legitimate = reasons to view the >measurements, so that end-to-end encryption is not = always desirable.
 
>It would be helpful for this docume= nt to discuss the trust models that might be encountered in operation, and = how confidentiality and authorized usage could co-exist within these models= . Of course, it may >be legitimate to conclude that under some circumstances such coexistence may be impossible,= and local policy may therefore be either to suppress the measurements or a= ccept the consequences of their >disclosure.
 
>Tina
--_000_58D08DCC37CD4DE9A574719F5409153Chuaweicom_-- From bill.wu@huawei.com Tue Aug 21 23:54:47 2012 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 3FFEA21F852C; Tue, 21 Aug 2012 23:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.342 X-Spam-Level: X-Spam-Status: No, score=-4.342 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2CUz1-GjQKn; Tue, 21 Aug 2012 23:54:46 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id CE58721F8534; Tue, 21 Aug 2012 23:54:45 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJU00149; Tue, 21 Aug 2012 22:54:45 -0800 (PST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 21 Aug 2012 23:46:59 -0700 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 21 Aug 2012 23:46:57 -0700 Received: from w53375 (10.138.41.149) by szxeml421-hub.china.huawei.com (10.82.67.160) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 22 Aug 2012 14:46:48 +0800 Message-ID: From: Qin Wu To: Tina TSOU References: <58D08DCC-37CD-4DE9-A574-719F5409153C@huawei.com> Date: Wed, 22 Aug 2012 14:46:48 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01F4_01CD8074.F5318F80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Cc: The IESG , draft-ietf-avtcore-monarch@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-avtcore-monarch-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 06:54:47 -0000 ------=_NextPart_000_01F4_01CD8074.F5318F80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCiAgRnJvbTogVGluYSBUU09VIA0KICBUbzog UWluIFd1IA0KICBDYzogZHJhZnQtaWV0Zi1hdnRjb3JlLW1vbmFyY2hAdG9vbHMuaWV0Zi5vcmcg OyBzZWNkaXJAaWV0Zi5vcmcgOyBUaGUgSUVTRyANCiAgU2VudDogV2VkbmVzZGF5LCBBdWd1c3Qg MjIsIDIwMTIgMTI6MzkgUE0NCiAgU3ViamVjdDogUmU6IFtzZWNkaXJdIFNlY2RpciByZXZpZXcg b2YgZHJhZnQtaWV0Zi1hdnRjb3JlLW1vbmFyY2gtMTcNCg0KDQogIEhlcmUgaXMgd2hhdCBJIG1l YW50OiB3aGljaCBwYXJ0aWVzIHRydXN0IGVhY2ggb3RoZXI/IFRoZSBvdGhlciBwYXJ0aWVzDQog IHdpbGwgYmUgZXhjbHVkZWQgZnJvbSByZWNlaXZpbmcgdGhlIG1lYXN1cmVtZW50cy4gV2hhdCBk b2VzIGVhY2ggY2FzZQ0KICBpbXBseSBpbiB0ZXJtcyBvZiByZXF1aXJlbWVudHMgZm9yIGtleSBt YW5hZ2VtZW50Pw0KDQoNCltRaW5dOiBJZiB0aGUgb3RoZXIgcGFydGllcyBhcmUgYWxsb3dlZCB0 byByZWNlaXZlIHRoZSBtZWFzdXJlbWVudCwgdGhleSBzaG91bGQgYmUgYXV0aGVudGljYXRlZCB1 c2luZyBTUlRQIGluIFJGQzM3MTEuDQpJZiB0aGUgcGFydGllcyB0aGF0IGFyZSB0cnVzdGVkIGFj Y2VzcyB0byBzb21lIFJUQ1AgZmxvd3MgYnV0IG5vdCBvdGhlciwgYXV0aGVudGljYXRpb24gdXNp bmcgU1JUUCBpbiBSRkMzNzExIGFsc28gY2FuIGJlIHVzZWQuDQpSZWdhcmRpbmcga2V5IG1hbmFn bWVudCByZXF1aXJlbWVudCwgIFJGQyAzNzExIGhhcyBhbHJlYWR5IHBvaW50ZWQgb3V0IHdoYXQg a2V5IG1hbmFnZW1lbnQgc3RhbmRhcmRzIGNhbiBiZSB1c2VkIHRvIA0KZXN0YWJsaXNoIGFuIFNS VFAgY3J5cHRvZ3JhcGhpYyBjb250ZXh0Lg== ------=_NextPart_000_01F4_01CD8074.F5318F80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgbmFtZT1HRU5FUkFUT1Ig Y29udGVudD0iTVNIVE1MIDguMDAuNjAwMS4xOTI1OCI+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAt LS0tLSA8L0RJVj4NCjxCTE9DS1FVT1RFIA0Kc3R5bGU9IkJPUkRFUi1MRUZUOiAjMDAwMDAwIDJw eCBzb2xpZDsgUEFERElORy1MRUZUOiA1cHg7IFBBRERJTkctUklHSFQ6IDBweDsgTUFSR0lOLUxF RlQ6IDVweDsgTUFSR0lOLVJJR0hUOiAwcHgiIA0KZGlyPWx0cj4NCiAgPERJViBzdHlsZT0iRk9O VDogOXB0ICYjMjM0MzU7JiMyMDMwNzs7IEJBQ0tHUk9VTkQ6ICNlNGU0ZTQ7IGZvbnQtY29sb3I6 IGJsYWNrIj48Qj5Gcm9tOjwvQj4gDQogIDxBIHRpdGxlPVRpbmEuVHNvdS5ab3V0aW5nQGh1YXdl aS5jb20gDQogIGhyZWY9Im1haWx0bzpUaW5hLlRzb3UuWm91dGluZ0BodWF3ZWkuY29tIj5UaW5h IFRTT1U8L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3 OyI+PEI+VG86PC9CPiA8QSB0aXRsZT1iaWxsLnd1QGh1YXdlaS5jb20gDQogIGhyZWY9Im1haWx0 bzpiaWxsLnd1QGh1YXdlaS5jb20iPlFpbiBXdTwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZP TlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5DYzo8L0I+IDxBIA0KICB0aXRsZT1kcmFmdC1p ZXRmLWF2dGNvcmUtbW9uYXJjaEB0b29scy5pZXRmLm9yZyANCiAgaHJlZj0ibWFpbHRvOmRyYWZ0 LWlldGYtYXZ0Y29yZS1tb25hcmNoQHRvb2xzLmlldGYub3JnIj5kcmFmdC1pZXRmLWF2dGNvcmUt bW9uYXJjaEB0b29scy5pZXRmLm9yZzwvQT4gDQogIDsgPEEgdGl0bGU9c2VjZGlyQGlldGYub3Jn IGhyZWY9Im1haWx0bzpzZWNkaXJAaWV0Zi5vcmciPnNlY2RpckBpZXRmLm9yZzwvQT4gOyANCiAg PEEgdGl0bGU9aWVzZ0BpZXRmLm9yZyBocmVmPSJtYWlsdG86aWVzZ0BpZXRmLm9yZyI+VGhlIElF U0c8L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+ PEI+U2VudDo8L0I+IFdlZG5lc2RheSwgQXVndXN0IDIyLCAyMDEyIDEyOjM5IA0KICBQTTwvRElW Pg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+U3ViamVjdDo8 L0I+IFJlOiBbc2VjZGlyXSBTZWNkaXIgcmV2aWV3IG9mIA0KICBkcmFmdC1pZXRmLWF2dGNvcmUt bW9uYXJjaC0xNzwvRElWPg0KICA8RElWPjxCUj48L0RJVj4NCiAgPERJVj5IZXJlIGlzIHdoYXQg SSBtZWFudDogd2hpY2ggcGFydGllcyB0cnVzdCBlYWNoIG90aGVyPyBUaGUgb3RoZXIgDQogIHBh cnRpZXM8QlI+PFNQQU4+d2lsbCBiZSBleGNsdWRlZCBmcm9tIHJlY2VpdmluZyB0aGUgbWVhc3Vy ZW1lbnRzLiBXaGF0IGRvZXMgDQogIGVhY2ggY2FzZTwvU1BBTj48QlI+PFNQQU4+aW1wbHkgaW4g dGVybXMgb2YgcmVxdWlyZW1lbnRzIGZvciBrZXkgDQogIG1hbmFnZW1lbnQ/PC9TUEFOPjxCUj48 U1BBTj48L1NQQU4+PEJSPjwvRElWPjwvQkxPQ0tRVU9URT4NCjxESVYgZGlyPWx0cj5bUWluXTog SWYgdGhlIG90aGVyIHBhcnRpZXMmbmJzcDthcmUgYWxsb3dlZCB0byByZWNlaXZlIHRoZSANCm1l YXN1cmVtZW50LCB0aGV5IHNob3VsZCBiZSBhdXRoZW50aWNhdGVkIHVzaW5nIFNSVFAgaW4gUkZD MzcxMS48L0RJVj4NCjxESVYgZGlyPWx0cj5JZiB0aGUgcGFydGllcyB0aGF0Jm5ic3A7YXJlIHRy dXN0ZWQgYWNjZXNzIHRvIHNvbWUgUlRDUCBmbG93cyBidXQgDQpub3Qgb3RoZXIsIGF1dGhlbnRp Y2F0aW9uIHVzaW5nIFNSVFAgaW4gUkZDMzcxMSBhbHNvIGNhbiBiZSB1c2VkLjwvRElWPg0KPERJ ViBkaXI9bHRyPlJlZ2FyZGluZyBrZXkgbWFuYWdtZW50IHJlcXVpcmVtZW50LCZuYnNwOyBSRkMg MzcxMSBoYXMgYWxyZWFkeSANCnBvaW50ZWQgb3V0IHdoYXQga2V5IG1hbmFnZW1lbnQgc3RhbmRh cmRzIGNhbiBiZSB1c2VkIHRvIDwvRElWPg0KPERJViBkaXI9bHRyPmVzdGFibGlzaCBhbiBTUlRQ IGNyeXB0b2dyYXBoaWMgY29udGV4dC48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_01F4_01CD8074.F5318F80-- From bill.wu@huawei.com Wed Aug 22 00:30:41 2012 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 A9E7721F8516; Wed, 22 Aug 2012 00:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 tagged_above=-999 required=5 tests=[AWL=-0.951, BAYES_00=-2.599, FAKE_REPLY_C=2.012, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZA4pQxVdC6d; Wed, 22 Aug 2012 00:30:37 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id B4BB421F8513; Wed, 22 Aug 2012 00:30:36 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfwdlp01-ep.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJU02176; Tue, 21 Aug 2012 23:30:35 -0800 (PST) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 22 Aug 2012 00:24:31 -0700 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 22 Aug 2012 00:24:29 -0700 Received: from w53375 (10.138.41.149) by szxeml407-hub.china.huawei.com (10.82.67.94) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 22 Aug 2012 15:24:25 +0800 Message-ID: <95BE189EF1EA49A5948DB07961604E80@china.huawei.com> From: Qin Wu To: Vincent Roca , The IESG , , Date: Wed, 22 Aug 2012 15:24:23 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02D6_01CD807A.35AEDC70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Subject: Re: [secdir] Secdir review of draft-ietf-xrblock-rtcp-xr-pdv-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 07:30:41 -0000 ------=_NextPart_000_02D6_01CD807A.35AEDC70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 T25lIG1vcmUgcG9pbnQgdG8gYWRkLCB5b3UgYXJlIGNvcnJlY3QgYWJvdXQgZm9yZ2VkIFBEViB2 YWx1ZXMsIGJ1dCB0aGlzIGNhbiBiZSBzb2x2ZWQgYnkgYXV0aGVudGljYXRpb24gdXNpbmcgU1JU UC4NCg0KUmVnYXJkcyENCi1RaW4NCiAgLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCiAg RnJvbTogUWluIFd1IA0KICBUbzogVmluY2VudCBSb2NhIDsgVGhlIElFU0cgOyBzZWNkaXJAaWV0 Zi5vcmcgOyBkcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1wZHYuYWxsQHRvb2xzLmlldGYub3Jn IA0KICBDYzogVmluY2VudCBSb2NhIA0KICBTZW50OiBGcmlkYXksIEF1Z3VzdCAxNywgMjAxMiAx MDozOCBBTQ0KICBTdWJqZWN0OiBSZTogU2VjZGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLXhyYmxv Y2stcnRjcC14ci1wZHYtMDMNCg0KDQogIEhpLFZpbmNlbnQ6DQogIFRoYW5rIGZvciB5b3VyIHJl dmlldywgcGxlYXNlIHNlZSBteSBjb21tZW50cyBpbmxpbmUgYmVsb3cuDQoNCiAgUmVnYXJkcyEN CiAgLVFpbg0KICAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KICBGcm9tOiAiVmluY2Vu dCBSb2NhIiA8dmluY2VudC5yb2NhQGlucmlhLmZyPg0KICBUbzogIlRoZSBJRVNHIiA8aWVzZ0Bp ZXRmLm9yZz47IDxzZWNkaXJAaWV0Zi5vcmc+OyA8ZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHIt cGR2LmFsbEB0b29scy5pZXRmLm9yZz4NCiAgQ2M6ICJWaW5jZW50IFJvY2EiIDx2aW5jZW50LnJv Y2FAaW5yaWEuZnI+DQogIFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMDIsIDIwMTIgNTozMSBBTQ0K ICBTdWJqZWN0OiBTZWNkaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYteHJibG9jay1ydGNwLXhyLXBk di0wMw0KDQoNCiAgPiBIZWxsbywNCiAgPiANCiAgPiBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1 bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzDQogID4gb25nb2luZyBl ZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhl DQogID4gSUVTRy4gIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRo ZSBiZW5lZml0IG9mIHRoZQ0KICA+IHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiBEb2N1bWVudCBl ZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0DQogID4gdGhlc2UgY29tbWVudHMganVz dCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQogID4gDQogID4gDQogID4gVGhl IGF1dGhvcnMgZXhwbGFpbiB0aGlzIGRvY3VtZW50IGludHJvZHVjZXMgbm8gbmV3IHNlY3VyaXR5 DQogID4gY29uc2lkZXJhdGlvbnMgYmV5b25kIHRob3NlIGRlc2NyaWJlZCBpbiBbUkZDMzYxMV0u DQogID4gSSBhZ3JlZSB0aGVyZSBpcyBubyBwcml2YWN5IHJpc2ssIGJ1dCBhIHF1ZXN0aW9uIEkn ZCBsaWtlIHRoZSBhdXRob3JzDQogID4gdG8gZGlzY3VzcyBhIGxpdHRsZSBiaXQgY29uY2VybnMg dGhlIGNhc2Ugd2hlcmUgYW4gYXR0YWNrZXIgc2VuZHMNCiAgPiBmb3JnZWQgUlRDUCBYUiByZXBv cnRzLCB3aXRoIGVycm9uZW91cyBQYWNrZXQgRGVsYXkgVmFyaWF0aW9uIHZhbHVlcw0KICA+IChl LmcuIHRoZSBhdHRhY2tlciBtYXkgcHJldGVuZCB0aGUgUERWIGFyZSBtdWNoIHNtYWxsZXIgdGhh biB0aGUgcmVhbGl0eSkuDQogID4gSSBhc3N1bWUgdGhpcyBtYXkgcmVzdWx0IGluIGJhY2sgcGxh eW91dCBidWZmZXIgc2V0dXBzLCBpc24ndCBpdD8gVGhpcw0KICA+IGxvb2tzIGxpa2UgYSBjb29s IHdheSB0byBjcmVhdGUgYSBEb1MuDQoNCiAgW1Fpbl06IEluIHNlY3VyaXR5IGNvbnNpZGVyYXRp b24gc2VjdGlvbiBpbiBSRkMzNjExLCBpdCBzYWlkOg0KICAiDQogIFRoZSBzZWN1cml0eSBjb25z aWRlcmF0aW9ucyB0aGF0IGFwcGx5IHRvIFJUQ1AgcmVwb3J0cyBbUkZDMzU1MF0gYWxzbyBhcHBs eQ0KICAgdG8gWFIgcmVwb3J0cy4gDQogICINCiAgSW4gU2VjdXJpdHkgY29uc2lkZXJhdGlvbiBz ZWN0aW9uIGluIFJGQzM1NTAsIGl0IHNhaWQ6DQogICINCiAgICAgUlRQIHN1ZmZlcnMgZnJvbSB0 aGUgc2FtZSBzZWN1cml0eSBsaWFiaWxpdGllcyBhcyB0aGUgdW5kZXJseWluZw0KICAgICBwcm90 b2NvbHMuICBGb3IgZXhhbXBsZSwgYW4gaW1wb3N0b3IgY2FuIGZha2Ugc291cmNlIG9yIGRlc3Rp bmF0aW9uDQogICAgIG5ldHdvcmsgYWRkcmVzc2VzLCBvciBjaGFuZ2UgdGhlIGhlYWRlciBvciBw YXlsb2FkLiAgV2l0aGluIFJUQ1AsIHRoZQ0KICAgICBDTkFNRSBhbmQgTkFNRSBpbmZvcm1hdGlv biBtYXkgYmUgdXNlZCB0byBpbXBlcnNvbmF0ZSBhbm90aGVyDQogICAgIHBhcnRpY2lwYW50LiAg SW4gYWRkaXRpb24sIFJUUCBtYXkgYmUgc2VudCB2aWEgSVAgbXVsdGljYXN0LCB3aGljaA0KICAg ICBwcm92aWRlcyBubyBkaXJlY3QgbWVhbnMgZm9yIGEgc2VuZGVyIHRvIGtub3cgYWxsIHRoZSBy ZWNlaXZlcnMgb2YNCiAgICAgdGhlIGRhdGEgc2VudCBhbmQgdGhlcmVmb3JlIG5vIG1lYXN1cmUg b2YgcHJpdmFjeS4gIFJpZ2h0bHkgb3Igbm90LA0KICAgICB1c2VycyBtYXkgYmUgbW9yZSBzZW5z aXRpdmUgdG8gcHJpdmFjeSBjb25jZXJucyB3aXRoIGF1ZGlvIGFuZCB2aWRlbw0KICAgICBjb21t dW5pY2F0aW9uIHRoYW4gdGhleSBoYXZlIGJlZW4gd2l0aCBtb3JlIHRyYWRpdGlvbmFsIGZvcm1z IG9mDQogICAgIG5ldHdvcmsgY29tbXVuaWNhdGlvbiBbMzNdLiAgVGhlcmVmb3JlLCB0aGUgdXNl IG9mIHNlY3VyaXR5DQogICAgIG1lY2hhbmlzbXMgd2l0aCBSVFAgaXMgaW1wb3J0YW50LiAgVGhl c2UgbWVjaGFuaXNtcyBhcmUgDQogICAgIGRpc2N1c3NlZCBpbiAgU2VjdGlvbiA5Lg0KDQogICIN CiAgVGhhdCBpcyB0byBzYXksIHlvdXIgY29uY2VybnMgaGFzIGFscmVhZHkgYmVlbiB0YWtlbiBp biBhY2NvdW50ZWQgaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gc2VjdGlvbiBpbiBSRkMz NTUwLg0KDQogIEZ1cnRoZXJtb3JlLCBJbiBzZWN0aW9uIDkgb2YgUkZDMzU1MCwgaXQgc2FpZDoN CiAgIg0KICAgICBMb3dlciBsYXllciBwcm90b2NvbHMgbWF5IGV2ZW50dWFsbHkgcHJvdmlkZSBh bGwgdGhlIHNlY3VyaXR5DQogICAgIHNlcnZpY2VzIHRoYXQgbWF5IGJlIGRlc2lyZWQgZm9yIGFw cGxpY2F0aW9ucyBvZiBSVFAsIGluY2x1ZGluZw0KICAgICBhdXRoZW50aWNhdGlvbiwgaW50ZWdy aXR5LCBhbmQgY29uZmlkZW50aWFsaXR5LiAgVGhlc2Ugc2VydmljZXMgaGF2ZQ0KICAgICBiZWVu IHNwZWNpZmllZCBmb3IgSVAgaW4gWzI3XS4gIFNpbmNlIHRoZSBpbml0aWFsIGF1ZGlvIGFuZCB2 aWRlbw0KICAgICBhcHBsaWNhdGlvbnMgdXNpbmcgUlRQIG5lZWRlZCBhIGNvbmZpZGVudGlhbGl0 eSBzZXJ2aWNlIGJlZm9yZSBzdWNoDQogICAgIHNlcnZpY2VzIHdlcmUgYXZhaWxhYmxlIGZvciB0 aGUgSVAgbGF5ZXIsIHRoZSBjb25maWRlbnRpYWxpdHkgc2VydmljZQ0KICAgICBkZXNjcmliZWQg aW4gdGhlIG5leHQgc2VjdGlvbiB3YXMgZGVmaW5lZCBmb3IgdXNlIHdpdGggUlRQIGFuZCBSVENQ Lg0KICAgICBUaGF0IGRlc2NyaXB0aW9uIGlzIGluY2x1ZGVkIGhlcmUgdG8gY29kaWZ5IGV4aXN0 aW5nIHByYWN0aWNlLiAgTmV3DQogICAgIGFwcGxpY2F0aW9ucyBvZiBSVFAgTUFZIGltcGxlbWVu dCB0aGlzIFJUUC1zcGVjaWZpYyBjb25maWRlbnRpYWxpdHkNCiAgICAgc2VydmljZSBmb3IgYmFj a3dhcmQgY29tcGF0aWJpbGl0eSwgYW5kL29yIHRoZXkgTUFZIGltcGxlbWVudA0KICAgICBhbHRl cm5hdGl2ZSBzZWN1cml0eSBzZXJ2aWNlcy4gIFRoZSBvdmVyaGVhZCBvbiB0aGUgUlRQIHByb3Rv Y29sIGZvcg0KICAgICB0aGlzIGNvbmZpZGVudGlhbGl0eSBzZXJ2aWNlIGlzIGxvdywgc28gdGhl IHBlbmFsdHkgd2lsbCBiZSBtaW5pbWFsDQogICAgIGlmIHRoaXMgc2VydmljZSBpcyBvYnNvbGV0 ZWQgYnkgb3RoZXIgc2VydmljZXMgaW4gdGhlIGZ1dHVyZS4NCg0KICAgICBBbHRlcm5hdGl2ZWx5 LCBvdGhlciBzZXJ2aWNlcywgb3RoZXIgaW1wbGVtZW50YXRpb25zIG9mIHNlcnZpY2VzIGFuZA0K ICAgICBvdGhlciBhbGdvcml0aG1zIG1heSBiZSBkZWZpbmVkIGZvciBSVFAgaW4gdGhlIGZ1dHVy ZS4gIEluDQogICAgIHBhcnRpY3VsYXIsIGFuIFJUUCBwcm9maWxlIGNhbGxlZCBTZWN1cmUgUmVh bC10aW1lIFRyYW5zcG9ydCBQcm90b2NvbA0KICAgICAoU1JUUCkgWzI4XSBpcyBiZWluZyBkZXZl bG9wZWQgdG8gcHJvdmlkZSBjb25maWRlbnRpYWxpdHkgb2YgdGhlIFJUUA0KICAgICBwYXlsb2Fk IHdoaWxlIGxlYXZpbmcgdGhlIFJUUCBoZWFkZXIgaW4gdGhlIGNsZWFyIHNvIHRoYXQgbGluay1s ZXZlbA0KICAgICBoZWFkZXIgY29tcHJlc3Npb24gYWxnb3JpdGhtcyBjYW4gc3RpbGwgb3BlcmF0 ZS4gIEl0IGlzIGV4cGVjdGVkIHRoYXQNCiAgICAgU1JUUCB3aWxsIGJlIHRoZSBjb3JyZWN0IGNo b2ljZSBmb3IgbWFueSBhcHBsaWNhdGlvbnMuICBTUlRQIGlzIGJhc2VkDQogICAgIG9uIHRoZSBB ZHZhbmNlZCBFbmNyeXB0aW9uIFN0YW5kYXJkIChBRVMpIGFuZCBwcm92aWRlcyBzdHJvbmdlcg0K ICAgICBzZWN1cml0eSB0aGFuIHRoZSBzZXJ2aWNlIGRlc2NyaWJlZCBoZXJlLiAgTm8gY2xhaW0g aXMgbWFkZSB0aGF0IHRoZQ0KICAgICBtZXRob2RzIHByZXNlbnRlZCBoZXJlIGFyZSBhcHByb3By aWF0ZSBmb3IgYSBwYXJ0aWN1bGFyIHNlY3VyaXR5DQogICAgIG5lZWQuICBBIHByb2ZpbGUgbWF5 IHNwZWNpZnkgd2hpY2ggc2VydmljZXMgYW5kIGFsZ29yaXRobXMgc2hvdWxkIGJlDQogICAgIG9m ZmVyZWQgYnkgYXBwbGljYXRpb25zLCBhbmQgbWF5IHByb3ZpZGUgZ3VpZGFuY2UgYXMgdG8gdGhl aXINCiAgICAgYXBwcm9wcmlhdGUgdXNlLg0KDQogICAgIEtleSBkaXN0cmlidXRpb24gYW5kIGNl cnRpZmljYXRlcyBhcmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcw0KICAgICBkb2N1bWVudC4N Cg0KDQogICINCiAgRG9lcyB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBzZWN0aW9uIGRlc2Ny aWJlZCBpbiBSRkMzNTUwIGFkZHJlc3MgeW91ciBjb25jZXJuPw0KDQoNCiAgPiBJcyB0aGUgUERW IHVzZWQgZm9yIG90aGVyIHB1cnBvc2VzLCBsaWtlIGltbWluZW50IGNvbmdlc3Rpb24gZGV0ZWN0 aW9uPw0KICA+IEluIHRoYXQgY2FzZSB0aGVyZSBjb3VsZCBiZSBvdGhlciBpbmNlbnRpdmVzIGZv ciBhbiBhdHRhY2tlciB0byBmYWtlIFhSDQogID4gcGFja2V0cywgd2l0aCBwb3NzaWJsZSBhZGRp dGlvbmFsIGRhbWFnZXMuIA0KDQogIFtRaW5dOlRoZSBQRFYgcmV2ZWFscyB0aGUgdmFyaWF0aW9u cyBpbiBsYXRlbmN5IGNhdXNlZCBieSBjb25nZXN0aW9uLCByb3V0ZSBjaGFuZ2VzLCBxdWV1aW5n LCBldGMuDQogIFRoYXQgaXMgdG8gc2F5LCB5b3UgY2FuIG5vdCBzaW1wbHkgdXNpbmcgUERWIHJl cG9ydGluZyB0byBkZXRlY3QgY29uZ2VzdGlvbi4gUGxlYXNlIGNvcnJlY3QgbWUgaWYgDQogIEkg YW0gd3JvbmcuDQoNCiAgPiBJIHRoaW5rIGEgcGFyYWdyYXBoIG9uIHRoZXNlIHJpc2tzIHNob3Vs ZCBiZSBhZGRlZC4NCiAgPiANCiAgPiBDaGVlcnMsDQogID4gDQogID4gICBWaW5jZW50 ------=_NextPart_000_02D6_01CD807A.35AEDC70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgbmFtZT1HRU5FUkFUT1Ig Y29udGVudD0iTVNIVE1MIDguMDAuNjAwMS4xOTI1OCI+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+DQo8RElWPk9uZSBtb3JlIHBvaW50IHRv IGFkZCwgeW91IGFyZSBjb3JyZWN0IGFib3V0IGZvcmdlZCBQRFYgdmFsdWVzLCBidXQgdGhpcyAN CmNhbiBiZSBzb2x2ZWQgYnkgYXV0aGVudGljYXRpb24gdXNpbmcgU1JUUC48L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPlJlZ2FyZHMhPC9ESVY+DQo8RElWPi1RaW48L0RJVj48L0RJVj4N CjxCTE9DS1FVT1RFIA0Kc3R5bGU9IkJPUkRFUi1MRUZUOiAjMDAwMDAwIDJweCBzb2xpZDsgUEFE RElORy1MRUZUOiA1cHg7IFBBRERJTkctUklHSFQ6IDBweDsgTUFSR0lOLUxFRlQ6IDVweDsgTUFS R0lOLVJJR0hUOiAwcHgiIA0KZGlyPWx0cj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0 MzU7JiMyMDMwNzsiPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gPC9ESVY+DQogIDxESVYg c3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7OyBCQUNLR1JPVU5EOiAjZTRlNGU0OyBm b250LWNvbG9yOiBibGFjayI+PEI+RnJvbTo8L0I+IA0KICA8QSB0aXRsZT1iaWxsLnd1QGh1YXdl aS5jb20gaHJlZj0ibWFpbHRvOmJpbGwud3VAaHVhd2VpLmNvbSI+UWluIFd1PC9BPiA8L0RJVj4N CiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlRvOjwvQj4gPEEg dGl0bGU9dmluY2VudC5yb2NhQGlucmlhLmZyIA0KICBocmVmPSJtYWlsdG86dmluY2VudC5yb2Nh QGlucmlhLmZyIj5WaW5jZW50IFJvY2E8L0E+IDsgPEEgdGl0bGU9aWVzZ0BpZXRmLm9yZyANCiAg aHJlZj0ibWFpbHRvOmllc2dAaWV0Zi5vcmciPlRoZSBJRVNHPC9BPiA7IDxBIHRpdGxlPXNlY2Rp ckBpZXRmLm9yZyANCiAgaHJlZj0ibWFpbHRvOnNlY2RpckBpZXRmLm9yZyI+c2VjZGlyQGlldGYu b3JnPC9BPiA7IDxBIA0KICB0aXRsZT1kcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1wZHYuYWxs QHRvb2xzLmlldGYub3JnIA0KICBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3At eHItcGR2LmFsbEB0b29scy5pZXRmLm9yZyI+ZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItcGR2 LmFsbEB0b29scy5pZXRmLm9yZzwvQT4gDQogIDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5 cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+Q2M6PC9CPiA8QSB0aXRsZT12aW5jZW50LnJvY2FAaW5y aWEuZnIgDQogIGhyZWY9Im1haWx0bzp2aW5jZW50LnJvY2FAaW5yaWEuZnIiPlZpbmNlbnQgUm9j YTwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48 Qj5TZW50OjwvQj4gRnJpZGF5LCBBdWd1c3QgMTcsIDIwMTIgMTA6MzggQU08L0RJVj4NCiAgPERJ ViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlN1YmplY3Q6PC9CPiBSZTog U2VjZGlyIHJldmlldyBvZiANCiAgZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItcGR2LTAzPC9E SVY+DQogIDxESVY+PEJSPjwvRElWPg0KICA8RElWPkhpLFZpbmNlbnQ6PC9ESVY+DQogIDxESVY+ VGhhbmsgZm9yIHlvdXIgcmV2aWV3LCBwbGVhc2Ugc2VlIG15IGNvbW1lbnRzIGlubGluZSBiZWxv dy48L0RJVj4NCiAgPERJVj4mbmJzcDs8L0RJVj4NCiAgPERJVj5SZWdhcmRzITwvRElWPg0KICA8 RElWPi1RaW48L0RJVj4NCiAgPERJVj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KICA8 RElWPkZyb206ICJWaW5jZW50IFJvY2EiICZsdDs8QSANCiAgaHJlZj0ibWFpbHRvOnZpbmNlbnQu cm9jYUBpbnJpYS5mciI+dmluY2VudC5yb2NhQGlucmlhLmZyPC9BPiZndDs8L0RJVj4NCiAgPERJ Vj5UbzogIlRoZSBJRVNHIiAmbHQ7PEEgaHJlZj0ibWFpbHRvOmllc2dAaWV0Zi5vcmciPmllc2dA aWV0Zi5vcmc8L0E+Jmd0OzsgDQogICZsdDs8QSBocmVmPSJtYWlsdG86c2VjZGlyQGlldGYub3Jn Ij5zZWNkaXJAaWV0Zi5vcmc8L0E+Jmd0OzsgJmx0OzxBIA0KICBocmVmPSJtYWlsdG86ZHJhZnQt aWV0Zi14cmJsb2NrLXJ0Y3AteHItcGR2LmFsbEB0b29scy5pZXRmLm9yZyI+ZHJhZnQtaWV0Zi14 cmJsb2NrLXJ0Y3AteHItcGR2LmFsbEB0b29scy5pZXRmLm9yZzwvQT4mZ3Q7PC9ESVY+DQogIDxE SVY+Q2M6ICJWaW5jZW50IFJvY2EiICZsdDs8QSANCiAgaHJlZj0ibWFpbHRvOnZpbmNlbnQucm9j YUBpbnJpYS5mciI+dmluY2VudC5yb2NhQGlucmlhLmZyPC9BPiZndDs8L0RJVj4NCiAgPERJVj5T ZW50OiBUaHVyc2RheSwgQXVndXN0IDAyLCAyMDEyIDU6MzEgQU08L0RJVj4NCiAgPERJVj5TdWJq ZWN0OiBTZWNkaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYteHJibG9jay1ydGNwLXhyLXBkdi0wMzwv RElWPjwvRElWPg0KICA8RElWPjxCUj48L0RJVj4NCiAgPERJVj4mZ3Q7IEhlbGxvLDxCUj4mZ3Q7 IDxCUj4mZ3Q7IEkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIA0K ICBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzPEJSPiZndDsgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3 IGFsbCBJRVRGIGRvY3VtZW50cyANCiAgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZTxCUj4mZ3Q7IElF U0cuJm5ic3A7IFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiANCiAgcHJpbWFyaWx5IGZvciB0 aGUgYmVuZWZpdCBvZiB0aGU8QlI+Jmd0OyBzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4gRG9jdW1l bnQgDQogIGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQ8QlI+Jmd0OyB0aGVzZSBj b21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIA0KICBsYXN0IGNhbGwgY29tbWVudHMuPEJSPiZn dDsgPEJSPiZndDsgPEJSPiZndDsgVGhlIGF1dGhvcnMgZXhwbGFpbiB0aGlzIA0KICBkb2N1bWVu dCBpbnRyb2R1Y2VzIG5vIG5ldyBzZWN1cml0eTxCUj4mZ3Q7IGNvbnNpZGVyYXRpb25zIGJleW9u ZCB0aG9zZSANCiAgZGVzY3JpYmVkIGluIFtSRkMzNjExXS48QlI+Jmd0OyBJIGFncmVlIHRoZXJl IGlzIG5vIHByaXZhY3kgcmlzaywgYnV0IGEgDQogIHF1ZXN0aW9uIEknZCBsaWtlIHRoZSBhdXRo b3JzPEJSPiZndDsgdG8gZGlzY3VzcyBhIGxpdHRsZSBiaXQgY29uY2VybnMgdGhlIA0KICBjYXNl IHdoZXJlIGFuIGF0dGFja2VyIHNlbmRzPEJSPiZndDsgZm9yZ2VkIFJUQ1AgWFIgcmVwb3J0cywg d2l0aCBlcnJvbmVvdXMgDQogIFBhY2tldCBEZWxheSBWYXJpYXRpb24gdmFsdWVzPEJSPiZndDsg KGUuZy4gdGhlIGF0dGFja2VyIG1heSBwcmV0ZW5kIHRoZSBQRFYgDQogIGFyZSBtdWNoIHNtYWxs ZXIgdGhhbiB0aGUgcmVhbGl0eSkuPEJSPiZndDsgSSBhc3N1bWUgdGhpcyBtYXkgcmVzdWx0IGlu IGJhY2sgDQogIHBsYXlvdXQgYnVmZmVyIHNldHVwcywgaXNuJ3QgaXQ/IFRoaXM8QlI+Jmd0OyBs b29rcyBsaWtlIGEgY29vbCB3YXkgdG8gY3JlYXRlIA0KICBhIERvUy48QlI+PC9ESVY+DQogIDxE SVY+W1Fpbl06Jm5ic3A7SW4gc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBzZWN0aW9uIGluIFJGQzM2 MTEsIGl0IHNhaWQ6PC9ESVY+DQogIDxESVY+IjwvRElWPg0KICA8RElWPjxTVFJPTkc+VGhlIHNl Y3VyaXR5Jm5ic3A7Y29uc2lkZXJhdGlvbnMgdGhhdCBhcHBseSB0byBSVENQIHJlcG9ydHMgDQog IFtSRkMzNTUwXSBhbHNvIGFwcGx5PEJSPiZuYnNwO3RvIFhSIHJlcG9ydHMuIDwvU1RST05HPjwv RElWPg0KICA8RElWPiI8L0RJVj4NCiAgPERJVj5JbiBTZWN1cml0eSBjb25zaWRlcmF0aW9uIHNl Y3Rpb24gaW4gUkZDMzU1MCwgaXQgc2FpZDo8L0RJVj4NCiAgPERJVj4iPC9ESVY+DQogIDxESVY+ Jm5ic3A7Jm5ic3A7IFJUUCBzdWZmZXJzIGZyb20gdGhlIHNhbWUgc2VjdXJpdHkgbGlhYmlsaXRp ZXMgYXMgdGhlIA0KICB1bmRlcmx5aW5nPEJSPiZuYnNwOyZuYnNwOyBwcm90b2NvbHMuJm5ic3A7 IEZvciBleGFtcGxlLCA8U1RST05HPmFuIGltcG9zdG9yIA0KICBjYW4gZmFrZTwvU1RST05HPiBz b3VyY2Ugb3IgZGVzdGluYXRpb248QlI+Jm5ic3A7Jm5ic3A7IG5ldHdvcmsgYWRkcmVzc2VzLCBv ciANCiAgY2hhbmdlIHRoZSBoZWFkZXIgPFNUUk9ORz5vciBwYXlsb2FkPC9TVFJPTkc+LiZuYnNw OyBXaXRoaW4gUlRDUCwgDQogIHRoZTxCUj4mbmJzcDsmbmJzcDsgQ05BTUUgYW5kIE5BTUUgaW5m b3JtYXRpb24gbWF5IGJlIHVzZWQgdG8gaW1wZXJzb25hdGUgDQogIGFub3RoZXI8QlI+Jm5ic3A7 Jm5ic3A7IHBhcnRpY2lwYW50LiZuYnNwOyBJbiBhZGRpdGlvbiwgUlRQIG1heSBiZSBzZW50IHZp YSBJUCANCiAgbXVsdGljYXN0LCB3aGljaDxCUj4mbmJzcDsmbmJzcDsgcHJvdmlkZXMgbm8gZGly ZWN0IG1lYW5zIGZvciBhIHNlbmRlciB0byBrbm93IA0KICBhbGwgdGhlIHJlY2VpdmVycyBvZjxC Uj4mbmJzcDsmbmJzcDsgdGhlIGRhdGEgc2VudCBhbmQgdGhlcmVmb3JlIG5vIG1lYXN1cmUgb2Yg DQogIHByaXZhY3kuJm5ic3A7IFJpZ2h0bHkgb3Igbm90LDxCUj4mbmJzcDsmbmJzcDsgdXNlcnMg bWF5IGJlIG1vcmUgc2Vuc2l0aXZlIHRvIA0KICBwcml2YWN5IGNvbmNlcm5zIHdpdGggYXVkaW8g YW5kIHZpZGVvPEJSPiZuYnNwOyZuYnNwOyBjb21tdW5pY2F0aW9uIHRoYW4gdGhleSANCiAgaGF2 ZSBiZWVuIHdpdGggbW9yZSB0cmFkaXRpb25hbCBmb3JtcyBvZjxCUj4mbmJzcDsmbmJzcDsgbmV0 d29yayBjb21tdW5pY2F0aW9uIA0KICBbPEEgdGl0bGU9JyJTZWN1cml0eSBTZXJ2aWNlcyBmb3Ig TXVsdGltZWRpYSBDb25mZXJlbmNpbmciJyANCiAgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjMzU1MCNyZWYtMzMiPjMzPC9BPl0uJm5ic3A7IA0KICA8U1RST05HPlRoZXJlZm9y ZSwgdGhlIHVzZSBvZiBzZWN1cml0eTxCUj4mbmJzcDsmbmJzcDsgbWVjaGFuaXNtcyB3aXRoIFJU UCBpcyANCiAgaW1wb3J0YW50LiZuYnNwOyBUaGVzZSBtZWNoYW5pc21zIGFyZSA8L1NUUk9ORz48 L0RJVj4NCiAgPERJVj48U1RST05HPiZuYnNwOyZuYnNwOyBkaXNjdXNzZWQgaW4mbmJzcDsgPC9T VFJPTkc+PEEgDQogIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzM1NTAjc2Vj dGlvbi05Ij48U1RST05HPlNlY3Rpb24gDQogIDk8L1NUUk9ORz48L0E+PFNUUk9ORz4uPEJSPjwv RElWPjwvU1RST05HPg0KICA8RElWPiI8L0RJVj4NCiAgPERJVj5UaGF0IGlzIHRvIHNheSwgeW91 ciBjb25jZXJucyBoYXMgYWxyZWFkeSBiZWVuIHRha2VuIGluIGFjY291bnRlZCBpbiB0aGUgDQog IHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gc2VjdGlvbiBpbiBSRkMzNTUwLjwvRElWPg0KICA8RElW PiZuYnNwOzwvRElWPg0KICA8RElWPkZ1cnRoZXJtb3JlLCBJbiBzZWN0aW9uIDkgb2YgUkZDMzU1 MCwgaXQgc2FpZDo8L0RJVj4NCiAgPERJVj4iPC9ESVY+DQogIDxESVY+Jm5ic3A7Jm5ic3A7PFNU Uk9ORz4gTG93ZXIgbGF5ZXIgcHJvdG9jb2xzIG1heSBldmVudHVhbGx5IHByb3ZpZGUgYWxsIHRo ZSANCiAgc2VjdXJpdHk8QlI+Jm5ic3A7Jm5ic3A7IHNlcnZpY2VzIHRoYXQgbWF5IGJlIGRlc2ly ZWQgZm9yIGFwcGxpY2F0aW9ucyBvZiBSVFAsIA0KICBpbmNsdWRpbmc8QlI+Jm5ic3A7Jm5ic3A7 IGF1dGhlbnRpY2F0aW9uLCBpbnRlZ3JpdHksIGFuZCANCiAgY29uZmlkZW50aWFsaXR5LjwvU1RS T05HPiZuYnNwOyBUaGVzZSBzZXJ2aWNlcyBoYXZlPEJSPiZuYnNwOyZuYnNwOyBiZWVuIA0KICBz cGVjaWZpZWQgZm9yIElQIGluIFs8QSANCiAgdGl0bGU9JyJTZWN1cml0eSBBcmNoaXRlY3R1cmUg Zm9yIHRoZSBJbnRlcm5ldCBQcm90b2NvbCInIA0KICBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmMzNTUwI3JlZi0yNyI+Mjc8L0E+XS4mbmJzcDsgU2luY2UgdGhlIA0KICBpbml0 aWFsIGF1ZGlvIGFuZCB2aWRlbzxCUj4mbmJzcDsmbmJzcDsgYXBwbGljYXRpb25zIHVzaW5nIFJU UCBuZWVkZWQgYSANCiAgY29uZmlkZW50aWFsaXR5IHNlcnZpY2UgYmVmb3JlIHN1Y2g8QlI+Jm5i c3A7Jm5ic3A7IHNlcnZpY2VzIHdlcmUgYXZhaWxhYmxlIA0KICBmb3IgdGhlIElQIGxheWVyLCB0 aGUgY29uZmlkZW50aWFsaXR5IHNlcnZpY2U8QlI+Jm5ic3A7Jm5ic3A7IGRlc2NyaWJlZCBpbiB0 aGUgDQogIG5leHQgc2VjdGlvbiB3YXMgZGVmaW5lZCBmb3IgdXNlIHdpdGggUlRQIGFuZCBSVENQ LjxCUj4mbmJzcDsmbmJzcDsgVGhhdCANCiAgZGVzY3JpcHRpb24gaXMgaW5jbHVkZWQgaGVyZSB0 byBjb2RpZnkgZXhpc3RpbmcgcHJhY3RpY2UuJm5ic3A7IA0KICBOZXc8QlI+Jm5ic3A7Jm5ic3A7 IGFwcGxpY2F0aW9ucyBvZiBSVFAgTUFZIGltcGxlbWVudCB0aGlzIFJUUC1zcGVjaWZpYyANCiAg Y29uZmlkZW50aWFsaXR5PEJSPiZuYnNwOyZuYnNwOyBzZXJ2aWNlIGZvciBiYWNrd2FyZCBjb21w YXRpYmlsaXR5LCBhbmQvb3IgDQogIHRoZXkgTUFZIGltcGxlbWVudDxCUj4mbmJzcDsmbmJzcDsg YWx0ZXJuYXRpdmUgc2VjdXJpdHkgc2VydmljZXMuJm5ic3A7IFRoZSANCiAgb3ZlcmhlYWQgb24g dGhlIFJUUCBwcm90b2NvbCBmb3I8QlI+Jm5ic3A7Jm5ic3A7IHRoaXMgY29uZmlkZW50aWFsaXR5 IHNlcnZpY2UgDQogIGlzIGxvdywgc28gdGhlIHBlbmFsdHkgd2lsbCBiZSBtaW5pbWFsPEJSPiZu YnNwOyZuYnNwOyBpZiB0aGlzIHNlcnZpY2UgaXMgDQogIG9ic29sZXRlZCBieSBvdGhlciBzZXJ2 aWNlcyBpbiB0aGUgZnV0dXJlLjxCUj48QlI+Jm5ic3A7Jm5ic3A7IEFsdGVybmF0aXZlbHksIA0K ICBvdGhlciBzZXJ2aWNlcywgb3RoZXIgaW1wbGVtZW50YXRpb25zIG9mIHNlcnZpY2VzIGFuZDxC Uj4mbmJzcDsmbmJzcDsgb3RoZXIgDQogIGFsZ29yaXRobXMgbWF5IGJlIGRlZmluZWQgZm9yIFJU UCBpbiB0aGUgZnV0dXJlLiZuYnNwOyBJbjxCUj4mbmJzcDsmbmJzcDsgDQogIHBhcnRpY3VsYXIs IDxTVFJPTkc+YW4gUlRQIHByb2ZpbGUgY2FsbGVkIFNlY3VyZSBSZWFsLXRpbWUgVHJhbnNwb3J0 IA0KICBQcm90b2NvbDxCUj4mbmJzcDsmbmJzcDsgKFNSVFApIFs8L1NUUk9ORz48QSANCiAgdGl0 bGU9JyJTZWN1cmUgUmVhbC10aW1lIFRyYW5zcG9ydCBQcm90b2NvbCInIA0KICBocmVmPSJodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzNTUwI3JlZi0yOCI+PFNUUk9ORz4yODwvU1RST05H PjwvQT48U1RST05HPl0gDQogIGlzIGJlaW5nIGRldmVsb3BlZCB0byBwcm92aWRlIGNvbmZpZGVu dGlhbGl0eSBvZiB0aGUgUlRQPEJSPiZuYnNwOyZuYnNwOyANCiAgcGF5bG9hZCB3aGlsZSBsZWF2 aW5nIHRoZSBSVFAgaGVhZGVyIGluIHRoZSBjbGVhciBzbyB0aGF0IA0KICBsaW5rLWxldmVsPEJS PiZuYnNwOyZuYnNwOyBoZWFkZXIgY29tcHJlc3Npb24gYWxnb3JpdGhtcyBjYW4gc3RpbGwgDQog IG9wZXJhdGUuJm5ic3A7PC9TVFJPTkc+IEl0IGlzIGV4cGVjdGVkIHRoYXQ8QlI+Jm5ic3A7Jm5i c3A7IFNSVFAgd2lsbCBiZSB0aGUgDQogIGNvcnJlY3QgY2hvaWNlIGZvciBtYW55IGFwcGxpY2F0 aW9ucy4mbmJzcDsgU1JUUCBpcyBiYXNlZDxCUj4mbmJzcDsmbmJzcDsgb24gDQogIHRoZSBBZHZh bmNlZCBFbmNyeXB0aW9uIFN0YW5kYXJkIChBRVMpIGFuZCBwcm92aWRlcyBzdHJvbmdlcjxCUj4m bmJzcDsmbmJzcDsgDQogIHNlY3VyaXR5IHRoYW4gdGhlIHNlcnZpY2UgZGVzY3JpYmVkIGhlcmUu Jm5ic3A7IE5vIGNsYWltIGlzIG1hZGUgdGhhdCANCiAgdGhlPEJSPiZuYnNwOyZuYnNwOyBtZXRo b2RzIHByZXNlbnRlZCBoZXJlIGFyZSBhcHByb3ByaWF0ZSBmb3IgYSBwYXJ0aWN1bGFyIA0KICBz ZWN1cml0eTxCUj4mbmJzcDsmbmJzcDsgbmVlZC4mbmJzcDsgQSBwcm9maWxlIG1heSBzcGVjaWZ5 IHdoaWNoIHNlcnZpY2VzIGFuZCANCiAgYWxnb3JpdGhtcyBzaG91bGQgYmU8QlI+Jm5ic3A7Jm5i c3A7IG9mZmVyZWQgYnkgYXBwbGljYXRpb25zLCBhbmQgbWF5IHByb3ZpZGUgDQogIGd1aWRhbmNl IGFzIHRvIHRoZWlyPEJSPiZuYnNwOyZuYnNwOyBhcHByb3ByaWF0ZSB1c2UuPEJSPjxCUj4mbmJz cDsmbmJzcDsgS2V5IA0KICBkaXN0cmlidXRpb24gYW5kIGNlcnRpZmljYXRlcyBhcmUgb3V0c2lk ZSB0aGUgc2NvcGUgb2YgdGhpczxCUj4mbmJzcDsmbmJzcDsgDQogIGRvY3VtZW50LjxCUj48QlI+ PC9ESVY+DQogIDxESVY+IjwvRElWPg0KICA8RElWPkRvZXMgdGhlIHNlY3VyaXR5IGNvbnNpZGVy YXRpb24gc2VjdGlvbiBkZXNjcmliZWQgaW4gUkZDMzU1MCBhZGRyZXNzIHlvdXIgDQogIGNvbmNl cm4/PC9ESVY+DQogIDxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQogIDxESVY+PEJSPiZndDsgSXMgdGhlIFBEViB1c2VkIGZvciBvdGhl ciBwdXJwb3NlcywgbGlrZSBpbW1pbmVudCBjb25nZXN0aW9uIA0KICBkZXRlY3Rpb24/PEJSPiZn dDsgSW4gdGhhdCBjYXNlIHRoZXJlIGNvdWxkIGJlIG90aGVyIGluY2VudGl2ZXMgZm9yIGFuIA0K ICBhdHRhY2tlciB0byBmYWtlIFhSPEJSPiZndDsgcGFja2V0cywgd2l0aCBwb3NzaWJsZSBhZGRp dGlvbmFsIGRhbWFnZXMuIA0KICA8QlI+PC9ESVY+DQogIDxESVY+W1Fpbl06VGhlIFBEViByZXZl YWxzIHRoZSB2YXJpYXRpb25zIGluIGxhdGVuY3kgY2F1c2VkIGJ5IGNvbmdlc3Rpb24sIA0KICBy b3V0ZSBjaGFuZ2VzLCBxdWV1aW5nLCBldGMuPC9ESVY+DQogIDxESVY+VGhhdCBpcyB0byBzYXks IHlvdSBjYW4gbm90IHNpbXBseSB1c2luZyBQRFYgcmVwb3J0aW5nIHRvIGRldGVjdCANCiAgY29u Z2VzdGlvbi4gUGxlYXNlIGNvcnJlY3QgbWUgaWYgPC9ESVY+DQogIDxESVY+SSBhbSB3cm9uZy48 L0RJVj4NCiAgPERJVj48Rk9OVCBzaXplPTIgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PjwvRk9OVD48 Rk9OVCBzaXplPTIgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PjwvRk9OVD48QlI+Jmd0OyBJIHRoaW5r IA0KICBhIHBhcmFncmFwaCBvbiB0aGVzZSByaXNrcyBzaG91bGQgYmUgYWRkZWQuPEJSPiZndDsg PEJSPiZndDsgQ2hlZXJzLDxCUj4mZ3Q7IA0KICA8QlI+Jmd0OyZuYnNwOyZuYnNwOyBWaW5jZW50 PC9ESVY+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_02D6_01CD807A.35AEDC70-- From charliek@microsoft.com Wed Aug 22 13:46:17 2012 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 81F3D21F86D7; Wed, 22 Aug 2012 13:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.534 X-Spam-Level: * X-Spam-Status: No, score=1.534 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+er5tIJMhjE; Wed, 22 Aug 2012 13:46:16 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 3A33821F86BD; Wed, 22 Aug 2012 13:46:16 -0700 (PDT) Received: from mail221-ch1-R.bigfish.com (10.43.68.254) by CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id 14.1.225.23; Wed, 22 Aug 2012 20:46:15 +0000 Received: from mail221-ch1 (localhost [127.0.0.1]) by mail221-ch1-R.bigfish.com (Postfix) with ESMTP id 490CF2C04B7; Wed, 22 Aug 2012 20:46:15 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: 2 X-BigFish: VS2(zzc85fhzz1202hzz8275bh8275dhz2fh2a8h683h839hd24hf0ah107ah9a9j) Received-SPF: pass (mail221-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=charliek@microsoft.com; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT003.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail221-ch1 (localhost.localdomain [127.0.0.1]) by mail221-ch1 (MessageSwitch) id 1345668372916895_21591; Wed, 22 Aug 2012 20:46:12 +0000 (UTC) Received: from CH1EHSMHS029.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.250]) by mail221-ch1.bigfish.com (Postfix) with ESMTP id D18DA400083; Wed, 22 Aug 2012 20:46:12 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS029.bigfish.com (10.43.70.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 22 Aug 2012 20:46:11 +0000 Received: from co1outboundpool.messaging.microsoft.com (157.54.51.114) by mail.microsoft.com (157.54.80.61) with Microsoft SMTP Server (TLS) id 14.2.309.3; Wed, 22 Aug 2012 20:46:03 +0000 Received: from mail135-co1-R.bigfish.com (10.243.78.248) by CO1EHSOBE008.bigfish.com (10.243.66.71) with Microsoft SMTP Server id 14.1.225.23; Wed, 22 Aug 2012 20:46:03 +0000 Received: from mail135-co1 (localhost [127.0.0.1]) by mail135-co1-R.bigfish.com (Postfix) with ESMTP id 215DE720082; Wed, 22 Aug 2012 20:46:03 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: SFV:FOP;SFS:;DIR:OUT; Received: from mail135-co1 (localhost.localdomain [127.0.0.1]) by mail135-co1 (MessageSwitch) id 1345668360445016_460; Wed, 22 Aug 2012 20:46:00 +0000 (UTC) Received: from CO1EHSMHS016.bigfish.com (unknown [10.243.78.227]) by mail135-co1.bigfish.com (Postfix) with ESMTP id 5FD98940043; Wed, 22 Aug 2012 20:46:00 +0000 (UTC) Received: from BL2PRD0310HT003.namprd03.prod.outlook.com (157.56.240.21) by CO1EHSMHS016.bigfish.com (10.243.66.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 22 Aug 2012 20:45:59 +0000 Received: from BL2PR03MB593.namprd03.prod.outlook.com (10.255.109.36) by BL2PRD0310HT003.namprd03.prod.outlook.com (10.255.97.38) with Microsoft SMTP Server (TLS) id 14.16.190.9; Wed, 22 Aug 2012 20:45:59 +0000 Received: from BL2PR03MB592.namprd03.prod.outlook.com (10.255.109.35) by BL2PR03MB593.namprd03.prod.outlook.com (10.255.109.36) with Microsoft SMTP Server (TLS) id 15.0.485.6; Wed, 22 Aug 2012 20:45:57 +0000 Received: from BL2PR03MB592.namprd03.prod.outlook.com ([169.254.11.151]) by BL2PR03MB592.namprd03.prod.outlook.com ([169.254.11.151]) with mapi id 15.00.0485.006; Wed, 22 Aug 2012 20:45:57 +0000 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-eai-mailinglistbis.all@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-eai-mailinglistbis-05 Thread-Index: Ac2AheMKwUzNei2US5OLmJ9bAk033w== Date: Wed, 22 Aug 2012 20:45:57 +0000 Message-ID: <5d350cd00c1240f0a9ffeaf07f6bd469@BL2PR03MB592.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.109.22] Content-Type: multipart/alternative; boundary="_000_5d350cd00c1240f0a9ffeaf07f6bd469BL2PR03MB592namprd03pro_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PR03MB593.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TOOLS.IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC106.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC106.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Subject: [secdir] secdir review of draft-ietf-eai-mailinglistbis-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 20:46:17 -0000 --_000_5d350cd00c1240f0a9ffeaf07f6bd469BL2PR03MB592namprd03pro_ Content-Type: text/plain; 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 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 Informational document describes "considerations" for the design and o= perations of mailing list expanders not collocated with the sender when non= -ASCII email addresses are involved. It is truly informational in that it d= oes not prescribe how to deal with the various problems that one might enco= unter. It simply enumerates the problems, describes the alternatives, and t= he range of behaviors observed in existing implementations. It suggests a n= umber of areas where future standardization would be helpful. The document lists no security considerations. An issue discussed in the do= cument that could be considered a security issue is that mail recipients th= at cannot accept non-ASCII email addresses might or might not receive messa= ges sent to the list (depending on approaches the forwarder takes), and gen= erally the original sender is not notified. I don't recommend any changes. --Charlie --_000_5d350cd00c1240f0a9ffeaf07f6bd469BL2PR03MB592namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

 

This Informational document describes “conside= rations” for the design and operations of mailing list expanders not = collocated with the sender when non-ASCII email addresses are involved. It = is truly informational in that it does not prescribe how to deal with the various problems that one might encounter. It simply = enumerates the problems, describes the alternatives, and the range of behav= iors observed in existing implementations. It suggests a number of areas wh= ere future standardization would be helpful.

 

The document lists no security considerations. An is= sue discussed in the document that could be considered a security issue is = that mail recipients that cannot accept non-ASCII email addresses might or = might not receive messages sent to the list (depending on approaches the forwarder takes), and generally the = original sender is not notified. I don’t recommend any changes.<= /o:p>

 

        &nbs= p;       --Charlie

--_000_5d350cd00c1240f0a9ffeaf07f6bd469BL2PR03MB592namprd03pro_-- From tlyu@mit.edu Wed Aug 22 17:14:18 2012 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 3F95521F8564; Wed, 22 Aug 2012 17:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.282 X-Spam-Level: X-Spam-Status: No, score=-104.282 tagged_above=-999 required=5 tests=[AWL=-0.683, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eNXOH4J9fZn; Wed, 22 Aug 2012 17:14:17 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7429C21F855E; Wed, 22 Aug 2012 17:14:17 -0700 (PDT) X-AuditID: 12074422-b7f1f6d00000090b-22-503575d883d0 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 17.8B.02315.8D575305; Wed, 22 Aug 2012 20:14:16 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id q7N0EG6l012340; Wed, 22 Aug 2012 20:14:16 -0400 Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q7N0ECc9012541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Aug 2012 20:14:14 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id q7N0EC6O008914; Wed, 22 Aug 2012 20:14:12 -0400 (EDT) To: secdir@ietf.org, iesg@ietf.org, draft-ietf-manet-olsrv2.all@tools.ietf.org From: Tom Yu Date: Wed, 22 Aug 2012 20:14:12 -0400 Message-ID: Lines: 42 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNIsWRmVeSWpSXmKPExsUixG6nonuj1DTA4NprA4tn3X/YLGb8mchs 8WHhQxYHZo8lS34yeXy5/JktgCmKyyYlNSezLLVI3y6BK+PJ839MBU8FKm4//sPSwNjA18XI ySEhYCJx5/pEdghbTOLCvfVsILaQwD5GiWtLuCDsDYwSp08ZdjFyAdlXmCRedxxjgXC6GCXe f/vK2sXIwSEi4CfR+zcapEEYaOj5d9cZQcJsAtISRxeXgYRZBFQl7h9/ALaLV8BC4sj0fmYQ m0eAU2L6jVusEHFBiZMzn7CA2MwCWhI3/r1kmsDINwtJahaS1AJGplWMsim5Vbq5iZk5xanJ usXJiXl5qUW6pnq5mSV6qSmlmxjBYeaitIPx50GlQ4wCHIxKPLwvzE0DhFgTy4orcw8xSnIw KYnyrikBCvEl5adUZiQWZ8QXleakFh9ilOBgVhLh7SoCyvGmJFZWpRblw6SkOViUxHmvpdz0 FxJITyxJzU5NLUgtgsnKcHAoSfDeBRkqWJSanlqRlplTgpBm4uAEGc4DNPw8SA1vcUFibnFm OkT+FKOilDjvR5CEAEgiozQPrheWBl4xigO9Isx7CaSKB5hC4LpfAQ1mAhqsdtUYZHBJIkJK qoHRIJLjmqT1Q5Ps33uiq2X3TvO9VJPXU7bj6f73s989fmu0W3Q+64x/6hrFWVdjeVh3fV2y ni+5x+H6idPNV5IePn85h0vUrZH/jzBPjDvvgmIf87kO19/8zruc7iQgmelSXrLo09frWf7x 26Sm2om++7gzPsNd5EqVh4Fy/9mTPz+XPNphOmG3EktxRqKhFnNRcSIAObQXVN4CAAA= Subject: [secdir] secdir review of draft-ietf-manet-olsrv2-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 00:14:18 -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's Security Considerations section (Section 23) analyzes some of the protocol's vulnerabilities, but provides no concrete actionable advice. The overall wording in that section suggests directions for future work, but the document does not describe actual protocol elements that are capable of providing the needed protections. Section 23.1 describes confidentiality considerations for the protocol, but does not explain what situations merit confidentiality protection for the network topology. It mentions the possibility of protecting confidentiality in OLSRv2 by using PGP or shared key encryption, but provides no indication of how to do so, nor does it indicate how participants should conduct key management. Section 23.2 describes integrity considerations. The text presents several examples where invalid control traffic may disrupt the network, and distinguishes the situations where data origin authentication for the control message is sufficient from situations that require additional authentication of link states, for example. Authentication of link states seems potentially complicated, because it seems that both ends of a link would have to authenticate the validity of the link between them in a way that third parties could verify. This document does not detail how such link validity authentication would work. Section 23.2 also mentions thwarting replay attacks using temporal information, but there are no obvious places for the protocol to carry such information. Section 23.2 mentions using IPsec authentication headers for authenticating entire control packets, but offers no suggestions about how to perform key distribution. Section 23.3 describes interactions with external routing domains, and makes reasonable suggestions. From Tina.Tsou.Zouting@huawei.com Wed Aug 22 21:36:21 2012 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 DC3DB21F84BF; Wed, 22 Aug 2012 21:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.08 X-Spam-Level: X-Spam-Status: No, score=-6.08 tagged_above=-999 required=5 tests=[AWL=0.518, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeDCuruMh07p; Wed, 22 Aug 2012 21:36:20 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 06CA721F84B8; Wed, 22 Aug 2012 21:36:19 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfwdlp01-ep.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJW09263; Wed, 22 Aug 2012 20:36:18 -0800 (PST) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 22 Aug 2012 21:30:32 -0700 Received: from dfweml513-mbx.china.huawei.com ([169.254.3.159]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Wed, 22 Aug 2012 21:30:21 -0700 From: Tina TSOU To: Qin Wu Thread-Topic: [secdir] Secdir review of draft-ietf-avtcore-monarch-17 Thread-Index: AQHNgBtTN3CPcwvDt0SdX/BDBNBFzZdlQAPegAAjoBqAAWwpjA== Date: Thu, 23 Aug 2012 04:30:21 +0000 Message-ID: <0AB75B72-FD89-4328-BCF6-CF29A2223B20@huawei.com> References: <58D08DCC-37CD-4DE9-A574-719F5409153C@huawei.com>, In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_0AB75B72FD894328BCF6CF29A2223B20huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: The IESG , "draft-ietf-avtcore-monarch@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-avtcore-monarch-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 04:36:21 -0000 --_000_0AB75B72FD894328BCF6CF29A2223B20huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable OK, our replies resolve my comments. Tina On Aug 21, 2012, at 11:46 PM, "Qin Wu" > wrote: ----- Original Message ----- From: Tina TSOU To: Qin Wu Cc: draft-ietf-avtcore-monarch@tools.ietf.org ; secdir@ietf.org ; The IESG Sent: Wednesday, August 22, 2012 12:39 PM Subject: Re: [secdir] Secdir review of draft-ietf-avtcore-monarch-17 Here is what I meant: which parties trust each other? The other parties will be excluded from receiving the measurements. What does each case imply in terms of requirements for key management? [Qin]: If the other parties are allowed to receive the measurement, they sh= ould be authenticated using SRTP in RFC3711. If the parties that are trusted access to some RTCP flows but not other, au= thentication using SRTP in RFC3711 also can be used. Regarding key managment requirement, RFC 3711 has already pointed out what= key management standards can be used to establish an SRTP cryptographic context. --_000_0AB75B72FD894328BCF6CF29A2223B20huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
OK, our replies resolve my comments.

Tina

On Aug 21, 2012, at 11:46 PM, "Qin Wu" <bill.wu@huawei.com> wrote:

----- Original Message -----
Sent: Wednesday, August 22= , 2012 12:39 PM
Subject: Re: [secdir] Secd= ir review of draft-ietf-avtcore-monarch-17

Here is what I meant: which parties trust each other? The other partie= s
will be excluded from receiving the measurements. What does each case=
imply in terms of requirements for key management?

[Qin]: If the other parties are allowed to receive th= e measurement, they should be authenticated using SRTP in RFC3711.
If the parties that are trusted access to some RTCP f= lows but not other, authentication using SRTP in RFC3711 also can be used.<= /div>
Regarding key managment requirement,  RFC 3711 has al= ready pointed out what key management standards can be used to
establish an SRTP cryptographic context.
--_000_0AB75B72FD894328BCF6CF29A2223B20huaweicom_-- From Tina.Tsou.Zouting@huawei.com Wed Aug 22 22:20:56 2012 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 1101A11E80A3; Wed, 22 Aug 2012 22:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.088 X-Spam-Level: X-Spam-Status: No, score=-6.088 tagged_above=-999 required=5 tests=[AWL=0.510, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ydzcf1xF-Xd; Wed, 22 Aug 2012 22:20:54 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4E12D11E808A; Wed, 22 Aug 2012 22:20:54 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJO05976; Wed, 22 Aug 2012 21:20:48 -0800 (PST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 22 Aug 2012 22:13:09 -0700 Received: from dfweml513-mbx.china.huawei.com ([169.254.3.159]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Wed, 22 Aug 2012 22:12:57 -0700 From: Tina TSOU To: Tina TSOU , Qin Wu Thread-Topic: [secdir] Secdir review of draft-ietf-avtcore-monarch-17 Thread-Index: AQHNgBtTN3CPcwvDt0SdX/BDBNBFzZdlQAPegAAjoBqAAWwpjIAAC8Ag Date: Thu, 23 Aug 2012 05:12:57 +0000 Message-ID: References: <58D08DCC-37CD-4DE9-A574-719F5409153C@huawei.com>, <0AB75B72-FD89-4328-BCF6-CF29A2223B20@huawei.com> In-Reply-To: <0AB75B72-FD89-4328-BCF6-CF29A2223B20@huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.113] Content-Type: multipart/alternative; boundary="_000_C0E0A32284495243BDE0AC8A066631A8158EF97Ddfweml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: The IESG , "draft-ietf-avtcore-monarch@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-avtcore-monarch-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 05:20:56 -0000 --_000_C0E0A32284495243BDE0AC8A066631A8158EF97Ddfweml513mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry, typo, I meant your replies. Lack of sleep... Tina From: secdir-bounces@ietf.org [mailto:secdir-bounces@ietf.org] On Behalf Of= Tina TSOU Sent: Wednesday, August 22, 2012 9:30 PM To: Qin Wu Cc: The IESG; draft-ietf-avtcore-monarch@tools.ietf.org; secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-avtcore-monarch-17 OK, our replies resolve my comments. Tina On Aug 21, 2012, at 11:46 PM, "Qin Wu" > wrote: ----- Original Message ----- From: Tina TSOU To: Qin Wu Cc: draft-ietf-avtcore-monarch@tools.ietf.org ; secdir@ietf.org ; The IESG Sent: Wednesday, August 22, 2012 12:39 PM Subject: Re: [secdir] Secdir review of draft-ietf-avtcore-monarch-17 Here is what I meant: which parties trust each other? The other parties will be excluded from receiving the measurements. What does each case imply in terms of requirements for key management? [Qin]: If the other parties are allowed to receive the measurement, they sh= ould be authenticated using SRTP in RFC3711. If the parties that are trusted access to some RTCP flows but not other, au= thentication using SRTP in RFC3711 also can be used. Regarding key managment requirement, RFC 3711 has already pointed out what= key management standards can be used to establish an SRTP cryptographic context. --_000_C0E0A32284495243BDE0AC8A066631A8158EF97Ddfweml513mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sorry, typo, I meant your= replies. Lack of sleep…

 <= /p>

Tina

 <= /p>

From: secdir-b= ounces@ietf.org [mailto:secdir-bounces@ietf.org] On Behalf Of Tina TSOU
Sent: Wednesday, August 22, 2012 9:30 PM
To: Qin Wu
Cc: The IESG; draft-ietf-avtcore-monarch@tools.ietf.org; secdir@ietf= .org
Subject: Re: [secdir] Secdir review of draft-ietf-avtcore-monarch-17=

 

OK, our replies resolve my comments.

Tina


On Aug 21, 2012, at 11:46 PM, "Qin Wu" <bill.wu@huawei.com> wrote:

----- Original Message -----

From: Tina TSOU

Sent: Wednesday, August 22, 2012 12:39 PM

Subject: Re: [secdir] Secdir review of draft-ietf-avtcore-monarch-17

 

Here is what I meant:= which parties trust each other? The other parties
will be excluded from receiving the measurements. What does each case
imply in terms of requirements for key management?

[Qin]: If the other parties are allowed to rece= ive the measurement, they should be authenticated using SRTP in RFC3711.

If the parties that are trusted access to some = RTCP flows but not other, authentication using SRTP in RFC3711 also can be = used.

Regarding key managment requirement,  RFC 3711 = has already pointed out what key management standards can be used to

establish an SRTP cryptographic context.<= /p>

--_000_C0E0A32284495243BDE0AC8A066631A8158EF97Ddfweml513mbxchi_-- From paul.hoffman@vpnc.org Thu Aug 23 09:43:31 2012 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 4361821F8559; Thu, 23 Aug 2012 09:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYxpu7S7TK2U; Thu, 23 Aug 2012 09:43:30 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 519B421F8535; Thu, 23 Aug 2012 09:43:30 -0700 (PDT) Received: from [10.20.30.108] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q7NGhSGG030877 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 23 Aug 2012 09:43:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Paul Hoffman In-Reply-To: Date: Thu, 23 Aug 2012 09:43:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <14DB90CC-BF75-4EBC-8348-29E85D678DDE@vpnc.org> To: "Bhatia, Vikas" X-Mailer: Apple Mail (2.1485) Cc: "drinks@ietf.org" , secdir Subject: Re: [secdir] [drinks] Secdir review of draft-ietf-drinks-spp-framework X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 16:43:31 -0000 On Aug 23, 2012, at 9:36 AM, "Bhatia, Vikas" wrote: > Agree with your point, but the line "SPPF is a protocol..." is not = present in the current version of the framework draft = (http://tools.ietf.org/html/draft-ietf-drinks-spp-framework-02) = (assuming this line was taken from the document that was reviewed). Correct. I was summarizing what SPPF was for the folks on the Secdir = mailing list so they would have a bit of understanding of what was being = protected. > We will add a reference to the spp-protocol-over-soap document to the = "Normative References" section in the framework document. Thanks. > Your point is valid. TLS is a MUST as mentioned in section 11.1 of the = SOAP document = (http://tools.ietf.org/html/draft-ietf-drinks-spp-protocol-over-soap-02). = It seems to be an oversight to not have this requirement as a MUST in = the framework. We shall replace existing text in the "Confidentiality = and Integrity" section of the framework document as below: >=20 > "Any conforming transport protocol specification MUST provide means to = protect the confidentiality and integrity of any data transmitted = between SPPF client and server. " Thanks. --Paul Hoffman= From d3e3e3@gmail.com Thu Aug 23 13:36:06 2012 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 3586E21F854C; Thu, 23 Aug 2012 13:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.528 X-Spam-Level: X-Spam-Status: No, score=-103.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8Y8-bNB1NCA; Thu, 23 Aug 2012 13:36:05 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id D7DC221F8549; Thu, 23 Aug 2012 13:36:04 -0700 (PDT) Received: by iabz21 with SMTP id z21so2150242iab.31 for ; Thu, 23 Aug 2012 13:36:01 -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:content-type; bh=Vcim0sPclo1Dc0qizp+AuElqSS3I1s4l9eA9K4Fz2cc=; b=J4g0Gm3epvYQBO51liUtugpi0ZPeL9AIdhYZlI2jHIfCrl5hQ9unNxUFTSKX/DEgIZ 0CbiKOHUym7K2xU4S34ddvMxnYL2bA8C4zibu0/DSW5J732cbz73TqiohlGaGIfqJW5u 1ypRJkFZ4sDdvgMDcKpq0yD7wK4IqYt7VSNJ4Xh09Di97RCChFizRxi9Sj7rIy6NL4s6 B7id+iFxxC1hN7oc+RAIAmN215dMOEDSaOX+HikyYfmGQECbZvhPjGi06ymqSTG2hJ4Q xyQCUYAYzASa0VZw8c1AkHIr/toy38wsvoWNQJjx7jaNgp/+/cu+BRHQSH9XSaJUxZ0l AyCg== Received: by 10.42.95.10 with SMTP id d10mr2463230icn.30.1345754161189; Thu, 23 Aug 2012 13:36:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.15.6 with HTTP; Thu, 23 Aug 2012 13:35:40 -0700 (PDT) From: Donald Eastlake Date: Thu, 23 Aug 2012 16:35:40 -0400 Message-ID: To: iesg@ietf.org, secdir@ietf.org, draft-ietf-pce-hierarchy-fwk.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [secdir] draft-ietf-pce-hierarchy-fwk-04 SECDIR review X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 20:36:06 -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. Document editors and WG chairs should treat these comments just like any other last call comments. This Informational draft discusses the use of the Path Computation Element (PCE) architecture to determining routes through multiple domains with different administration. This uses hierarchical PCE processes that are heavily dependent on the PCE Protocol. The Security Consideration section of this draft is heavily dependent on the Security Considerations in the PCE Protocol RFC 5440, which are quite good, and also references Security Considerations in several other RFCs including RFC 5327 for inter-AS path computation and Path Keys in RFC 5520 as well as directly discussing aspects unique to or particularly prominent in the area considered. I believe that security aspects of the technology being discussed in this informational draft are well covered, directly or by reference, and have no changes to recommend. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From kent@bbn.com Thu Aug 23 22:42:29 2012 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 195DA21F847C for ; Thu, 23 Aug 2012 22:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.521 X-Spam-Level: X-Spam-Status: No, score=-106.521 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Jtyau4WH8r9 for ; Thu, 23 Aug 2012 22:42:27 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 14ACD21F847A for ; Thu, 23 Aug 2012 22:42:27 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:48681 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1T4mf2-000Ig7-RW for secdir@ietf.org; Fri, 24 Aug 2012 01:42:25 -0400 Message-ID: <503709BF.1080307@bbn.com> Date: Fri, 24 Aug 2012 00:57:35 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: secdir References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070800090302070005010305" Subject: [secdir] review of draft-ietf-httpbis-p7-auth-20 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 05:42:29 -0000 This is a multi-part message in MIME format. --------------070800090302070005010305 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 editors and WG chairs should treat these comments just like any other last call comments. This is a fairly brief document: 18 pages including appendices. The Abstract says that this document "...defines the HTTP Authentication framework" but the Introduction expands the description, saying that it " describes HTTP/1.1 access control and authentication." I suggest the introduction be changed to match the abstract, especially since the principal focus of the document is authentication. There are several places where the term "authorization" is used. In many contexts, this term is a synonym for access control. However, in this context it seems to be used almost interchangeably with "authentication" in most places. I suspect the terminology choice arises for historical reasons, but it might be helpful to explicitly note this, where applicable. The introduction says that it includes "the relevant parts of RFC 2616 with only minor changes ([RFC2616]), plus the general framework for HTTP authentication, as previously defined in "HTTP Authentication: Basic and Digest Access Authentication" ([RFC2617])." The document updates RFC 2617, and obsoletes RFC 2616. It includes an appendix that describes the differences between this document and (the relevant portions) of 2616 and 2617. I'm not sure whether the use of lowercase "ought" in four places in Section 2.3.1 is intended to express a new level of IETF standards compliance, perhaps filling the gap between MAY and SHOULD ;-) . I like the fact that the Security Considerations section addresses implementation issues, since the document, overall, addresses security. Only two topics are discussed here, but both seem relevant. I am surprised that there is no mention of using HTTPS, to protect the most commonly used credentials, i.e., passwords. --------------070800090302070005010305 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

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 editors and WG chairs should treat these comments just like any other last call comments.

 

This is a fairly brief document: 18 pages including appendices. The Abstract says that this document “…defines the HTTP Authentication framework” but the Introduction expands the description, saying that it “ describes HTTP/1.1 access control and authentication.” I suggest the introduction be changed to match the abstract, especially since the principal focus of the document is authentication. There are several places where the term “authorization” is used. In many contexts, this term is a synonym for access control. However, in this context it seems to be used almost interchangeably with “authentication” in most places. I suspect the terminology choice arises for historical reasons, but it might be helpful to explicitly note this, where applicable.

 

The introduction says that it includes “the relevant parts of RFC 2616 with only minor changes ([RFC2616]), plus the general framework for HTTP authentication, as previously defined in "HTTP Authentication: Basic and Digest Access Authentication" ([RFC2617]).” The document updates RFC 2617, and obsoletes RFC 2616. It includes an appendix that describes the differences between this document and (the relevant portions) of 2616 and 2617.

 

I’m not sure whether the use of lowercase “ought” in four places in Section 2.3.1 is intended to express a new level of IETF standards compliance, perhaps filling the gap between MAY and SHOULD ;-) .

 

I like the fact that the Security Considerations section addresses implementation issues, since the document, overall, addresses security. Only two topics are discussed here, but both seem relevant. I am surprised that there is no mention of using HTTPS, to protect the most commonly used credentials, i.e., passwords.

 

--------------070800090302070005010305-- From andrew.g.malis@verizon.com Mon Aug 20 07:14:31 2012 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 708BD21F8629; Mon, 20 Aug 2012 07:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.226 X-Spam-Level: X-Spam-Status: No, score=-3.226 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phtuNkK7Z5h0; Mon, 20 Aug 2012 07:14:31 -0700 (PDT) Received: from fldsmtpe03.verizon.com (fldsmtpe03.verizon.com [140.108.26.142]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2B821F8602; Mon, 20 Aug 2012 07:14:30 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe03.verizon.com with ESMTP; 20 Aug 2012 14:14:13 +0000 From: "Malis, Andrew G \(Andy\)" X-IronPort-AV: E=Sophos;i="4.77,797,1336348800"; d="scan'208";a="321465198" Received: from fhdp1lumxc7hb05.verizon.com (HELO FHDP1LUMXC7HB05.us.one.verizon.com) ([166.68.59.192]) by fldsmtpi01.verizon.com with ESMTP; 20 Aug 2012 14:14:13 +0000 Received: from fhdp1lumxc7v22.us.one.verizon.com ([166.68.59.158]) by FHDP1LUMXC7HB05.us.one.verizon.com ([166.68.59.192]) with mapi; Mon, 20 Aug 2012 10:14:13 -0400 To: Carl Wallace , "draft-ietf-ccamp-rfc5787bis.all@tools.ietf.org" Date: Mon, 20 Aug 2012 10:14:19 -0400 Thread-Topic: secdir review of draft-ietf-ccamp-rfc5787bis Thread-Index: Ac1+3hKMcHiSCJZzTryvqpPyDBYwlg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 24 Aug 2012 05:44:28 -0700 Cc: "Malis, Andrew G \(Andy\)" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-ccamp-rfc5787bis X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 14:14:31 -0000 Carl, Thanks, that's a good comment on Appendix C - I'll see what we can do to expand on the detail. Cheers, Andy On 8/19/2012 18:16 , "Carl Wallace" 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 document obsoletes RFC 5787 and updates RFC 5786. Though this document is from an area with which I have no expertise, I found it clear and easy to follow. I found no security issues. One minor nit, it'd be helpful if Appendix C provided more detail about the nature of how this draft updates RFC 5786. From sun.weiqiang@gmail.com Mon Aug 20 18:50:41 2012 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 E05E711E809C; Mon, 20 Aug 2012 18:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQQn8z4aW6RM; Mon, 20 Aug 2012 18:50:40 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0A91311E809B; Mon, 20 Aug 2012 18:50:39 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so8110839pbb.31 for ; Mon, 20 Aug 2012 18:50:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=fILk4pRP7y984+BYA5KBWfpscmzX9SxKKQmO0HVEDhM=; b=x3meI0IntjZnnJZE1lYBgDMCBl+POTn5grLcyCX6gnleWzpLdnwPkFKG/ocDQlBLB6 qaHyhHscDAxoKxpfhfNy1hw1GUg4jH/72KOq9elv+axZRwuhqzq0r1aNw395//AI4gTW Lgkc5Low9RQkESGRpCddT8qg5GO0iwfJfF2MxwymHki86TU2RDe+L6rvq3E/FnJs5Qiq UsU7MDf4aqeU1Bhg4SF4LSy5nA7seb0Oqp9bbXvGIOGGYkJ4vm1RyMXvr3AtRtotAk2O M3zs8puwXe9Mib8jHM/TjJnb9Ion0u6l/U7LN33Lw5Sqg3HMR0YYD5uCST1LacYfXls1 7Fnw== Received: by 10.68.242.231 with SMTP id wt7mr34348730pbc.99.1345513839262; Mon, 20 Aug 2012 18:50:39 -0700 (PDT) Received: from [192.168.6.100] ([202.120.39.147]) by mx.google.com with ESMTPS id wd6sm308630pbc.15.2012.08.20.18.50.35 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Aug 2012 18:50:38 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Tue, 21 Aug 2012 09:50:28 +0800 From: Weiqiang Sun To: Klaas Wierenga , The IESG , , Message-ID: Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-dpm-07.txt In-Reply-To: <20120821014012.12834.63124.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Mailman-Approved-At: Fri, 24 Aug 2012 05:44:28 -0700 Cc: ccamp@ietf.org Subject: [secdir] FW: [CCAMP] I-D Action: draft-ietf-ccamp-dpm-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 01:50:41 -0000 Hello all, We have uploaded a new version of draft-ietf-ccamp-dpm by taking into account the Secdir review comments from Klaas. Three changes are made in this revision: 1) in the Abstract: We rephrased the following sentence: Old text: The existence of this delay and the possible failure of cross connection programming, if not properly treated, will result in data loss or even application failure. New text: The existence of the inconsistency between the signaling messages and cross connection programing, and the possible failure of cross connection programming, if not properly treated, will result in data loss or even application failure. 2) in 11.2. The Median of Metric We added the following text: When the number of defined values in the given sample is small, the metric median may not be typical and SHOULD be used carefully. 3) slight changes to <14. Acknowledgements> Thanks, Weiqiang and co-authors On 8/21/12 9:40 AM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Common Control and Measurement Plane >Working Group of the IETF. > > Title : Label Switched Path (LSP) Data Path Delay Metrics in >Generalized MPLS/ MPLS-TE Networks > Author(s) : Weiqiang Sun > Guoying Zhang > Filename : draft-ietf-ccamp-dpm-07.txt > Pages : 33 > Date : 2012-08-20 > >Abstract: > When setting up a label switched path (LSP) in Generalized MPLS and > MPLS/TE networks, the completion of the signaling process does not > necessarily mean that the cross connection along the LSP have been > programmed accordingly and in a timely manner. Meanwhile, the > completion of signaling process may be used by applications as > indication that data path has become usable. The existence of the > inconsistency between the signaling messages and cross connection > programing, and the possible failure of cross connection programming, > if not properly treated, will result in data loss or even application > failure. Characterization of this performance can thus help > designers to improve the application model and to build more robust > applications. This document defines a series of performance metrics > to evaluate the connectivity of data path in the signaling process. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-ccamp-dpm > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-ccamp-dpm-07 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-dpm-07 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >CCAMP mailing list >CCAMP@ietf.org >https://www.ietf.org/mailman/listinfo/ccamp From sumanth@cablelabs.com Tue Aug 21 09:31:53 2012 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 1163921F87B7; Tue, 21 Aug 2012 09:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWOaH6JEZL6m; Tue, 21 Aug 2012 09:31:52 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 73B0521F87B6; Tue, 21 Aug 2012 09:31:49 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q7LGVlZG020740; Tue, 21 Aug 2012 10:31:48 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Tue, 21 Aug 2012 10:31:47 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Tue, 21 Aug 2012 10:31:48 -0600 From: Sumanth Channabasappa To: "Drinks@ietf.org" Date: Tue, 21 Aug 2012 10:31:45 -0600 Thread-Topic: Security Directorate early review comments (from Paul Hoffman) Thread-Index: Ac1/unXInveEUfdeQQi+APx35OQepA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC59141111BB3sumanthcablelabscom_" MIME-Version: 1.0 X-Approved: ondar X-Mailman-Approved-At: Fri, 24 Aug 2012 05:44:28 -0700 Cc: Paul Hoffman , "secdir@ietf.org" Subject: [secdir] Security Directorate early review comments (from Paul Hoffman) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 16:31:53 -0000 --_000_CC59141111BB3sumanthcablelabscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WG Participants, As you know we requested an early review from the security directorate, the= apps area, and a couple of other external reviewers on the two I-Ds that a= re currently I last call. I am forwarding the comments from Paul Hoffman (on behalf of the security d= irectorate) since he is not on the mailing list. Please include him on your= responses. - S -- From Paul Hoffman Greetings. I have been requested to review draft-ietf-drinks-spp-framework = for the Security Directorate. This review is being done during WG Last Call= instead of IETF Last Call as a special request. I note that literally no o= ne has spoken up in the WG during WG Last Call since it began three weeks a= go. SPPF is a protocol for provisioning session establishment data into data re= gistries and SIP service providers. Well, actually it's not. It is a descri= ption of the data format and some handwaving about how to transport that da= ta. The mandatory-to-implement transport is listed in a different document,= draft-ietf-drinks-spp-protocol-over-soap (for which there is no reference = in this document...). The transport protocol requirements listed in section 4 of this document ar= e fairly generic, as are the security requirements. The descriptions of the= transport requirements are fine. The security requirements are not so grea= t: while servers MUST be able to authenticate clients, confidentiality and = integrity protection SHOULD be provided. Given that the mandatory-to implem= ent transport is SOAP, this approximately translates to "must do some sort = or minimal client authentication, should consider using TLS but lots of cli= ents and servers probably won't actually do it". I think that undershoots m= oderns security practices, which would have TLS be mandatory. Even though this is a security review, I cannot resist a non-security quest= ion: SOAP? In 2012? Really? -- --_000_CC59141111BB3sumanthcablelabscom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
WG Participants,

As you know we requested an early review fr= om the security directorate, the apps area, and a couple of other external = reviewers on the two I-Ds that are currently I last call. 

I am forwarding the comments f= rom Paul Hoffman (on behalf of the security directorate) since he is not on= the mailing list. Please include him on your responses.


- S


-- From Paul Hoffman

Greetings. I have been requested to review draft-ietf-drinks-spp= -framework for the Security Directorate. This review is being done during W= G Last Call instead of IETF Last Call as a special request. I note that lit= erally no one has spoken up in the WG during WG Last Call since it began th= ree weeks ago.
SPPF= is a protocol for provisioning session establishment data into data regist= ries and SIP service providers. Well, actually it's not. It is a descriptio= n of the data format and some handwaving about how to transport that data. = The mandatory-to-implement transport is listed in a different document, dra= ft-ietf-drinks-spp-protocol-over-soap (for which there is no reference in t= his document...).

T= he transport protocol requirements listed in section 4 of this document are= fairly generic, as are the security requirements. The descriptions of the = transport requirements are fine. The security requirements are not so great= : while servers MUST be able to authenticate clients, confidentiality and i= ntegrity protection SHOULD be provided. Given that the mandatory-to impleme= nt transport is SOAP, this approximately translates to "must do some sort o= r minimal client authentication, should consider using TLS but lots of clie= nts and servers probably won't actually do it". I think that undershoots mo= derns security practices, which would have TLS be mandatory.

Even though this is a security re= view, I cannot resist a non-security question: SOAP? In 2012? Really? <s= igh>

--
--_000_CC59141111BB3sumanthcablelabscom_-- From vbhatia@tnsi.com Thu Aug 23 09:36:26 2012 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 CC01621F8582; Thu, 23 Aug 2012 09:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDRQLyDC99OE; Thu, 23 Aug 2012 09:36:24 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADA921F85A3; Thu, 23 Aug 2012 09:36:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAJlbNlCsEQfn/2dsb2JhbABFu1SCIAEBAQQBAQEkEw0nCwwEAgEIEQQBAR8JBycLFAkIAQEEAQ0FCIgQqlaPO4sIGoYXYAOWaJF/gUU X-IronPort-AV: E=Sophos;i="4.80,301,1344207600"; d="scan'208";a="1485043" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 23 Aug 2012 17:36:26 +0100 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Thu, 23 Aug 2012 12:36:22 -0400 From: "Bhatia, Vikas" To: Paul Hoffman , "drinks@ietf.org" Date: Thu, 23 Aug 2012 12:36:21 -0400 Thread-Topic: [drinks] Secdir review of draft-ietf-drinks-spp-framework Thread-Index: Ac2AL4WpGgx7n2I7SJm66NwiqSSlmABEVq1w Message-ID: References: <14DB90CC-BF75-4EBC-8348-29E85D678DDE@vpnc.org> In-Reply-To: <14DB90CC-BF75-4EBC-8348-29E85D678DDE@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 24 Aug 2012 05:44:28 -0700 Cc: secdir Subject: Re: [secdir] [drinks] Secdir review of draft-ietf-drinks-spp-framework X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 16:36:26 -0000 Hello Paul, Thanks for the review. Below is a response to your comments: =3D=3DYour Comment=3D=3D SPPF is a protocol for provisioning session establishment data into data re= gistries and SIP service providers. Well, actually it's not. It is a descri= ption of the data format and some handwaving about how to transport that da= ta. The mandatory-to-implement transport is listed in a different document,= draft-ietf-drinks-spp-protocol-over-soap (for which there is no reference = in this document...). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Response -> Agree with your point, but the line "SPPF is a protocol..." is not present = in the current version of the framework draft (http://tools.ietf.org/html/d= raft-ietf-drinks-spp-framework-02) (assuming this line was taken from the d= ocument that was reviewed). Below is an excerpt from the "Abstract" that th= e framework document currently has to describe SPPF: This document specifies the data model and the overall structure for a framework to provision session establishment data into Session Data Registries and SIP Service Provider data stores. The framework is called the Session Peering Provisioning Framework (SPPF). Let us know if you have a further comment on the above text. We will add a reference to the spp-protocol-over-soap document to the "Norm= ative References" section in the framework document. =3D=3DYour Comment=3D=3D The transport protocol requirements listed in section 4 of this document ar= e fairly generic, as are the security requirements. The descriptions of the= transport requirements are fine. The security requirements are not so grea= t: while servers MUST be able to authenticate clients, confidentiality and = integrity protection SHOULD be provided. Given that the mandatory-to implem= ent transport is SOAP, this approximately translates to "must do some sort = or minimal client authentication, should consider using TLS but lots of cli= ents and servers probably won't actually do it". I think that undershoots m= oderns security practices, which would have TLS be mandatory. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Response -> Your point is valid. TLS is a MUST as mentioned in section 11.1 of the SOAP= document (http://tools.ietf.org/html/draft-ietf-drinks-spp-protocol-over-s= oap-02). It seems to be an oversight to not have this requirement as a MUST= in the framework. We shall replace existing text in the "Confidentiality a= nd Integrity" section of the framework document as below: "Any conforming transport protocol specification MUST provide means to prot= ect the confidentiality and integrity of any data transmitted between SPPF = client and server. " For easy reference, below is the existing text (which shall be replaced wit= h the above one liner): "4.6. Confidentiality and Integrity In some deployments, the SPPF objects that an SPPF registry manages can be private in nature. As a result it MAY NOT be appropriate to for transmission in plain text over a connection to the SPPF registry. Therefore, the transport protocol SHOULD provide means for end-to-end encryption between the SPPF client and server. For some SPPF implementations, it may be acceptable for the data to be transmitted in plain text, but the failure to detect a change in data after it leaves the SPPF client and before it is received at the server, either by accident or with a malicious intent, will adversely affect the stability and integrity of the registry. Therefore, the transport protocol SHOULD provide means for data integrity" protection." Thanks, Vikas -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Paul Hoffman Sent: Saturday, August 18, 2012 9:19 PM To: drinks@ietf.org Cc: secdir Subject: [drinks] Secdir review of draft-ietf-drinks-spp-framework Greetings. I have been requested to review draft-ietf-drinks-spp-framework = for the Security Directorate. This review is being done during WG Last Call= instead of IETF Last Call as a special request. I note that literally no o= ne has spoken up in the WG during WG Last Call since it began three weeks a= go. SPPF is a protocol for provisioning session establishment data into data re= gistries and SIP service providers. Well, actually it's not. It is a descri= ption of the data format and some handwaving about how to transport that da= ta. The mandatory-to-implement transport is listed in a different document,= draft-ietf-drinks-spp-protocol-over-soap (for which there is no reference = in this document...). The transport protocol requirements listed in section 4 of this document ar= e fairly generic, as are the security requirements. The descriptions of the= transport requirements are fine. The security requirements are not so grea= t: while servers MUST be able to authenticate clients, confidentiality and = integrity protection SHOULD be provided. Given that the mandatory-to implem= ent transport is SOAP, this approximately translates to "must do some sort = or minimal client authentication, should consider using TLS but lots of cli= ents and servers probably won't actually do it". I think that undershoots m= oderns security practices, which would have TLS be mandatory. Even though this is a security review, I cannot resist a non-security quest= ion: SOAP? In 2012? Really? --Paul Hoffman _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From adrian@olddog.co.uk Sat Aug 25 02:27:26 2012 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 61CB621F8527; Sat, 25 Aug 2012 02:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xWQI2ktI9ru; Sat, 25 Aug 2012 02:27:25 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0A221F844F; Sat, 25 Aug 2012 02:27:25 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7P9RNfm027748; Sat, 25 Aug 2012 10:27:23 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7P9RLZW027728 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 25 Aug 2012 10:27:22 +0100 From: "Adrian Farrel" To: "'Donald Eastlake'" , , , References: In-Reply-To: Date: Sat, 25 Aug 2012 10:27:19 +0100 Message-ID: <198e01cd82a3$d3e43180$7bac9480$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHXehRvSsSDO+gN7IAsyMZT++BtTJdWUw+w Content-Language: en-gb Subject: Re: [secdir] draft-ietf-pce-hierarchy-fwk-04 SECDIR review X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 09:27:26 -0000 Thanks Donald. Adrian (this time I'm an author) > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of > Donald Eastlake > Sent: 23 August 2012 21:36 > To: iesg@ietf.org; secdir@ietf.org; draft-ietf-pce-hierarchy-fwk.all@tools.ietf.org > Subject: draft-ietf-pce-hierarchy-fwk-04 SECDIR review > > 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. > > This Informational draft discusses the use of the Path Computation > Element (PCE) architecture to determining routes through multiple > domains with different administration. This uses hierarchical PCE > processes that are heavily dependent on the PCE Protocol. > > The Security Consideration section of this draft is heavily dependent > on the Security Considerations in the PCE Protocol RFC 5440, which are > quite good, and also references Security Considerations in several > other RFCs including RFC 5327 for inter-AS path computation and Path > Keys in RFC 5520 as well as directly discussing aspects unique to or > particularly prominent in the area considered. > > I believe that security aspects of the technology being discussed in > this informational draft are well covered, directly or by reference, > and have no changes to recommend. > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com From shawn.emery@oracle.com Tue Aug 28 00:23:40 2012 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 6E3A311E80BF; Tue, 28 Aug 2012 00:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fY0msT9ROupF; Tue, 28 Aug 2012 00:23:40 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id E21DB11E808D; Tue, 28 Aug 2012 00:23:39 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7S7NcBk001288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 28 Aug 2012 07:23:39 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7S7NbYo021198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Aug 2012 07:23:37 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7S7NarS029372; Tue, 28 Aug 2012 02:23:37 -0500 Received: from [10.159.71.178] (/10.159.71.178) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 28 Aug 2012 00:23:36 -0700 Message-ID: <503C71A4.30709@oracle.com> Date: Tue, 28 Aug 2012 01:22:12 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:10.0.6esrpre) Gecko/20120731 Thunderbird/10.0.6 MIME-Version: 1.0 To: secdir@ietf.org References: <50065F08.1090307@oracle.com> In-Reply-To: <50065F08.1090307@oracle.com> Content-Type: multipart/alternative; boundary="------------030901080104060804000009" X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: iesg@ietf.org, draft-ietf-dnsop-rfc4641bis.all@tools.ietf.org Subject: [secdir] Review of draft-ietf-dnsop-rfc4641bis-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 07:23:40 -0000 This is a multi-part message in MIME format. --------------030901080104060804000009 Content-Type: text/plain; charset=ISO-8859-1; 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 informational draft describes the operational practices for administrating a DNSSEC environment. Specifically the management of keys and signatures in DNS. The draft intends to obsolete RFC 4641. The security considerations section does exist and is somewhat terse in its explanation of mitigating spoofing and DoS attacks. This should be expanded or at least a reference made. General comments: None. Editorial comments: Consistency: SEP is expanded, but not DS. s/purposes X will somewhere/purposes, X will be somewhere/ s/such as e.g. RFC 5011/e.g. RFC 5011/ Shawn. -- --------------030901080104060804000009 Content-Type: text/html; charset=ISO-8859-1 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 informational draft describes the operational practices for administrating a DNSSEC environment.  Specifically the management of keys and signatures in DNS.  The draft intends to obsolete RFC 4641.

The security considerations section does exist and is somewhat terse in its explanation of mitigating spoofing and DoS attacks.  This should be expanded or at least a reference made.

General comments:

None.

Editorial comments:

Consistency: SEP is expanded, but not DS.

s/purposes X will somewhere/purposes, X will be somewhere/
s/such as e.g.  RFC 5011/e.g. RFC 5011/

Shawn.
--
--------------030901080104060804000009-- From matthijs@nlnetlabs.nl Tue Aug 28 02:10:02 2012 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 00E7B21F854D; Tue, 28 Aug 2012 02:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLCOfUiBwgX7; Tue, 28 Aug 2012 02:10:01 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 951F321F854B; Tue, 28 Aug 2012 02:10:00 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:7dea:95c2:f2f9:298f] ([IPv6:2001:7b8:206:1:7dea:95c2:f2f9:298f]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id q7S99rlK027027 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 28 Aug 2012 11:09:54 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) X-DKIM: OpenDKIM Filter v2.6.7 open.nlnetlabs.nl q7S99rlK027027 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1346144996; bh=i4KW6wIJMmnc2qRl4WGeOmOOu50L31Glu5av5QvtqA0=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=Ce9vtwZ/rsuTKiBDjdtYM65BbZTjbimXi1b5rbBDJYaO7SPJ8DjGW/74Gs7+Ru4Hr IqTgrvSTJQ7Upl4MFpj99MvOyx1hAlzC4CEhOw9MoD5DvM7GgmwR0UVFeRfBik/y6a NvzLTga/CB8+ZAjxma40D836CiUL/2U9NTckBs0s= Message-ID: <503C8AE3.8070906@nlnetlabs.nl> Date: Tue, 28 Aug 2012 11:09:55 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Shawn Emery References: <50065F08.1090307@oracle.com> <503C71A4.30709@oracle.com> In-Reply-To: <503C71A4.30709@oracle.com> X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Tue, 28 Aug 2012 11:09:55 +0200 (CEST) X-Mailman-Approved-At: Tue, 28 Aug 2012 02:41:40 -0700 Cc: iesg@ietf.org, draft-ietf-dnsop-rfc4641bis.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-ietf-dnsop-rfc4641bis-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 09:10:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Shawn, Thanks for your review. On 08/28/2012 09:22 AM, Shawn 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 informational draft describes the operational practices for > administrating a DNSSEC environment. Specifically the management of > keys and signatures in DNS. The draft intends to obsolete RFC 4641. > > The security considerations section does exist and is somewhat terse in > its explanation of mitigating spoofing and DoS attacks. This should be > expanded or at least a reference made. How DNSSEC mitigates against spoofing attacks and does not protect against DoS attacks is explained in the DNSSEC RFCs (RFC 4033-4035). I have added a reference to these documents. Also, I have explained a bit more how not taking into account 'data propagation' properties will cause validation failures, making secured zones unavailable to security-aware resolvers. The proposed text is now: DNSSEC adds data origin authentication and data integrity to the DNS, using digital signatures over resource record sets. DNSSEC does not protect against denial of service attacks, nor does it provide confidentiality. For more general security considerations related to DNSSEC, please see RFC 4033 [RFC4033], RFC 4034 [RFC4034] and RFC 4035 [RFC4035]. This document tries to assess the operational considerations to maintain a stable and secure DNSSEC service. When performing key rollovers, it is important to keep in mind that it takes time for the data to be propagated to the verifying clients. Also important to notice is that this data may be cached. Not taking into account the 'data propagation' properties in the DNS may cause validation failures, because cached data may mismatch with data fetched from the authoritative servers. This will make secured zones unavailable to security-aware resolvers. Is this better? > > General comments: > > None. > > Editorial comments: > > Consistency: SEP is expanded, but not DS. I have expanded DS at its first occurrence. > > s/purposes X will somewhere/purposes, X will be somewhere/ > s/such as e.g. RFC 5011/e.g. RFC 5011/ Changed. The diff with the work in progress can be found here: http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-dnsop-rfc4641bis-12.txt&url2=http://www.nlnetlabs.nl/~matje/draft-ietf-dnsop-rfc4641bis.txt tinyurl: http://tinyurl.com/8luvedk The diff also contains other reviewers changes. Best regards, Matthijs > > Shawn. > -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQPIrjAAoJEA8yVCPsQCW5RV8H/jQrXSXs1ZnJHFWvGeamL/MS QG41CmBX0tYpW7QHT/YjcwBopXo/XuvHY3ITqMskeUfJjC5XNpvC5Uh2Gm+QZ5cs jvikzNG6DaaXpCKSWuXskHsLFm8Pzfu9geUkpgbULtaJNgxCvG15+z+cLVSbuMoY oZ7Gysec9kxklvqqTinfeMZAqNyROXew/lzTRYam6nlYePwAeV23h0Bu3JOm4yvd DF1F1UhZaqEiaBk6vUuDepS76irBLzSHHxqHXQ7JlFIAO/TegemqF+OZ6Bhd+HNp MlT5Tq+5nIF7+qR2oGD/j1sqnPxIJfI7dhdRB9aEXiJAx43m0WDZU+2k5f5HWL0= =Idp2 -----END PGP SIGNATURE----- From turners@ieca.com Tue Aug 28 04:24:33 2012 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 015E121F849A for ; Tue, 28 Aug 2012 04:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.095 X-Spam-Level: X-Spam-Status: No, score=-102.095 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvcx6g4PMgfN for ; Tue, 28 Aug 2012 04:24:32 -0700 (PDT) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [67.18.14.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8317821F848F for ; Tue, 28 Aug 2012 04:24:32 -0700 (PDT) Received: by gateway05.websitewelcome.com (Postfix, from userid 5007) id EC68075E3306; Tue, 28 Aug 2012 06:24:31 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway05.websitewelcome.com (Postfix) with ESMTP id E1E6275E32E6 for ; Tue, 28 Aug 2012 06:24:31 -0500 (CDT) Received: from [108.18.174.220] (port=62873 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1T6JuJ-0003iv-NU for secdir@ietf.org; Tue, 28 Aug 2012 06:24:31 -0500 Message-ID: <503CAA6F.30302@ieca.com> Date: Tue, 28 Aug 2012 07:24:31 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: secdir@ietf.org References: <20120809010519.15222.89232.idtracker@ietfa.amsl.com> In-Reply-To: <20120809010519.15222.89232.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120809010519.15222.89232.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.18.174.220]:62873 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [secdir] Fwd: I-D Action: draft-harkins-brainpool-ike-groups-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 11:24:33 -0000 BTW - Dan's submitted a draft about the topic we had in Vancouver. Comments are welcome. spt -------- Original Message -------- Subject: I-D Action: draft-harkins-brainpool-ike-groups-00.txt Date: Wed, 08 Aug 2012 18:05:19 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Brainpool Elliptic Curves for the IKE Group Description Registry Author(s) : Dan Harkins Filename : draft-harkins-brainpool-ike-groups-00.txt Pages : 26 Date : 2012-08-08 Abstract: This memo allocates code points for fourteen new elliptic curve domain parameter sets over finite prime fields into a registry established by The Internet Key Exchange (IKE). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-harkins-brainpool-ike-groups There's also a htmlized version available at: http://tools.ietf.org/html/draft-harkins-brainpool-ike-groups-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From stephen.farrell@cs.tcd.ie Tue Aug 28 04:32:54 2012 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 6A97A21F851B for ; Tue, 28 Aug 2012 04:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.894 X-Spam-Level: X-Spam-Status: No, score=-101.894 tagged_above=-999 required=5 tests=[AWL=-0.691, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1wUmHe+Lfr3 for ; Tue, 28 Aug 2012 04:32:48 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 5C10021F84C5 for ; Tue, 28 Aug 2012 04:32:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 6837217148B; Tue, 28 Aug 2012 12:32:45 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h=date :subject:from:x-mailer:message-id:content-type :content-transfer-encoding:mime-version:in-reply-to:references :received:received:x-virus-scanned; s=cs; t=1346153564; bh=5D34G 3vvKeSQ3h90r9T9WepAHEB+WNsuuxb7D3h0z+s=; b=hidIekSu9JZsH414QUvYn 2riIV2GP6XBhWuA9auTk3J1dyQc5nhZWo2t/zOwIaZYVO5cBcLrMsrlevZ3cvYLH xTCvV0eKwqMIseovfsQcGhh7QcBphmrBSpSzPZP1CvMfGpNrn14gBjCSYkRvQja8 vEY/B5BJWt/GswyD75QUcU7KdNaA0uSrHPdJnMeezXeK5mfU1rj2Y11wHIoW5nbi RkMrZ99laL7bojCM1dcImhnpwpZ9HS8Qb7285OYl3HcS4QUma6SnporNvvv3onKV xEKRhsjtMtgfRmrnk0lXe398VNQZ/jjbnNxDRldyw8x/Su4uMgSCKjNS2XsCuSPW A== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id wHCTLsGuWB6m; Tue, 28 Aug 2012 12:32:44 +0100 (IST) Received: from [10.36.195.160] (mobileinternet2.o2.ie [62.40.36.14]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 73DD6171474; Tue, 28 Aug 2012 12:32:44 +0100 (IST) References: <20120809010519.15222.89232.idtracker@ietfa.amsl.com> <503CAA6F.30302@ieca.com> In-Reply-To: <503CAA6F.30302@ieca.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <9035196F-001D-4E15-B6D6-30B59BEBBB01@cs.tcd.ie> X-Mailer: iPhone Mail (9B206) From: Stephen Farrell Date: Tue, 28 Aug 2012 12:31:58 +0100 To: Sean Turner Cc: "secdir@ietf.org" Subject: Re: [secdir] Fwd: I-D Action: draft-harkins-brainpool-ike-groups-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 11:32:54 -0000 On 28 Aug 2012, at 12:24, Sean Turner wrote: > BTW - Dan's submitted a draft about the topic we had in Vancouver. Comment= s are welcome. I've one: I didn't realize Dan wanted 14 code points. That seems a lot. S >=20 > spt >=20 > -------- Original Message -------- > Subject: I-D Action: draft-harkins-brainpool-ike-groups-00.txt > Date: Wed, 08 Aug 2012 18:05:19 -0700 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. >=20 >=20 > Title : Brainpool Elliptic Curves for the IKE Group Descripti= on Registry > Author(s) : Dan Harkins > Filename : draft-harkins-brainpool-ike-groups-00.txt > Pages : 26 > Date : 2012-08-08 >=20 > Abstract: > This memo allocates code points for fourteen new elliptic curve > domain parameter sets over finite prime fields into a registry > established by The Internet Key Exchange (IKE). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-harkins-brainpool-ike-groups >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-harkins-brainpool-ike-groups-00 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From ynir@checkpoint.com Tue Aug 28 04:52:58 2012 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 6B10D11E8101 for ; Tue, 28 Aug 2012 04:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.44 X-Spam-Level: X-Spam-Status: No, score=-10.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0w1gzBqEucI for ; Tue, 28 Aug 2012 04:52:57 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 550FB11E80F6 for ; Tue, 28 Aug 2012 04:52:57 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id q7SBqmti009909; Tue, 28 Aug 2012 14:52:48 +0300 X-CheckPoint: {503CAD2B-0-1B221DC2-4FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 28 Aug 2012 14:52:44 +0300 From: Yoav Nir To: Stephen Farrell Date: Tue, 28 Aug 2012 14:52:44 +0300 Thread-Topic: [secdir] I-D Action: draft-harkins-brainpool-ike-groups-00.txt Thread-Index: Ac2FE6IIjcWrSValQ3yW5vF1s0rHHQ== Message-ID: <73F8581B-716F-4466-8F6B-645206789C5E@checkpoint.com> References: <20120809010519.15222.89232.idtracker@ietfa.amsl.com> <503CAA6F.30302@ieca.com> <9035196F-001D-4E15-B6D6-30B59BEBBB01@cs.tcd.ie> In-Reply-To: <9035196F-001D-4E15-B6D6-30B59BEBBB01@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11a65c226f595a9e8811fb4569ed442144af7c9b4f Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "secdir@ietf.org" Subject: Re: [secdir] I-D Action: draft-harkins-brainpool-ike-groups-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 11:52:58 -0000 On Aug 28, 2012, at 2:31 PM, Stephen Farrell wrote: >=20 >=20 > On 28 Aug 2012, at 12:24, Sean Turner wrote: >=20 >> BTW - Dan's submitted a draft about the topic we had in Vancouver. Comme= nts are welcome. >=20 > I've one: I didn't realize Dan wanted 14 code points. That seems a lot. BTW: Johannes Merkle submitted http://tools.ietf.org/html/draft-merkle-ikev= 2-ke-brainpool-00 that requests points for the same curves for IKEv2. I'm wondering if we really need 7 different strengths as opposed to, say, 3= , and whether we need both a twisted and non-twisted variation for each. Ne= ither document discusses the why one would prefer the twisted to the non-tw= isted variant, or the non-twisted to the twisted. RFC 5639 does not give su= ch considerations either, but documents that relate to protocols should IMO= . Yoav From william.polk@nist.gov Tue Aug 28 07:28:11 2012 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 CCCAF21F8468 for ; Tue, 28 Aug 2012 07:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NP0cM0XJaqA4 for ; Tue, 28 Aug 2012 07:28:11 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id C934421F843E for ; Tue, 28 Aug 2012 07:28:10 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.379.0; Tue, 28 Aug 2012 10:27:52 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Tue, 28 Aug 2012 10:28:09 -0400 From: "Polk, William T." To: "dharkins@arubanetworks.com" Content-Class: urn:content-classes:message Date: Tue, 28 Aug 2012 10:28:08 -0400 Thread-Topic: [secdir] I-D Action: draft-harkins-brainpool-ike-groups-00.txt Thread-Index: Ac2FE6IIjcWrSValQ3yW5vF1s0rHHQAE8k0VAAB7SWg= Message-ID: References: <20120809010519.15222.89232.idtracker@ietfa.amsl.com> <503CAA6F.30302@ieca.com> <9035196F-001D-4E15-B6D6-30B59BEBBB01@cs.tcd.ie>, <73F8581B-716F-4466-8F6B-645206789C5E@checkpoint.com> In-Reply-To: <73F8581B-716F-4466-8F6B-645206789C5E@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-mimectl: Produced By Microsoft Exchange V8.2.176.0 Content-Type: multipart/alternative; boundary="_000_DDAF3F154C724CC9AC4D29D7496A7BD3mimectl_" MIME-Version: 1.0 Cc: "secdir@ietf.org" Subject: Re: [secdir] I-D Action: draft-harkins-brainpool-ike-groups-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 14:28:11 -0000 --_000_DDAF3F154C724CC9AC4D29D7496A7BD3mimectl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi Dan, Thanks for getting this work underway. First observation: I think a reference to RFC 6090 is warranted. Second Observation: 80 bit crypto is on its last legs. Do we really need t= o specify curves with less than 112 bit strength? Third Observation: The security considerations section does not address the= security strength of 192 or 384 bit curves. It feels incomplete, although= I guess most readers can work it out for themselves. General observation: my experience is that specifying so many curves dilute= s implementer enthusiasm. We finally started to get some interest in ECC s= upport for FIPS 201 when we pared the list down from six curves in three fa= milies to two prime curves (P-256 and P-384). Specifying two alternatives for each security level feels like an implement= er's nightmare. Are Brainpool implementations general enough to handle the= normal and twisted curves at a particular level? If the implementations a= re agnostic, maybe that should get noted in yout insecurity considerations. Tim ________________________________ From: secdir-bounces@ietf.org [secdir-bounces@ietf.org] On Behalf Of Yoav N= ir [ynir@checkpoint.com] Sent: Tuesday, August 28, 2012 7:52 AM To: Stephen Farrell Cc: secdir@ietf.org Subject: Re: [secdir] I-D Action: draft-harkins-brainpool-ike-groups-00.txt On Aug 28, 2012, at 2:31 PM, Stephen Farrell wrote: > > > On 28 Aug 2012, at 12:24, Sean Turner wrote: > >> BTW - Dan's submitted a draft about the topic we had in Vancouver. Comme= nts are welcome. > > I've one: I didn't realize Dan wanted 14 code points. That seems a lot. BTW: Johannes Merkle submitted http://tools.ietf.org/html/draft-merkle-ikev= 2-ke-brainpool-00 that requests points for the same curves for IKEv2. I'm wondering if we really need 7 different strengths as opposed to, say, 3= , and whether we need both a twisted and non-twisted variation for each. Ne= ither document discusses the why one would prefer the twisted to the non-tw= isted variant, or the non-twisted to the twisted. RFC 5639 does not give su= ch considerations either, but documents that relate to protocols should IMO= . Yoav _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --_000_DDAF3F154C724CC9AC4D29D7496A7BD3mimectl_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi Dan,<= /DIV>
 
Thanks for gett= ing this work underway.
 
First observati= on: I think a reference to RFC 6090 is warranted.
 
Second Observation: 80 bit cryp= to is on its last legs.  Do we really need to specify curves with less= than 112 bit strength? 
 
Third Observation: The security= considerations section does not address the security strength of 192 or 38= 4 bit curves.  It feels incomplete, although I guess most readers can = work it out for themselves.
 
General observation: my experie= nce is that specifying so many curves dilutes implementer enthusiasm. = We finally started to get some interest in ECC support for FIPS 201 when w= e pared the list down from six curves in three families to two prime c= urves (P-256 and P-384).
 
Specifying two alternatives for= each security level feels like an implementer's nightmare. = Are Brainpool implementations general enough to handle the normal and twis= ted curves at a particular level?  If the implementations are agnostic= , maybe that should get noted in yout insecurity considerations.
 
Tim
 
From: secdir-bounces@ie= tf.org [secdir-bounces@ietf.org] On Behalf Of Yoav Nir [ynir@checkpoint.com= ]
Sent: Tuesday, August 28, 2012 7:52 AM
To: Stephen Fa= rrell
Cc: secdir@ietf.org
Subject: Re: [secdir] I-D Act= ion: draft-harkins-brainpool-ike-groups-00.txt


On Aug 28, 2012, at 2:31 PM, Stephen Farrell wro= te:

>
>
> On 28 Aug 2012, at 12:24, Sean Turner <= ;turners@ieca.com> wrote:
>
>> BTW - Dan's submitted a d= raft about the topic we had in Vancouver. Comments are welcome.
> > I've one: I didn't realize Dan wanted 14 code points. That seems a lo= t.

BTW: Johannes Merkle submitted http://tools.ietf.o= rg/html/draft-merkle-ikev2-ke-brainpool-00 that requests points for the= same curves for IKEv2.

I'm wondering if we really need 7 different = strengths as opposed to, say, 3, and whether we need both a twisted and non= -twisted variation for each. Neither document discusses the why one would p= refer the twisted to the non-twisted variant, or the non-twisted to the twi= sted. RFC 5639 does not give such considerations either, but documents that= relate to protocols should IMO.

Yoav

_______________________= ________________________
secdir mailing list
secdir@ietf.org
https:/= /www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf= .org/area/sec/trac/wiki/SecDirReview
 --_000_DDAF3F154C724CC9AC4D29D7496A7BD3mimectl_-- From dharkins@lounge.org Tue Aug 28 08:48:18 2012 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 4478E21F851C for ; Tue, 28 Aug 2012 08:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.219 X-Spam-Level: X-Spam-Status: No, score=-6.219 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3TZDr8rCkb9 for ; Tue, 28 Aug 2012 08:48:17 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2EE21F851B for ; Tue, 28 Aug 2012 08:48:17 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 28CAE1022404A; Tue, 28 Aug 2012 08:48:17 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 28 Aug 2012 08:48:17 -0700 (PDT) Message-ID: In-Reply-To: References: <20120809010519.15222.89232.idtracker@ietfa.amsl.com> <503CAA6F.30302@ieca.com> <9035196F-001D-4E15-B6D6-30B59BEBBB01@cs.tcd.ie>, <73F8581B-716F-4466-8F6B-645206789C5E@checkpoint.com> Date: Tue, 28 Aug 2012 08:48:17 -0700 (PDT) From: "Dan Harkins" To: "Polk, William T." User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "dharkins@arubanetworks.com" , "secdir@ietf.org" Subject: Re: [secdir] I-D Action: draft-harkins-brainpool-ike-groups-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 15:48:18 -0000 Hi Tim, On Tue, August 28, 2012 7:28 am, Polk, William T. wrote: > hi Dan, > > Thanks for getting this work underway. > > First observation: I think a reference to RFC 6090 is warranted. Yes, good point. I'll add a reference to it at the start of section 2 where the equation for the curves is noted. > Second Observation: 80 bit crypto is on its last legs. Do we really need > to specify curves with less than 112 bit strength? There is the notion that "if it's worth protecting, it's worth protecting properly" and I'm not sure of the current usefulness of 80-bit crypto but this is more for completeness. The Brainpool defined them and I'm just asking for a magic numbers to be assigned to all the defined curves. That also is the the answer to the "14 code points, oh my!" comments. Note that we still have over 32,000 code points available so we're talking about taking 4/100th of 1%. > Third Observation: The security considerations section does not address > the security strength of 192 or 384 bit curves. It feels incomplete, > although I guess most readers can work it out for themselves. I refer the reader to RFC 5639 which mentions the security considerations of the curves. If you like I can also mention something about how the best known attacks run on the order of the square root of the order. Would that be satisfactory? > General observation: my experience is that specifying so many curves > dilutes implementer enthusiasm. We finally started to get some interest > in ECC support for FIPS 201 when we pared the list down from six curves in > three families to two prime curves (P-256 and P-384). That is a very good observation. I guess we should talk to the Brainpool. Their consortium seems to have some large and important companies in it. The concern is that one of the members would promote the use of a particular curve in some operational or regulatory fashion and it's important that the users of the IKEv1 registry be able to work anywhere. > Specifying two alternatives for each security level feels like an > implementer's nightmare. Are Brainpool implementations general enough to > handle the normal and twisted curves at a particular level? If the > implementations are agnostic, maybe that should get noted in yout > insecurity considerations. You're right, it is a nightmare! As it turns out quite a few of my test vectors are wrong. I think implementations will be agnostic and I will mention agnosticism. thanks for your comments! Dan. > Tim > > ________________________________ > From: secdir-bounces@ietf.org [secdir-bounces@ietf.org] On Behalf Of Yoav > Nir [ynir@checkpoint.com] > Sent: Tuesday, August 28, 2012 7:52 AM > To: Stephen Farrell > Cc: secdir@ietf.org > Subject: Re: [secdir] I-D Action: > draft-harkins-brainpool-ike-groups-00.txt > > > On Aug 28, 2012, at 2:31 PM, Stephen Farrell wrote: > >> >> >> On 28 Aug 2012, at 12:24, Sean Turner wrote: >> >>> BTW - Dan's submitted a draft about the topic we had in Vancouver. >>> Comments are welcome. >> >> I've one: I didn't realize Dan wanted 14 code points. That seems a lot. > > BTW: Johannes Merkle submitted > http://tools.ietf.org/html/draft-merkle-ikev2-ke-brainpool-00 that > requests points for the same curves for IKEv2. > > I'm wondering if we really need 7 different strengths as opposed to, say, > 3, and whether we need both a twisted and non-twisted variation for each. > Neither document discusses the why one would prefer the twisted to the > non-twisted variant, or the non-twisted to the twisted. RFC 5639 does not > give such considerations either, but documents that relate to protocols > should IMO. > > Yoav > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > From yaronf.ietf@gmail.com Tue Aug 28 09:05:50 2012 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 788D711E80A5; Tue, 28 Aug 2012 09:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaxwE7eotYcM; Tue, 28 Aug 2012 09:05:49 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5E511E808D; Tue, 28 Aug 2012 09:05:48 -0700 (PDT) Received: by bkty12 with SMTP id y12so1437273bkt.31 for ; Tue, 28 Aug 2012 09:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=y8Z275qQJVu23z8+c6/36N46WB9IiUjbu6Pe7QzzbuI=; b=QYXs0xkMB+yq8K6+L7q3Fv0BJ8ncom/hrt+4PSUyg+lI/wdstq2SYOWSohp4qh60o4 PcKqLc6audWn4Azvuo71ST6sTw0XWL5TevLHE2WDrYB9vdszPsh9deWdjuQn1kx9u/tK s0CMFpXDvai4bTsnRp301TxNodumhJi2p7nOsco/Jse2Tal7YfdRWkIREfnnrCzw7wVL uMYvOVeYs1BszgW62xVD2KITD+JDM96VXhNI8bc8HhHWvbky0Bzdzjq+XqFMYfsxlLP3 RY/T3pTQHb8fWAKWOOzQ+3HCanZdjeNdOwRzdbhhELCEcAX8EQeFpe32I8upJFU+DZ3Y C8DQ== Received: by 10.204.157.18 with SMTP id z18mr5292381bkw.16.1346169947727; Tue, 28 Aug 2012 09:05:47 -0700 (PDT) Received: from [10.0.0.8] ([109.67.151.97]) by mx.google.com with ESMTPS id n5sm13150103bkv.14.2012.08.28.09.05.46 (version=SSLv3 cipher=OTHER); Tue, 28 Aug 2012 09:05:47 -0700 (PDT) Message-ID: <503CEC59.9080601@gmail.com> Date: Tue, 28 Aug 2012 19:05:45 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Dan Harkins References: <20120809010519.15222.89232.idtracker@ietfa.amsl.com> <503CAA6F.30302@ieca.com> <9035196F-001D-4E15-B6D6-30B59BEBBB01@cs.tcd.ie>, <73F8581B-716F-4466-8F6B-645206789C5E@checkpoint.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , "dharkins@arubanetworks.com" , "Polk, William T." , "secdir@ietf.org" Subject: Re: [secdir] I-D Action: draft-harkins-brainpool-ike-groups-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 16:05:50 -0000 Hi Tim, Dan, can you please move this discussion to the ipsecme mailing list (copied)? I believe that is a more appropriate venue to discuss IKE code points. Thanks, Yaron On 08/28/2012 06:48 PM, Dan Harkins wrote: > > Hi Tim, > > On Tue, August 28, 2012 7:28 am, Polk, William T. wrote: >> hi Dan, >> >> Thanks for getting this work underway. >> >> First observation: I think a reference to RFC 6090 is warranted. > > Yes, good point. I'll add a reference to it at the start of section 2 where > the equation for the curves is noted. > >> Second Observation: 80 bit crypto is on its last legs. Do we really need >> to specify curves with less than 112 bit strength? > > There is the notion that "if it's worth protecting, it's worth protecting > properly" and I'm not sure of the current usefulness of 80-bit crypto but > this is more for completeness. The Brainpool defined them and I'm just > asking for a magic numbers to be assigned to all the defined curves. > > That also is the the answer to the "14 code points, oh my!" comments. > Note that we still have over 32,000 code points available so we're talking > about taking 4/100th of 1%. > >> Third Observation: The security considerations section does not address >> the security strength of 192 or 384 bit curves. It feels incomplete, >> although I guess most readers can work it out for themselves. > > I refer the reader to RFC 5639 which mentions the security considerations > of the curves. If you like I can also mention something about how the best > known attacks run on the order of the square root of the order. Would that > be satisfactory? > >> General observation: my experience is that specifying so many curves >> dilutes implementer enthusiasm. We finally started to get some interest >> in ECC support for FIPS 201 when we pared the list down from six curves in >> three families to two prime curves (P-256 and P-384). > > That is a very good observation. I guess we should talk to the Brainpool. > Their consortium seems to have some large and important companies in > it. The concern is that one of the members would promote the use of a > particular curve in some operational or regulatory fashion and it's > important that the users of the IKEv1 registry be able to work anywhere. > >> Specifying two alternatives for each security level feels like an >> implementer's nightmare. Are Brainpool implementations general enough to >> handle the normal and twisted curves at a particular level? If the >> implementations are agnostic, maybe that should get noted in yout >> insecurity considerations. > > You're right, it is a nightmare! As it turns out quite a few of my test > vectors are wrong. I think implementations will be agnostic and I will > mention agnosticism. > > thanks for your comments! > > Dan. > >> Tim >> >> ________________________________ >> From: secdir-bounces@ietf.org [secdir-bounces@ietf.org] On Behalf Of Yoav >> Nir [ynir@checkpoint.com] >> Sent: Tuesday, August 28, 2012 7:52 AM >> To: Stephen Farrell >> Cc: secdir@ietf.org >> Subject: Re: [secdir] I-D Action: >> draft-harkins-brainpool-ike-groups-00.txt >> >> >> On Aug 28, 2012, at 2:31 PM, Stephen Farrell wrote: >> >>> >>> >>> On 28 Aug 2012, at 12:24, Sean Turner wrote: >>> >>>> BTW - Dan's submitted a draft about the topic we had in Vancouver. >>>> Comments are welcome. >>> >>> I've one: I didn't realize Dan wanted 14 code points. That seems a lot. >> >> BTW: Johannes Merkle submitted >> http://tools.ietf.org/html/draft-merkle-ikev2-ke-brainpool-00 that >> requests points for the same curves for IKEv2. >> >> I'm wondering if we really need 7 different strengths as opposed to, say, >> 3, and whether we need both a twisted and non-twisted variation for each. >> Neither document discusses the why one would prefer the twisted to the >> non-twisted variant, or the non-twisted to the twisted. RFC 5639 does not >> give such considerations either, but documents that relate to protocols >> should IMO. >> >> Yoav >> >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >> > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > From dharkins@lounge.org Tue Aug 28 10:49:04 2012 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 6E4BF21F85FC; Tue, 28 Aug 2012 10:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.221 X-Spam-Level: X-Spam-Status: No, score=-6.221 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Q56aoAlw-7D; Tue, 28 Aug 2012 10:49:03 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 99C4E21F8597; Tue, 28 Aug 2012 10:49:03 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id E8ECA1022404A; Tue, 28 Aug 2012 10:49:02 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 28 Aug 2012 10:49:03 -0700 (PDT) Message-ID: In-Reply-To: <503CEC59.9080601@gmail.com> References: <20120809010519.15222.89232.idtracker@ietfa.amsl.com> <503CAA6F.30302@ieca.com> <9035196F-001D-4E15-B6D6-30B59BEBBB01@cs.tcd.ie>, <73F8581B-716F-4466-8F6B-645206789C5E@checkpoint.com> <503CEC59.9080601@gmail.com> Date: Tue, 28 Aug 2012 10:49:03 -0700 (PDT) From: "Dan Harkins" To: "Yaron Sheffer" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: IPsecme WG , "dharkins@arubanetworks.com" , "secdir@ietf.org" Subject: Re: [secdir] [IPsec] I-D Action: draft-harkins-brainpool-ike-groups-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 17:49:04 -0000 Hi Yaron, On Tue, August 28, 2012 9:05 am, Yaron Sheffer wrote: > Hi Tim, Dan, > > can you please move this discussion to the ipsecme mailing list > (copied)? I believe that is a more appropriate venue to discuss IKE code > points. When the IEEE liaison brought up this issue, your co-chairman said, "Yaron and I should "not* be part of this discussion because the issue is *not* an IPsecME WG issue. It is not in our charter to make additions to the obsoleted-but-still-widely-used IKEv1 protocol." He is also the one who insisted on the note that the draft adds to the registry, which sort of makes this not an IKE code point discussion. If this is an IKE discussion, I'd be happy to discuss this on the ipsecme list and I'd be, therefore, happy to remove the note and the corresponding "Insecurity Considerations" from the draft. But maybe you guys should go off and decide what you want. Dan. > > Thanks, > Yaron > > On 08/28/2012 06:48 PM, Dan Harkins wrote: >> >> Hi Tim, >> >> On Tue, August 28, 2012 7:28 am, Polk, William T. wrote: >>> hi Dan, >>> >>> Thanks for getting this work underway. >>> >>> First observation: I think a reference to RFC 6090 is warranted. >> >> Yes, good point. I'll add a reference to it at the start of section 2 >> where >> the equation for the curves is noted. >> >>> Second Observation: 80 bit crypto is on its last legs. Do we really >>> need >>> to specify curves with less than 112 bit strength? >> >> There is the notion that "if it's worth protecting, it's worth >> protecting >> properly" and I'm not sure of the current usefulness of 80-bit crypto >> but >> this is more for completeness. The Brainpool defined them and I'm just >> asking for a magic numbers to be assigned to all the defined curves. >> >> That also is the the answer to the "14 code points, oh my!" comments. >> Note that we still have over 32,000 code points available so we're >> talking >> about taking 4/100th of 1%. >> >>> Third Observation: The security considerations section does not address >>> the security strength of 192 or 384 bit curves. It feels incomplete, >>> although I guess most readers can work it out for themselves. >> >> I refer the reader to RFC 5639 which mentions the security >> considerations >> of the curves. If you like I can also mention something about how the >> best >> known attacks run on the order of the square root of the order. Would >> that >> be satisfactory? >> >>> General observation: my experience is that specifying so many curves >>> dilutes implementer enthusiasm. We finally started to get some >>> interest >>> in ECC support for FIPS 201 when we pared the list down from six curves >>> in >>> three families to two prime curves (P-256 and P-384). >> >> That is a very good observation. I guess we should talk to the >> Brainpool. >> Their consortium seems to have some large and important companies in >> it. The concern is that one of the members would promote the use of a >> particular curve in some operational or regulatory fashion and it's >> important that the users of the IKEv1 registry be able to work anywhere. >> >>> Specifying two alternatives for each security level feels like an >>> implementer's nightmare. Are Brainpool implementations general enough >>> to >>> handle the normal and twisted curves at a particular level? If the >>> implementations are agnostic, maybe that should get noted in yout >>> insecurity considerations. >> >> You're right, it is a nightmare! As it turns out quite a few of my >> test >> vectors are wrong. I think implementations will be agnostic and I will >> mention agnosticism. >> >> thanks for your comments! >> >> Dan. >> >>> Tim >>> >>> ________________________________ >>> From: secdir-bounces@ietf.org [secdir-bounces@ietf.org] On Behalf Of >>> Yoav >>> Nir [ynir@checkpoint.com] >>> Sent: Tuesday, August 28, 2012 7:52 AM >>> To: Stephen Farrell >>> Cc: secdir@ietf.org >>> Subject: Re: [secdir] I-D Action: >>> draft-harkins-brainpool-ike-groups-00.txt >>> >>> >>> On Aug 28, 2012, at 2:31 PM, Stephen Farrell wrote: >>> >>>> >>>> >>>> On 28 Aug 2012, at 12:24, Sean Turner wrote: >>>> >>>>> BTW - Dan's submitted a draft about the topic we had in Vancouver. >>>>> Comments are welcome. >>>> >>>> I've one: I didn't realize Dan wanted 14 code points. That seems a >>>> lot. >>> >>> BTW: Johannes Merkle submitted >>> http://tools.ietf.org/html/draft-merkle-ikev2-ke-brainpool-00 that >>> requests points for the same curves for IKEv2. >>> >>> I'm wondering if we really need 7 different strengths as opposed to, >>> say, >>> 3, and whether we need both a twisted and non-twisted variation for >>> each. >>> Neither document discusses the why one would prefer the twisted to the >>> non-twisted variant, or the non-twisted to the twisted. RFC 5639 does >>> not >>> give such considerations either, but documents that relate to protocols >>> should IMO. >>> >>> Yoav >>> >>> _______________________________________________ >>> secdir mailing list >>> secdir@ietf.org >>> https://www.ietf.org/mailman/listinfo/secdir >>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >>> _______________________________________________ >>> secdir mailing list >>> secdir@ietf.org >>> https://www.ietf.org/mailman/listinfo/secdir >>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >>> >> >> >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >> > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From paul.hoffman@vpnc.org Tue Aug 28 11:18:32 2012 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 1D0F721F85DA; Tue, 28 Aug 2012 11:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5fHfPQZTAr9; Tue, 28 Aug 2012 11:18:31 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7D221F85F7; Tue, 28 Aug 2012 11:18:31 -0700 (PDT) Received: from [10.20.30.108] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q7SIIQ6M013774 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 28 Aug 2012 11:18:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman X-Priority: 3 (Normal) In-Reply-To: Date: Tue, 28 Aug 2012 11:18:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120809010519.15222.89232.idtracker@ietfa.amsl.com> <503CAA6F.30302@ieca.com> <9035196F-001D-4E15-B6D6-30B59BEBBB01@cs.tcd.ie>, <73F8581B-716F-4466-8F6B-645206789C5E@checkpoint.com> <503CEC59.9080601@gmail.com> To: Dan Harkins X-Mailer: Apple Mail (2.1486) Cc: IPsecme WG , secdir Subject: Re: [secdir] [IPsec] I-D Action: draft-harkins-brainpool-ike-groups-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 18:18:32 -0000 On Aug 28, 2012, at 10:49 AM, Dan Harkins wrote: > When the IEEE liaison brought up this issue, your co-chairman > said, "Yaron and I should "not* be part of this discussion because > the issue is *not* an IPsecME WG issue. It is not in our charter > to make additions to the obsoleted-but-still-widely-used IKEv1 > protocol." He is also the one who insisted on the note that the > draft adds to the registry, which sort of makes this not an IKE > code point discussion. I was with you until that last phrase. It most certainly is an IKEv1 = code point discussion. > If this is an IKE discussion, I'd be happy to discuss this on the > ipsecme list and I'd be, therefore, happy to remove the note and the > corresponding "Insecurity Considerations" from the draft. >=20 > But maybe you guys should go off and decide what you want. What I want is for you to be less snarky in your communication, both = on-list and in the Internet-Drafts you write. I would also want you to = be clearer in your drafts when you are talking about IKEv1 or IKEv2: in = this draft, even in the filename, you kind of hid that. Whether or not you want to do those, I want the ADs to decide whether it = is appropriate to do more work on IKEv1, such as adding these curves to = the IKEv1 registries. If they think the work is appropriate, they can = also say where it should be done. --Paul Hoffman= From dharkins@lounge.org Tue Aug 28 11:54:10 2012 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 8C24621F860E; Tue, 28 Aug 2012 11:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.223 X-Spam-Level: X-Spam-Status: No, score=-6.223 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnwXmhWmsPiu; Tue, 28 Aug 2012 11:54:10 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1144721F860B; Tue, 28 Aug 2012 11:54:10 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 9DCFB1022404A; Tue, 28 Aug 2012 11:54:09 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 28 Aug 2012 11:54:09 -0700 (PDT) Message-ID: <6c1ddd2baf1480f6e7abeab6ac618402.squirrel@www.trepanning.net> In-Reply-To: References: <20120809010519.15222.89232.idtracker@ietfa.amsl.com> <503CAA6F.30302@ieca.com> <9035196F-001D-4E15-B6D6-30B59BEBBB01@cs.tcd.ie>, <73F8581B-716F-4466-8F6B-645206789C5E@checkpoint.com> <503CEC59.9080601@gmail.com> Date: Tue, 28 Aug 2012 11:54:09 -0700 (PDT) From: "Dan Harkins" To: "Paul Hoffman" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: IPsecme WG , secdir Subject: Re: [secdir] [IPsec] I-D Action: draft-harkins-brainpool-ike-groups-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 18:54:10 -0000 On Tue, August 28, 2012 11:18 am, Paul Hoffman wrote: > > On Aug 28, 2012, at 10:49 AM, Dan Harkins wrote: > >> When the IEEE liaison brought up this issue, your co-chairman >> said, "Yaron and I should "not* be part of this discussion because >> the issue is *not* an IPsecME WG issue. It is not in our charter >> to make additions to the obsoleted-but-still-widely-used IKEv1 >> protocol." He is also the one who insisted on the note that the >> draft adds to the registry, which sort of makes this not an IKE >> code point discussion. > > I was with you until that last phrase. It most certainly is an IKEv1 code > point discussion. If you insist that the registry say "not for IKEv1" then the code points are not for IKEv1 and any discussion about code points that are not for IKEv1 is not an IKEv1 code point discussion. >> If this is an IKE discussion, I'd be happy to discuss this on the >> ipsecme list and I'd be, therefore, happy to remove the note and the >> corresponding "Insecurity Considerations" from the draft. >> >> But maybe you guys should go off and decide what you want. > > What I want is for you to be less snarky in your communication, both > on-list and in the Internet-Drafts you write. I would also want you to be > clearer in your drafts when you are talking about IKEv1 or IKEv2: in this > draft, even in the filename, you kind of hid that. Please rephrase your wants into specific comments on the draft that I can then accept, counter, or reject. And please do not send them to the IPsecME list because, as you said, this "is *not* an IPsecME WG issue" (emphasis yours). > Whether or not you want to do those, I want the ADs to decide whether it > is appropriate to do more work on IKEv1, such as adding these curves to > the IKEv1 registries. If they think the work is appropriate, they can also > say where it should be done. They already did; you were there. Dan. From shawn.emery@oracle.com Wed Aug 29 00:54:25 2012 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 2492021F84F2; Wed, 29 Aug 2012 00:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Wl+tAxfej4h; Wed, 29 Aug 2012 00:54:24 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 392DD21F84D8; Wed, 29 Aug 2012 00:54:24 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7T7sLeC008896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 29 Aug 2012 07:54:22 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7T7sLdi027182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Aug 2012 07:54:21 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7T7sKGU029694; Wed, 29 Aug 2012 02:54:20 -0500 Received: from [10.159.87.39] (/10.159.87.39) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 29 Aug 2012 00:54:20 -0700 Message-ID: <503DCA56.5040301@oracle.com> Date: Wed, 29 Aug 2012 01:52:54 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:10.0.6esrpre) Gecko/20120731 Thunderbird/10.0.6 MIME-Version: 1.0 To: Matthijs Mekking References: <50065F08.1090307@oracle.com> <503C71A4.30709@oracle.com> <503C8AE3.8070906@nlnetlabs.nl> In-Reply-To: <503C8AE3.8070906@nlnetlabs.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: iesg@ietf.org, draft-ietf-dnsop-rfc4641bis.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-ietf-dnsop-rfc4641bis-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 07:54:25 -0000 On 08/28/12 03:09 AM, Matthijs Mekking wrote: > On 08/28/2012 09:22 AM, Shawn 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 informational draft describes the operational practices for >> administrating a DNSSEC environment. Specifically the management of >> keys and signatures in DNS. The draft intends to obsolete RFC 4641. >> >> The security considerations section does exist and is somewhat terse in >> its explanation of mitigating spoofing and DoS attacks. This should be >> expanded or at least a reference made. > How DNSSEC mitigates against spoofing attacks and does not protect > against DoS attacks is explained in the DNSSEC RFCs (RFC 4033-4035). I > have added a reference to these documents. Also, I have explained a bit > more how not taking into account 'data propagation' properties will > cause validation failures, making secured zones unavailable to > security-aware resolvers. The proposed text is now: > > > DNSSEC adds data origin authentication and data integrity to the DNS, > using digital signatures over resource record sets. DNSSEC does not > protect against denial of service attacks, nor does it provide > confidentiality. For more general security considerations related to > DNSSEC, please see RFC 4033 [RFC4033], RFC 4034 [RFC4034] and RFC > 4035 [RFC4035]. > > This document tries to assess the operational considerations to > maintain a stable and secure DNSSEC service. When performing key > rollovers, it is important to keep in mind that it takes time for the > data to be propagated to the verifying clients. Also important to > notice is that this data may be cached. Not taking into account the > 'data propagation' properties in the DNS may cause validation > failures, because cached data may mismatch with data fetched from the > authoritative servers. This will make secured zones unavailable to > security-aware resolvers. > > > Is this better? Yes, this resolves my concerns. Thanks. >> General comments: >> >> None. >> >> Editorial comments: >> >> Consistency: SEP is expanded, but not DS. > I have expanded DS at its first occurrence. > >> s/purposes X will somewhere/purposes, X will be somewhere/ >> s/such as e.g. RFC 5011/e.g. RFC 5011/ > Changed. > > The diff with the work in progress can be found here: > > http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-dnsop-rfc4641bis-12.txt&url2=http://www.nlnetlabs.nl/~matje/draft-ietf-dnsop-rfc4641bis.txt > > tinyurl: http://tinyurl.com/8luvedk > > The diff also contains other reviewers changes. These updates look good. Regards, Shawn. -- From kivinen@iki.fi Wed Aug 29 07:28:52 2012 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 8D04921F8527 for ; Wed, 29 Aug 2012 07:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.539 X-Spam-Level: X-Spam-Status: No, score=-103.539 tagged_above=-999 required=5 tests=[AWL=1.060, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QITm6hHQK8zL for ; Wed, 29 Aug 2012 07:28:52 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9B48821F851E for ; Wed, 29 Aug 2012 07:28:50 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id q7TEScuN005447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Aug 2012 17:28:38 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q7TESbWk029518; Wed, 29 Aug 2012 17:28:37 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20542.10005.144001.210338@fireball.kivinen.iki.fi> Date: Wed, 29 Aug 2012 17:28:37 +0300 From: Tero Kivinen To: Stephen Farrell In-Reply-To: <9035196F-001D-4E15-B6D6-30B59BEBBB01@cs.tcd.ie> References: <20120809010519.15222.89232.idtracker@ietfa.amsl.com> <503CAA6F.30302@ieca.com> <9035196F-001D-4E15-B6D6-30B59BEBBB01@cs.tcd.ie> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 17 min X-Total-Time: 19 min Cc: "secdir@ietf.org" Subject: Re: [secdir] Fwd: I-D Action: draft-harkins-brainpool-ike-groups-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 14:28:52 -0000 Stephen Farrell writes: > On 28 Aug 2012, at 12:24, Sean Turner wrote: > > BTW - Dan's submitted a draft about the topic we had in Vancouver. > > Comments are welcome. > > I've one: I didn't realize Dan wanted 14 code points. That seems a > lot. BTW, I think it was bit misstated in secdir lunch that the 802.11-2012 cannot be changed anymore. IEEE started 54-day Comment Collection perioid for IEEE Std-802.11-2012 at 2012-07-20 and that will end 2012-09-12. I would expect that if they are still collecting comments for the draft it can also be still modified. Of course it might be that they are not willing to change it anymore, but at least I already submitted comments for requesting change (I proposed creating completely new registry copied from IKEv1 for just this SAE use, i.e. change text on page 1176 in subclause 11.3.4.1). I am not sure when they are going to go through comments, and as I am going to miss next interm IEEE meeting and next IEEE plenary meeting, I cannot be there to explain the situation if they go through comments there. Also if I have understood correctly this kind of change will most likely be Technical change which require 75% approval votes from voting members for the change to happen, so ... ---------------------------------------------------------------------- From: "Stephens, Adrian P" To: STDS-802-11@LISTSERV.IEEE.ORG Subject: [STDS-802-11] IEEE 802.11 Comment Collection for IEEE Std 802.11-2012 Starts Today Date: Fri, 20 Jul 2012 20:59:46 +0000 IEEE 802.11(TM) Letter Ballot 802.11-2012_call_for_comments To: IEEE 802.11 Voters, With this email, the 802.11 Working Group is officially beginning the comment collection period for IEEE Std-802.11-2012. Important notes: o There is a 54-day comment collection period. o Anybody interested may provide comments. Note that access to the standard is required to provide comments. A copy of the standard is on the members' area. Those who are not active can still comment provided they have access to the standard from another source. o Commenting is entirely optional. o You have to cast a vote to comment using the ePoll tool, but whether you vote yes or no is entirely irrelevant. Comments can only be submitted using the ePoll tool. The comment collection opens on: Fri Jul 20, 2012 at 23:59 Eastern Time USA and closes 54 days later on Wed Sep 12, 2012 at 23:59 Eastern Time USA. (Add reminder to calendar). (The attached file contains a reminder set for 5 days before the close of the ballot. You may find it helpful to import this into or open this with your calendar client in order to get an automated reminder.) Thank you for participating in Letter Ballot 802.11-2012_call_for_comments. Bruce Kraemer, IEEE 802.11 Working Group Chair E-mail: bkraemer@marvell.com Adrian Stephens, IEEE 802.11 Working Group Vice Chair / Balloting Coordinator E-mail: Adrian.P.Stephens@intel.com -- kivinen@iki.fi From kivinen@iki.fi Wed Aug 29 07:45:25 2012 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 971AB21F8525; Wed, 29 Aug 2012 07:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.716 X-Spam-Level: X-Spam-Status: No, score=-102.716 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8qQg7Y8MdvH; Wed, 29 Aug 2012 07:45:25 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9639F21F8528; Wed, 29 Aug 2012 07:45:24 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id q7TEjMo9018138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Aug 2012 17:45:22 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q7TEjLTK012338; Wed, 29 Aug 2012 17:45:21 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20542.11009.577257.29490@fireball.kivinen.iki.fi> Date: Wed, 29 Aug 2012 17:45:21 +0300 From: Tero Kivinen To: "Dan Harkins" In-Reply-To: <6c1ddd2baf1480f6e7abeab6ac618402.squirrel@www.trepanning.net> References: <20120809010519.15222.89232.idtracker@ietfa.amsl.com> <503CAA6F.30302@ieca.com> <9035196F-001D-4E15-B6D6-30B59BEBBB01@cs.tcd.ie> <73F8581B-716F-4466-8F6B-645206789C5E@checkpoint.com> <503CEC59.9080601@gmail.com> <6c1ddd2baf1480f6e7abeab6ac618402.squirrel@www.trepanning.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 12 min Cc: IPsecme WG , secdir Subject: Re: [secdir] [IPsec] I-D Action: draft-harkins-brainpool-ike-groups-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 14:45:25 -0000 Dan Harkins writes: > > I was with you until that last phrase. It most certainly is an > > IKEv1 code point discussion. > > If you insist that the registry say "not for IKEv1" then the > code points are not for IKEv1 and any discussion about code points > that are not for IKEv1 is not an IKEv1 code point discussion. That registry is for IKEv1. Meaning ANY changes to those registries are still IKEv1 issues. Regardless whether we say that those points are not for IKEv1 use. Are you saying that if I want to add 2000 new cipher suites to TLS registry (from the Specification Required space) and say that they are not for TLS use, I do not need to ask anything from the TLS working group? So I myself at least do consider this to be also IKE issue even when the groups are not for IKEv1 use, just because it changes IKEv1 registry. > Please rephrase your wants into specific comments on the draft that > I can then accept, counter, or reject. And please do not send them to > the IPsecME list because, as you said, this "is *not* an IPsecME WG > issue" (emphasis yours). Remove the completely stupid "5. Insecurity Considerations" containing your own biased opionions of the reality. Add proper note why these things are to be added at all. You say in the section 1 that "Other pprotocols, ...", but do not point out any other than IEEE802.11, is there some other protocols referencing this registry than the IEEE802.11? Also it would be better to say that in the IEEE 802.11 only the SAE uses this registry. Also how widely supported SAE is? I have not seen it in any of the user interfaces for wlan systems I have configured at? Also the point that these groups are not for IKE is bit misleading when the title says IKE, and abstract talks about adding groups to "registry established by Teh Internet Key Exchange (IKE)", but does not point out that it is not for that protocol at all... > > Whether or not you want to do those, I want the ADs to decide whether it > > is appropriate to do more work on IKEv1, such as adding these curves to > > the IKEv1 registries. If they think the work is appropriate, they can also > > say where it should be done. > > They already did; you were there. I was there too, but I think I missed it too. Can you tell me what did they decide? Is it approriate to do any more work on IKEv1? And if so where should it be done? -- kivinen@iki.fi From leifj@sunet.se Wed Aug 29 12:50:16 2012 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 DD35221F854D; Wed, 29 Aug 2012 12:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.028 X-Spam-Level: X-Spam-Status: No, score=-3.028 tagged_above=-999 required=5 tests=[AWL=-0.429, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogxiklWkOsGj; Wed, 29 Aug 2012 12:50:16 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [193.10.252.66]) by ietfa.amsl.com (Postfix) with ESMTP id B335B21F8545; Wed, 29 Aug 2012 12:50:15 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.5/8.14.3) with ESMTP id q7TJmpE8009466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Aug 2012 21:48:57 +0200 (CEST) Message-ID: <503E7223.2060005@sunet.se> Date: Wed, 29 Aug 2012 21:48:51 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: "iesg@ietf.org" , draft-ietf-ccamp-assoc-ext.all@tools.ietf.org, "secdir@ietf.org" X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] secdir review of draft-ietf-ccamp-assoc-ext-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 19:50:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 describes use of RSVP ASSOCIATION objects that extends their current use as defined by GMPLS. The subject matter is well beyond my area of expertise so take this review with a grain of salt. In the security considerations section the authors basically say that using ASSOCIATION objects for (say) VOIP call reservations doesn't introduce any new security issues beyond those that already exist for the GMPLS use of ASSOCIATION objects. I suspect that may be simplifying the issue but I can't find any obvious counter-examples. Regards Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlA+ch8ACgkQ8Jx8FtbMZndD9QCgijOhEHUlpvgcnjbadtiLvUWO IZMAoKLD+m6VVMnvr133ICSZkfLTYryG =xTw1 -----END PGP SIGNATURE----- From d3e3e3@gmail.com Wed Aug 29 14:08:30 2012 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 BC2D611E80F1 for ; Wed, 29 Aug 2012 14:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.516 X-Spam-Level: X-Spam-Status: No, score=-104.516 tagged_above=-999 required=5 tests=[AWL=1.083, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXS9+hWYO4Rq for ; Wed, 29 Aug 2012 14:08:30 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 01BD411E80EA for ; Wed, 29 Aug 2012 14:08:29 -0700 (PDT) Received: by iabz21 with SMTP id z21so2181953iab.31 for ; Wed, 29 Aug 2012 14:08:28 -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:content-type; bh=iz18HP6EHDGGhhF8fTJjO9dgYZYhCTdJFprP7DvC9tU=; b=jHgATmdFv3fu8fczDiU0xE0wSmRwPGcc2u48BirrOu9Wdz46QjeDboYv/TYSTiE/ZN cum0trLoGh+F7KCLLBp5pzSzhHOHTTUKfE66Wr3TSyzALjrX2e7b93PaCVNYqFlzqSod RjskS3KrOFuHu4OUvH6tuFxe3uz366UYtQZZMcabaiYwVSGhbXB5A5riU6QcBoZcJ/so j/vfMLTQsC16M6RFseY4oinGaNAH+reqROHIJ1cren/aH0Jcex3M0hEde2/aobOJgHlu RS6rWBfKL6mKYynZpQURlxXtaURUSzEUi4MBr/m6Ew8uc8qCuxnfwqpAFbYhav5Y3jjP XEUA== Received: by 10.50.180.169 with SMTP id dp9mr3273487igc.8.1346274508642; Wed, 29 Aug 2012 14:08:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.15.6 with HTTP; Wed, 29 Aug 2012 14:08:07 -0700 (PDT) In-Reply-To: <20542.10005.144001.210338@fireball.kivinen.iki.fi> References: <20120809010519.15222.89232.idtracker@ietfa.amsl.com> <503CAA6F.30302@ieca.com> <9035196F-001D-4E15-B6D6-30B59BEBBB01@cs.tcd.ie> <20542.10005.144001.210338@fireball.kivinen.iki.fi> From: Donald Eastlake Date: Wed, 29 Aug 2012 17:08:07 -0400 Message-ID: To: Tero Kivinen Content-Type: text/plain; charset=ISO-8859-1 Cc: "secdir@ietf.org" Subject: Re: [secdir] Fwd: I-D Action: draft-harkins-brainpool-ike-groups-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 21:08:30 -0000 802.11-2012 is pretty much as immutable as any RFC. I believe comments are being collected with a view towards the next big roll-up document which would incorporate amendments to 2012 adopted in the interim and any other changes that are thought to be good. I believe it is expected that this next 802.11 rollup will likely be published by the IEEE in 2015 (and if so would, of course, be 802.11-2015). Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Wed, Aug 29, 2012 at 10:28 AM, Tero Kivinen wrote: > Stephen Farrell writes: >> On 28 Aug 2012, at 12:24, Sean Turner wrote: >> > BTW - Dan's submitted a draft about the topic we had in Vancouver. >> > Comments are welcome. >> >> I've one: I didn't realize Dan wanted 14 code points. That seems a >> lot. > > BTW, I think it was bit misstated in secdir lunch that the 802.11-2012 > cannot be changed anymore. > > IEEE started 54-day Comment Collection perioid for IEEE > Std-802.11-2012 at 2012-07-20 and that will end 2012-09-12. I would > expect that if they are still collecting comments for the draft it can > also be still modified. Of course it might be that they are not > willing to change it anymore, but at least I already submitted > comments for requesting change (I proposed creating completely new > registry copied from IKEv1 for just this SAE use, i.e. change text on > page 1176 in subclause 11.3.4.1). > > I am not sure when they are going to go through comments, and as I am > going to miss next interm IEEE meeting and next IEEE plenary meeting, > I cannot be there to explain the situation if they go through comments > there. Also if I have understood correctly this kind of change will > most likely be Technical change which require 75% approval votes from > voting members for the change to happen, so ... > > ---------------------------------------------------------------------- > From: "Stephens, Adrian P" > To: STDS-802-11@LISTSERV.IEEE.ORG > Subject: [STDS-802-11] IEEE 802.11 Comment Collection for IEEE Std > 802.11-2012 Starts Today > Date: Fri, 20 Jul 2012 20:59:46 +0000 > > IEEE 802.11(TM) Letter Ballot 802.11-2012_call_for_comments > To: IEEE 802.11 Voters, > > With this email, the 802.11 Working Group is officially beginning the > comment collection period for IEEE Std-802.11-2012. > > Important notes: > > o There is a 54-day comment collection period. > > o Anybody interested may provide comments. Note that > access to the standard is required to provide comments. > A copy of the standard is on the members' area. Those > who are not active can still comment provided they have > access to the standard from another source. > > o Commenting is entirely optional. > > o You have to cast a vote to comment using the ePoll tool, > but whether you vote yes or no is entirely irrelevant. > Comments can only be submitted using the ePoll tool. > > The comment collection opens on: Fri Jul 20, 2012 at 23:59 Eastern > Time USA and closes 54 days later on Wed Sep 12, 2012 at 23:59 Eastern > Time USA. (Add reminder to calendar). > > (The attached file contains a reminder set for 5 days before the close > of the ballot. You may find it helpful to import this into or open > this with your calendar client in order to get an automated reminder.) > > Thank you for participating in Letter Ballot 802.11-2012_call_for_comments. > > Bruce Kraemer, IEEE 802.11 Working Group Chair > E-mail: bkraemer@marvell.com > > Adrian Stephens, IEEE 802.11 Working Group Vice Chair / Balloting > Coordinator > E-mail: Adrian.P.Stephens@intel.com > -- > kivinen@iki.fi > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From clonvick@cisco.com Wed Aug 29 18:29:20 2012 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 63BE111E810B; Wed, 29 Aug 2012 18:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sp8Cax-XdBAl; Wed, 29 Aug 2012 18:29:19 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id B10C411E8103; Wed, 29 Aug 2012 18:29:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=clonvick@cisco.com; l=589; q=dns/txt; s=iport; t=1346290159; x=1347499759; h=date:from:to:subject:message-id:mime-version; bh=h161lTjhmSTwhUaE2bPwl6gC8NxuA6tVtpqehReqPog=; b=bh7os4TevHvhPySmDqOXzDTJ5alstSq/T+7egvupx/bBl2Q/9Paemgn3 VMEp7m5pMq7VU2q44T9bt9bJdIvrKcXifCGzNBa3DODeO4B4wlBTOftks rgt2tN5PGPgTmNdBRIfDK198/8LLnD6VYDMKNqrQBuiktTaai7yrKO9dv U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEADnBPlCrRDoG/2dsb2JhbABFuneBB4I5ASUCgX40h2qcBqAvkWEDiE+bNYFngwM X-IronPort-AV: E=Sophos;i="4.80,336,1344211200"; d="scan'208";a="54074807" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 30 Aug 2012 01:29:19 +0000 Received: from sjc-xdm-114 (sjc-xdm-114.cisco.com [171.71.188.119]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q7U1TJ2K025611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Aug 2012 01:29:19 GMT Date: Wed, 29 Aug 2012 18:29:19 -0700 (PDT) From: Chris Lonvick To: iesg@ietf.org, secdir@ietf.org, draft-ietf-v6ops-wireline-incremental-ipv6.all@tools.ietf.org Message-ID: User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [secdir] SECDIR review of draft-ietf-v6ops-wireline-incremental-ipv6 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 01:29:20 -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 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. Overall I found the document to be well written and very informative. The Security Considerations is complimentary and appropriate for the document. I found no nits to complain about so I recommend publication. Thanks and regards, Chris From kivinen@iki.fi Thu Aug 30 03:58:45 2012 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 EAEDD21F8607 for ; Thu, 30 Aug 2012 03:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MorcC9AdcWks for ; Thu, 30 Aug 2012 03:58:45 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id CC3A521F856D for ; Thu, 30 Aug 2012 03:58:44 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id q7UAwe2t001624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 30 Aug 2012 13:58:40 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q7UAwcJJ020248; Thu, 30 Aug 2012 13:58:38 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20543.18269.916014.989372@fireball.kivinen.iki.fi> Date: Thu, 30 Aug 2012 13:58:37 +0300 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 29 min X-Total-Time: 19 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 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, 30 Aug 2012 10:58:46 -0000 So this is my first assignment email. I hope I can do as good job as Sam has been doing for his multiyear work as secdir secretary, and I want to thank him for all work he has done so far. The review tool now has new feature where secretary can mark the document "Ready", "Ready with nits", "Ready with issues", "Almost ready", "Not ready" etc so it would be nice if you could put that kind of summary in your email. There seems to be quite a lot of reviews waiting for to be done for todays telechat (all of them were there already on last week). ---------------------------------------------------------------------- Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Kathleen Moriarty is next in the rotation. For telechat 2012-08-30 Reviewer LC end Draft Rob Austein T 2012-06-26 draft-ietf-bmwg-2544-as-05 Dave Cridland T 2012-08-23 draft-ietf-armd-problem-statement-03 Warren Kumari T 2012-07-11 draft-ietf-oauth-v2-threatmodel-07 Alexey Melnikov T - draft-ietf-krb-wg-kdc-model-14 Tim Polk T 2012-07-23 draft-ietf-appsawg-http-forwarded-07 Ondrej Sury T 2012-08-13 draft-sparks-genarea-mailarch-06 Sam Weiler T - draft-ietf-nea-pt-tls-07 Klaas Wierenga TR2012-08-15 draft-ietf-ccamp-dpm-07 Nico Williams T 2012-08-14 draft-ietf-ippm-testplan-rfc2679-02 For telechat 2012-09-13 Julien Laganier T 2012-08-29 draft-ietf-sieve-imap-sieve-06 Alexey Melnikov T 2012-08-13 draft-ietf-storm-iscsi-cons-06 Vincent Roca TR2012-02-06 draft-ietf-simple-chat-16 Tina TSOU TR2012-08-02 draft-ietf-avtcore-monarch-18 Last calls and special requests: Dave Cridland 2012-06-28 draft-ietf-nfsv4-federated-fs-admin-11 Alan DeKok 2012-08-23 draft-ietf-mmusic-media-loopback-22 Phillip Hallam-Baker 2012-09-03 draft-kumaki-murai-l3vpn-rsvp-te-06 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-02 Tero Kivinen - draft-ietf-httpbis-p6-cache-20 Warren Kumari 2012-09-03 draft-ietf-mpls-entropy-label-05 Catherine Meadows - draft-ietf-isis-mi-06 Alexey Melnikov 2012-09-05 draft-ietf-pkix-rfc5280-clarifications-08 Eric Rescorla 2012-07-25 draft-ietf-websec-strict-transport-sec-12 Nico Williams - draft-ietf-httpbis-p5-range-20 Glen Zorn 2012-06-27 draft-hoffman-tao4677bis-16 Glen Zorn 2012-08-14 draft-ietf-mptcp-api-05 -- kivinen@iki.fi From john-ietf@jck.com Thu Aug 30 11:38:38 2012 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 66DE421F85A8; Thu, 30 Aug 2012 11:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNYFyRvPowQL; Thu, 30 Aug 2012 11:38:37 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0DA21F858E; Thu, 30 Aug 2012 11:38:37 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1T79dU-000NaI-9L; Thu, 30 Aug 2012 14:38:36 -0400 Date: Thu, 30 Aug 2012 14:38:31 -0400 From: John C Klensin To: Charlie Kaufman Message-ID: <6C09D4F6CF343B77DE54A404@JcK-HP8200.jck.com> In-Reply-To: <5d350cd00c1240f0a9ffeaf07f6bd469@BL2PR03MB592.namprd03.prod.outlook.com> References: <5d350cd00c1240f0a9ffeaf07f6bd469@BL2PR03MB592.namprd03.prod.outlook.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: draft-ietf-eai-mailinglistbis.all@tools.ietf.org, Joseph Yee , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-eai-mailinglistbis-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 18:38:38 -0000 Charlie, As WG Co-chair, let me respond to this on behalf of the WG (and just to be sure we don't have open loops). Your careful review is much appreciated, as is the "no changes recommended" conclusion. It is always good to have additional assurances that nothing important was overlooked. The issue of a multiple-recipient message that requires SMTPUTF8 capability being undeliverable to some recipients, and hence misleading to those who do receive it about who else got it, is endemic in any approach that attempts to permit non-ASCII local-parts of addresses while preserving rough compatibility with the existing email infrastructure. That is the case whether the list of recipients is determined by the message originator (e.g., in "To:" or "Cc:" fields) or as part of distribution list processing. Of course, such recipient lists are _never_ guaranteed to be accurate: addresses may become obsolete or undeliverable for all sorts of reasons and none of them are reported back to other recipients (or, in the case of mailing lists that follow the specs, to the message originator). In that sense, the "None beyond what mailing list agents do now" statement in this draft is precisely and narrowly correct. For the specific case of these extensions, many of the issues -- but not the specific one of misleading recipient lists-- are discussed at length in RFC 6530. In retrospect, the particular issue with recipient lists should probably have been called out in either the Security Considerations section or, more likely, Section 11 of that document, but it is a little bit late for that now. That said, if you (or others) think the Security Consideration section of this document would be improved by an explicit pointer to the discussion in RFC 6530, I can't imagine the WG finding that objectionable. Thanks again for the review. best, john --On Wednesday, August 22, 2012 20:45 +0000 Charlie Kaufman 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 Informational document describes "considerations" for the > design and operations of mailing list expanders not collocated > with the sender when non-ASCII email addresses are involved. > It is truly informational in that it does not prescribe how to > deal with the various problems that one might encounter. It > simply enumerates the problems, describes the alternatives, > and the range of behaviors observed in existing > implementations. It suggests a number of areas where future > standardization would be helpful. > > The document lists no security considerations. An issue > discussed in the document that could be considered a security > issue is that mail recipients that cannot accept non-ASCII > email addresses might or might not receive messages sent to > the list (depending on approaches the forwarder takes), and > generally the original sender is not notified. I don't > recommend any changes. > > --Charlie