From kivinen@iki.fi Thu Jan 2 05:45:39 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13E51AE1E2 for ; Thu, 2 Jan 2014 05:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.261 X-Spam-Level: X-Spam-Status: No, score=0.261 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74gP6tIJIGVN for ; Thu, 2 Jan 2014 05:45:37 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 005311AE141 for ; Thu, 2 Jan 2014 05:45:36 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s02DjRXY024809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 2 Jan 2014 15:45:27 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s02DjRko009501; Thu, 2 Jan 2014 15:45:27 +0200 (EET) 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: <21189.28023.284827.306035@fireball.kivinen.iki.fi> Date: Thu, 2 Jan 2014 15:45:27 +0200 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 3 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jan 2014 13:45:39 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Klaas Wierenga is next in the rotation. For telechat 2014-01-09 Reviewer LC end Draft Derek Atkins TR2013-10-01 draft-ietf-siprec-architecture-11 Alan DeKok TR2013-12-01 draft-moonesamy-ietf-conduct-3184bis-05 Jeffrey Hutzelman T 2013-12-09 draft-ietf-avtcore-leap-second-07 Vincent Roca T 2013-12-23 draft-ietf-savi-send-10 Yaron Sheffer TR2013-12-23 draft-ietf-trill-o-pw-04 Zach Shelby T 2013-12-23 draft-ietf-trill-rfc6327bis-02 Klaas Wierenga T 2013-11-27 draft-ietf-pwe3-dynamic-ms-pw-20 For telechat 2014-01-23 Tina TSOU T 2014-01-10 draft-moriarty-pkcs12v1-1-03 Last calls and special requests: Rob Austein 2013-11-27 draft-turner-application-cms-media-type-07 Dave Cridland E 2013-11-21 draft-dunbar-armd-arp-nd-scaling-practices-07 Steve Hanna E 2013-11-28 draft-ietf-pcp-nat64-prefix64-04 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-05 Julien Laganier E 2013-11-21 draft-ietf-websec-key-pinning-09 Julien Laganier 2013-12-11 draft-ietf-stox-core-09 Ben Laurie 2013-12-11 draft-ietf-stox-presence-06 Sandy Murphy 2013-12-17 draft-ietf-netmod-iana-timezones-03 Magnus Nystrom 2014-01-05 draft-ietf-ccamp-oam-configuration-fwk-11 Vincent Roca 2013-12-25 draft-ietf-6man-stable-privacy-addresses-16 Joe Salowey 2013-12-23 draft-ietf-soc-overload-control-14 Ondrej Sury 2013-12-27 draft-ietf-tls-applayerprotoneg-03 Carl Wallace 2014-01-06 draft-ietf-opsawg-lsn-deployment-04 David Waltermire 2014-01-16 draft-ietf-pwe3-mpls-tp-cv-adv-03 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-09 Glen Zorn 2013-08-30 draft-kaplan-insipid-session-id-03 Glen Zorn 2013-11-27 draft-turner-ct-keypackage-receipt-n-error-algs-04 -- kivinen@iki.fi From simon@josefsson.org Sat Jan 4 14:49:55 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06ADD1AE0BA for ; Sat, 4 Jan 2014 14:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.149 X-Spam-Level: * X-Spam-Status: No, score=1.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79PgyzOGZACi for ; Sat, 4 Jan 2014 14:49:53 -0800 (PST) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) by ietfa.amsl.com (Postfix) with ESMTP id 512551AE0B2 for ; Sat, 4 Jan 2014 14:49:53 -0800 (PST) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id s04MngLb012160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sat, 4 Jan 2014 23:49:43 +0100 Date: Sat, 4 Jan 2014 23:49:41 +0100 From: Simon Josefsson To: secdir@ietf.org Message-ID: <20140104234941.37653805@latte.josefsson.org> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se X-Virus-Status: Clean Subject: [secdir] Necrotizing Fasciitis X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2014 22:49:55 -0000 I'll be flat on my back for a while, please hold my reviews. http://blog.josefsson.org/2014/01/05/necrotizing-fasciitis/ /Simon From magnusn@gmail.com Sat Jan 4 17:31:51 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7AF71AE09D; Sat, 4 Jan 2014 17:31:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiHfKA6ge92p; Sat, 4 Jan 2014 17:31:50 -0800 (PST) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 037E21AD73E; Sat, 4 Jan 2014 17:31:49 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id hi5so1669258wib.14 for ; Sat, 04 Jan 2014 17:31:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=MaDJqZg8G/oUtSUU8W01AbC6qVCUxn1jEQCautH6DGE=; b=IiSeTsW6N5Gtg0LwKTu/Girzu0aM17ux4nedWXhQi5nnxOq9DJxau4wh7labKBPE8G FXJJl0j2hOJAgWkTHOQ/OeNpuXlxP97yClsIyMy0ejbrg1PFrzy7fjKmFxuMT7Wa/G1W GabEDvXKgO8EN5T8i0kLF/BJBxENXF1COcVJjzHiSdQeFXO7LCqUYho5F0aug3UrvpTK SNikNndUvL2+ksUq/SA5H73gsvQc2ZKi0M4RO5+TVXVSApVaW+v+NwVZoGGKId2MgzNA 8rsY9Wp7LnQu82kk1JuB6BlM9Xz5f5QGjitVeJAbfA+Y0rr2La0R3t+8WCOlPn5BkXzo E3aQ== MIME-Version: 1.0 X-Received: by 10.180.20.33 with SMTP id k1mr7110898wie.34.1388885501595; Sat, 04 Jan 2014 17:31:41 -0800 (PST) Received: by 10.180.36.78 with HTTP; Sat, 4 Jan 2014 17:31:41 -0800 (PST) Date: Sat, 4 Jan 2014 17:31:41 -0800 Message-ID: From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: "secdir@ietf.org" , draft-ietf-ccamp-oam-configuration-fwk@tools.ietf.org Content-Type: multipart/alternative; boundary=bcaec53d5ee1f4d53104ef2f1ae6 Cc: "iesg@ietf.org" Subject: [secdir] Security directorate review of draft-ietf-ccamp-oam-configuration-fwk X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jan 2014 01:31:52 -0000 --bcaec53d5ee1f4d53104ef2f1ae6 Content-Type: text/plain; charset=ISO-8859-1 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 extensions to RSVP-TE in support of the establishment of Operation, Administration and Management entities in the context of GMPLS . The document seems well written. I would suggest removing the last sentence of the Security Considerations section ("Cryptography can be used...") since it does not really offer any hint as to how to use cryptography. Instead, the previous sentence could be replaced with something like: "For a more comprehensive discussion of GMPLS security, and attack mitigation techniques, please see the Security Framework for MPLS and GMPLS Networks [ RFC5920 ]." -- Magnus --bcaec53d5ee1f4d53104ef2f1ae6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=A0I have reviewed this documen= t as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security=20 area directors. Document editors and WG chairs should treat these=20 comments just like any other last call comments.

This document descr= ibes extensions to RSVP-TE in support of the establishment of Operation, Ad= ministration and Management entities in the context of GMPLS .

The document seems well written. I would suggest removing the last sentence= of the Security Considerations section ("Cryptography can be used...&= quot;) since it does not really offer any hint as to how to use cryptograph= y. Instead, the previous sentence could be replaced with something like: &q= uot;For a more comprehensive discussion of GMPLS security, and attack mitig= ation techniques, please see the Security Framework for MPLS and GMPLS Networks [RFC5920]."
=A0
-- Magnus
--bcaec53d5ee1f4d53104ef2f1ae6-- From kwiereng@cisco.com Mon Jan 6 01:51:40 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2871AD69E; Mon, 6 Jan 2014 01:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.039 X-Spam-Level: X-Spam-Status: No, score=-15.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPCSBWXDNC7k; Mon, 6 Jan 2014 01:51:39 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 97FC61AD603; Mon, 6 Jan 2014 01:51:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1521; q=dns/txt; s=iport; t=1389001890; x=1390211490; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=3KW4jb3ULUmLnmQgR/px/SKCDIFr4LI9g0y4r922m8I=; b=RGUDmJ4OJsKfqxEObKP4CGaddIf9K8zv7/pR8nXspKypEAjp9t1x9usB LgLKtMW/1TuyNgbls/Lw6tTewjDntg+Guko3f4bXKkPg9tcEf20c5m70L hpzKdn0wTJGHBjrWsZFts3q91jGb6QIqDggBFkoDS+tRKtJfqDEFsBQmg 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANh7ylKtJXHA/2dsb2JhbABYgwuBDbpWFnSCLDpRAT5CJwQBiBbDYxeSOoETBJgXkhWDLYIq X-IronPort-AV: E=Sophos;i="4.95,611,1384300800"; d="scan'208";a="295490476" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 06 Jan 2014 09:51:30 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s069pUiF013620 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Jan 2014 09:51:30 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.104]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Mon, 6 Jan 2014 03:51:30 -0600 From: "Klaas Wierenga (kwiereng)" To: "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-pwe3-dynamic-ms-pw.all@tools.ietf.org" Thread-Topic: Security Directorate review of draft-ietf-pwe3-dynamic-ms-pw-20 Thread-Index: AQHPCsTfytZKjSSLZEyTvepq9ynOww== Date: Mon, 6 Jan 2014 09:51:29 +0000 Message-ID: <5784D17B-CADE-4298-953C-37423DF6A66F@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.97.246] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] Security Directorate review of draft-ietf-pwe3-dynamic-ms-pw-20 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 09:51:41 -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=20 IESG. These comments were written primarily for the benefit of the securit= y area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. The draft describes extensions to the pseudowire control protocol to dynami= cally place the segments of the multi-segment pseudowire among a set of Pro= vider Edge (PE) routers. The draft is relatively straightforward and clear, but from a security PoV = I did take issue with the statement in the security considerations that goe= s: "This document specifies only extensions to the protocols already defined i= n [RFC4447], and [RFC6073]. The extensions defined in this document do not = affect the security considerations for those protocols." When you essentially propose a mechanism to insert dynamically men in the m= iddle you can imo not just state that nothing changes. In the meanwhile I h= ave talked to some people that are much more cognisant about pseudowires th= an I am, and I have let myself be convinced that this indeed not introducin= g new attack vectors (as compared to static PW and normal MPLS networks), a= nd that existing threats can be mitigated by doing end to end connection ve= rification, but I believe that others, like me would be helped by a short d= iscussion pertaining to this. Hope this helps, Klaas= From matthew.bocci@alcatel-lucent.com Mon Jan 6 08:01:46 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C330C1AE06C; Mon, 6 Jan 2014 08:01:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AP_42JdROzak; Mon, 6 Jan 2014 08:01:44 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id F03791AE06D; Mon, 6 Jan 2014 08:01:43 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s06G1XuI009345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 Jan 2014 10:01:34 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s06G1XRS026177 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Jan 2014 17:01:33 +0100 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.146]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Mon, 6 Jan 2014 17:01:33 +0100 From: "Bocci, Matthew (Matthew)" To: "Klaas Wierenga (kwiereng)" , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-pwe3-dynamic-ms-pw.all@tools.ietf.org" Thread-Topic: Security Directorate review of draft-ietf-pwe3-dynamic-ms-pw-20 Thread-Index: AQHPCsTfytZKjSSLZEyTvepq9ynOw5p3ytOA Date: Mon, 6 Jan 2014 16:01:32 +0000 Message-ID: References: <5784D17B-CADE-4298-953C-37423DF6A66F@cisco.com> In-Reply-To: <5784D17B-CADE-4298-953C-37423DF6A66F@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 06 Jan 2014 09:12:35 -0800 Subject: Re: [secdir] Security Directorate review of draft-ietf-pwe3-dynamic-ms-pw-20 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 16:01:47 -0000 Klaas Thank you very much for your review. I will add a short discussion to the security considerations section, as you propose. Regards Matthew On 06/01/2014 09:51, "Klaas Wierenga (kwiereng)" wrote: >Hi, > >I have reviewed this document as part of the security directorate's >ongoing effort to review all IETF documents being processed by the >IESG. These comments were written primarily for the benefit of the >security area directors. Document editors and WG chairs should treat >these comments just like any other last call comments. > >The draft describes extensions to the pseudowire control protocol to >dynamically place the segments of the multi-segment pseudowire among a >set of Provider Edge (PE) routers. > >The draft is relatively straightforward and clear, but from a security >PoV I did take issue with the statement in the security considerations >that goes: > >"This document specifies only extensions to the protocols already defined >in [RFC4447], and [RFC6073]. The extensions defined in this document do >not affect the security considerations for those protocols." > >When you essentially propose a mechanism to insert dynamically men in the >middle you can imo not just state that nothing changes. In the meanwhile >I have talked to some people that are much more cognisant about >pseudowires than I am, and I have let myself be convinced that this >indeed not introducing new attack vectors (as compared to static PW and >normal MPLS networks), and that existing threats can be mitigated by >doing end to end connection verification, but I believe that others, like >me would be helped by a short discussion pertaining to this. > >Hope this helps, > >Klaas From vincent.roca@inria.fr Mon Jan 6 23:59:23 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 681101AE44F; Mon, 6 Jan 2014 23:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.106 X-Spam-Level: X-Spam-Status: No, score=-6.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrxSYm6J7cvE; Mon, 6 Jan 2014 23:59:21 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by ietfa.amsl.com (Postfix) with ESMTP id 65A0B1ADFD5; Mon, 6 Jan 2014 23:59:20 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,617,1384297200"; d="scan'208,217";a="43793163" Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO [192.168.1.120]) ([82.236.155.50]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 07 Jan 2014 08:59:10 +0100 From: Vincent Roca Content-Type: multipart/alternative; boundary=Apple-Mail-31-604973775 Date: Tue, 7 Jan 2014 08:59:10 +0100 Message-Id: <206CF360-2CE2-4472-9252-707E0CB0888A@inria.fr> To: IESG , draft-ietf-savi-send@tools.ietf.org, secdir@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [secdir] Secdir review of draft-ietf-savi-send-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 07:59:23 -0000 --Apple-Mail-31-604973775 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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. IMHO, the document is Almost ready. This i-d contains a detailed Security Consideration sections which is = great. However I have a few questions and comments. 1/ Section 5 says: "The interaction in a mixed scenario comprising SEND and non-SEND devices should be addressed in other document." What happens if an attacker behaves as a non-SEND host? Is it sufficient to escape SEND SAVI and launch an attack? This is not said. 2/ Section 5.2 says: "The recommended minimum is the memory needed to store 4 bindings associated to the port." If there are several hosts behind this port (e.g., several hosts behind = a hub attached to this switch, or several virtual machines), this value of 4 = may not be sufficient. I agree that having per-port buffers is fine, but = specifying a value is risky. 3/ Section 5.2 is a bit confusing and I'm wondering if it could not be = simplified. Basically, it says: - in case of memory shortage, it is RECOMMENDED to "delete the entries = with a higher Creation time". BTW, what do you mean by "higher creation time"? The oldest entries? - it is RECOMMENDED to reserve some memory for each port in order to = isolate the effects to the attacker's port; - one MUST limit the maximum amount of memory used to store data packets in order to keep memory for other tasks; - one SHOULD rate limit packets which may trigger SEND SAVI events, = since it requires costly crypto operations. BTW, why do you say "which may trigger" instead of "which trigger"? Third paragraph is strange. I read: "As the SEND SAVI device may store data packets while the address is being verified..." If the incoming packet rate is higher than the packet verification rate, = sure there will be problems. Is it what the authors mean? I don't see any = good solution except rate limiting the incoming packet flow. Later: "The effects of such attacks may be limited to the lack of capacity to store new data packets." Does it mean that setting an upper limit to the amount of memory = devoted to store data packets is a way to mitigate the attack (last sentence), or does it mean that the attack will lead packets to be dropped = (following sentence)? And when it is said that: "A SEND SAVI device MUST limit the amount of memory used to store data packets, allowing the other functions to have available memory even in the case of an attacks..." What do you mean by "other functions"? SEND SAVI functions? Others? 5/ Section 5.4 says that "a SEND SAVI MUST NOT log binding anchor = information except [if there's a good reason for that]". And later that "information = about the majority of hosts that never spoof SHOULD NOT be logged." The intention is fine, but if I understand correctly, SAVI requires to = identify a host's legitimate IP source addresses (RFC 7039). It means that this = information will be logged any away as SAVI needs it (if I understand correctly). Or may be by "logging" you mean "long term logging" but in that case = this is not clear. Or is there something else I've missed? Typos: ** s/reply/replay in: "There are two different cases to analyze when considering SEND SAVI reply attacks:" ** s/In this two cases/In these two cases/ ** s/messages which does not result in changes/messages which do not = result in changes/ ** s/in the case of an attacks such those described above/in the case of = an attack like the one described above/ --Apple-Mail-31-604973775 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
IMHO, the document is Almost = ready.


This i-d = contains a detailed Security Consideration sections which is = great.
However I have a few questions and = comments.

1/ Section 5 says:
  =  "The interaction in a mixed scenario comprising SEND and = non-SEND
   devices should be addressed in other = document."
What happens if an attacker behaves as a non-SEND = host? Is it sufficient
to escape SEND SAVI and launch an = attack? This is not said.


2/ = Section 5.2 says:
   "The recommended = minimum
   is the memory needed to store 4 bindings = associated to the port."
If there are several hosts behind = this port (e.g., several hosts behind a hub
attached to this = switch, or several virtual machines), this value of 4 may = not
be sufficient. I agree that having per-port buffers is = fine, but specifying a
value is = risky.


3/ Section 5.2 is a bit = confusing and I'm wondering if it could not be = simplified.
Basically, it says:
- in case of memory = shortage, it is RECOMMENDED to "delete the entries with
  = a higher Creation time".
  BTW, what do you mean by = "higher creation time"? The oldest entries?
- it is = RECOMMENDED to reserve some memory for each port in order to = isolate
  the effects to the attacker's port;
- = one MUST limit the maximum amount of memory used to store data = packets
  in order to keep memory for other = tasks;
- one SHOULD rate limit packets which may trigger SEND = SAVI events, since
  it requires costly crypto = operations.
  BTW, why do you say "which may trigger" = instead of "which trigger"?

Third paragraph is = strange. I read:
   "As the SEND SAVI device may = store data packets while the address is
   being = verified..."
If the incoming packet rate is higher than the = packet verification rate, sure
there will be problems. Is it = what the authors mean? I don't see any good
solution except = rate limiting the incoming packet = flow.

Later:
   "The = effects of such attacks may be limited to
   the = lack of capacity to store new data packets."
Does it = mean that setting an upper limit to the amount of memory = devoted
to store data packets is a way to mitigate the attack = (last sentence),
or does it mean that the attack will lead = packets to be dropped = (following
sentence)?

And when it is = said that:
   "A SEND SAVI device MUST limit the = amount of
   memory used to store data packets, = allowing the other functions to
   have available = memory even in the case of an attacks..."
What do you mean by = "other functions"? SEND SAVI functions? = Others?


5/ Section 5.4 says that = "a SEND SAVI MUST NOT log binding anchor information
except = [if there's a good reason for that]". And later that "information = about
the majority of hosts that never spoof SHOULD NOT be = logged."

The intention is fine, but if I = understand correctly, SAVI requires to identify
a host's = legitimate IP source addresses (RFC 7039). It means that this = information
will be logged any away as SAVI needs it (if I = understand correctly).
Or may be by "logging" you mean "long = term logging" but in that case this is
not clear. Or is there = something else I've = missed?


Typos:

** s/reply/replay  in:
  =  "There are two different cases to analyze when considering SEND = SAVI
   reply attacks:"

** = s/In this two cases/In these two cases/

** = s/messages which does not result in changes/messages which do not result = in changes/

** s/in the case of an attacks such = those described above/in the case of an attack like the one described = above/

= --Apple-Mail-31-604973775-- From alberto@it.uc3m.es Thu Jan 9 02:24:21 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0AD1AE1AE; Thu, 9 Jan 2014 02:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.772 X-Spam-Level: X-Spam-Status: No, score=-3.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrrcWIPalz0v; Thu, 9 Jan 2014 02:24:15 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 71BA71AE1F7; Thu, 9 Jan 2014 02:24:10 -0800 (PST) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id AD9A011BF590; Thu, 9 Jan 2014 11:24:00 +0100 (CET) X-uc3m-safe: yes X-uc3m-safe: yes Received: from BOMBO (unknown [163.117.139.50]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: alberto@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id 8579111BF902; Thu, 9 Jan 2014 11:24:00 +0100 (CET) From: =?iso-8859-1?Q?Alberto_Garc=EDa?= To: "'Vincent Roca'" , "'IESG'" , , References: <206CF360-2CE2-4472-9252-707E0CB0888A@inria.fr> In-Reply-To: <206CF360-2CE2-4472-9252-707E0CB0888A@inria.fr> Date: Thu, 9 Jan 2014 11:24:00 +0100 Message-ID: <01ae01cf0d24$e9d492c0$bd7db840$@it.uc3m.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01AF_01CF0D2D.4BA0C2F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHaNKwdfSYJOwgcxKKswh9HGthMUZpkXnQg Content-Language: es X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20418.005 X-TM-AS-Result: No--44.993-7.0-31-1 X-imss-scan-details: No--44.993-7.0-31-1 X-Mailman-Approved-At: Thu, 09 Jan 2014 02:44:05 -0800 Subject: Re: [secdir] Secdir review of draft-ietf-savi-send-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 10:24:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01AF_01CF0D2D.4BA0C2F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Vincent, Thank you for your comments. Responses are inline, colored in blue. =20 =20 De: Vincent Roca [mailto:vincent.roca@inria.fr]=20 Enviado el: martes, 07 de enero de 2014 8:59 Para: IESG; draft-ietf-savi-send@tools.ietf.org; secdir@ietf.org CC: Vincent Roca Asunto: Secdir review of draft-ietf-savi-send-10 =20 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. =20 IMHO, the document is Almost ready. =20 This i-d contains a detailed Security Consideration sections which is = great. However I have a few questions and comments. =20 1/ Section 5 says: "The interaction in a mixed scenario comprising SEND and non-SEND devices should be addressed in other document." What happens if an attacker behaves as a non-SEND host? Is it sufficient to escape SEND SAVI and launch an attack? This is not said. =20 Yes, this is not said and it should. I have modified the first paragraph = to say: =20 SEND SAVI operates only with validated SEND messages. Note that IPv6 packets generated by non-SEND nodes will be discarded by the first SEND SAVI device receiving it. Therefore, attackers cannot obtain any benefit by not using SEND. In order to perform address validation in a mixed scenario comprising SEND and non-SEND devices, a different solution is required, which should be addressed in other document. =20 2/ Section 5.2 says: "The recommended minimum is the memory needed to store 4 bindings associated to the port." If there are several hosts behind this port (e.g., several hosts behind = a hub attached to this switch, or several virtual machines), this value of 4 = may not be sufficient. I agree that having per-port buffers is fine, but = specifying a value is risky. =20 This text is also included in RFC 6620 (FCFS SAVI) Note that the value specified is a *minimum*, which means that=20 - Implementors of SEND SAVI devices could raise this number, of course, probably depending on the memory they have. - This is the minimum in case malicious nodes are connected to = other ports trying to exhaust memory; i.e., there will always be at least 4 bindings, which should be a minimum number of addresses for one basic = host (link local address + global unicast address=85). Even if this is the = minimum being set, when an attack is not occurring more than 4 bindings could be available to certain ports, assuming that the device can store more = bindings than 4*number_of_ports.=20 =20 In order to stress the first idea, I have rephrased the paragraph as follows: =20 The recommended minimum is the memory needed to store four bindings associated to the port, although it should be raised if the ratio between the maximum number of bindings allowed in the device and the number of ports is high. =20 =20 By the way, you raise an interesting issue that has not been considered = in the previous versions of the document: the virtual machine case. In = order to address this, at least cursorily, I have included the following text in section 2.4 =91Special Cases=92: =20 Virtual switches: A hypervisor or a host Operating System may perform bridging functions between virtual hosts running on the same machine. The hypervisor or host OS may in turn connect to a SEND SAVI system. This scenario is depicted in the next figure, with two virtual machines VM1 and VM2 connected through a virtual switch VS1 to SEND SAVI device SEND-SAVI1. The attachment points of VS1 to VM1 and VM2 are configured as Validating. =20 =20 Host1 +----------------+ | +---+ +---+ | | |VM1| |VM2| | | +---+ +---+ | | | | | | +-1-----2--+ | | | VS1 | | | +--3-------+ | | | | +----|-----------+ | | +--1-----2--+ | SEND- | | SAVI1 | +--3---4----+ | | =20 =20 =20 In order to provide proper security against replay attacks, it is recommended to perform SEND SAVI filtering as close to untrusted hosts as possible (see Section 3.4 and Section 5.1). In this scenario, this objective can be achieved by enabling SEND SAVI validation in VS1. Ideally, VS1 could be integrated into the SEND SAVI protection perimeter, if the hypervisor or host OS at Host1 can be trusted (even though VM1 and VM2 could not be trusted). To do so, both the attachment to SEND-SAVI1 at VS1, and port 1 at SEND-SAVI1, are configured as Trusted. =20 If the administrator of the network does not trust on VS1, port 1 of SEND-SAVI1 is configured as Validating, so that every address being used at Host1 is validated at SEND-SAVI1 by SEND SAVI. The attachment point to the physical network at VS1 should be configured as Trusted, if the host administrator knows that it is connected to a SEND SAVI device; in this case, VS1 relies on the infrastructure comprised by the physical SEND SAVI devices, but not the other way. Packets egressing from VM1 are validated twice, first at VS1, and then at SEND-SAVI1; packets going in the reverse direction (from an external host to VM1) are validated once, when they first reach a SEND SAVI device. If the administrator of VS1 does not trust on the physical switch to which it attaches, it can configure the attachment to SEND-SAVI1 as Validating. In the figure above, this means that a packet going from another host to VM1 would be validated twice, once when entering the SEND SAVI perimeter formed by the physical devices, and the other when entering at VS1. =20 =20 =20 =20 3/ Section 5.2 is a bit confusing and I'm wondering if it could not be simplified. =20 Just to provide some background about this section: it is almost the = same text as section 4.1 of RFC 6620, since the DoS problems are mostly the = same (except for the last paragraph of the section, which insists in the = extra cost of cryptographic operations due to the use of SEND.=20 This being said, I do not pretend that RFC6620 text could not be = improved. =20 Basically, it says: - in case of memory shortage, it is RECOMMENDED to "delete the entries = with a higher Creation time". BTW, what do you mean by "higher creation time"? The oldest entries = el? =20 =20 No, the newer ones, as the next sentence clarifies: =91This implies that = older entries are preserved and newer entries overwrite each other.=20 =20 - it is RECOMMENDED to reserve some memory for each port in order to = isolate the effects to the attacker's port; - one MUST limit the maximum amount of memory used to store data packets in order to keep memory for other tasks; - one SHOULD rate limit packets which may trigger SEND SAVI events, = since it requires costly crypto operations. BTW, why do you say "which may trigger" instead of "which trigger"? I remove =91may=92. Your summary is correct. =20 =20 Third paragraph is strange.=20 =20 According to your comments, I have changed the text to (I explain later = the changes): The SEND SAVI device may store data packets while the address is being verified, for example, when a DAD_NSOL was lost before arriving to the SEND SAVI device to which the host attaches, and the host sends data packets, these data packets may be stored until the SEND SAVI device verifies the binding by means of a NUD packet exchange. In this case, the memory for data packet storage may also be a target of DoS attacks. A SEND SAVI device MUST limit the amount of memory used to store data packets, allowing the other functions (such as being able to store new bindings) to have available memory even in the case of an attacks such those described above. =20 =20 =20 =20 I read: "As the SEND SAVI device may store data packets while the address is being verified..." If the incoming packet rate is higher than the packet verification rate, sure there will be problems. Is it what the authors mean? I don't see any = good solution except rate limiting the incoming packet flow. =20 I think it was not clear enough the case to which we were referring. = That=92s why I changed the first sentence. What I want to note is that this is a particular case, but not =91normal operation=92 of the SAVI device, because in most cases (well-behaved = hosts), DAD_NSOL is going to be issued first, and the host will not send packets until the address is valid (and so the state at the SEND SAVI devices).=20 However, we do not want malicious nodes to exploit the fact that memory (especially for other more relevant uses, such as storing bindings) = could be exhausted in this way. =20 Later: "The effects of such attacks may be limited to the lack of capacity to store new data packets." Does it mean that setting an upper limit to the amount of = memory devoted to store data packets is a way to mitigate the attack (last sentence), or does it mean that the attack will lead packets to be dropped = (following sentence)? =20 I agree that the two sentences starting by the one you copy here were = hard to understand. As you see in the new version of the text (above), I have removed them. What I think is the most relevant problem is that using = memory for this could drain resources for other functions, and this is stated = in the last sentence. =20 And when it is said that: "A SEND SAVI device MUST limit the amount of memory used to store data packets, allowing the other functions to have available memory even in the case of an attacks..." What do you mean by "other functions"? SEND SAVI functions? Others? I have clarified this in the text =20 5/ Section 5.4 says that "a SEND SAVI MUST NOT log binding anchor information except [if there's a good reason for that]". And later that "information about the majority of hosts that never spoof SHOULD NOT be logged." =20 The intention is fine, but if I understand correctly, SAVI requires to identify a host's legitimate IP source addresses (RFC 7039). It means that this information will be logged any away as SAVI needs it (if I understand correctly). Or may be by "logging" you mean "long term logging" but in that case = this is not clear. Or is there something else I've missed? =20 You are right. I have changed this to =20 A SEND SAVI device MUST delete binding anchor information as soon as possible (i.e., as soon as the state for a given address is back to NO_BIND), except where there is an identified reason why that information is likely to be involved in detection, prevention or tracing of actual source address spoofing. Information about the majority of hosts that never spoof SHOULD NOT be logged. =20 =20 Typos: =20 ** s/reply/replay in: "There are two different cases to analyze when considering SEND SAVI reply attacks:" =20 ** s/In this two cases/In these two cases/ =20 ** s/messages which does not result in changes/messages which do not = result in changes/ =20 ** s/in the case of an attacks such those described above/in the case of = an attack like the one described above/ =20 Corrected! Thanks again for your comments Alberto ------=_NextPart_000_01AF_01CF0D2D.4BA0C2F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Vincent,

Thank you for your comments. = Responses are inline, colored in blue.

 

 

De: = Vincent Roca [mailto:vincent.roca@inria.fr]
Enviado el: = martes, 07 de enero de 2014 8:59
Para: IESG; = draft-ietf-savi-send@tools.ietf.org; secdir@ietf.org
CC: = Vincent Roca
Asunto: Secdir review of = draft-ietf-savi-send-10

 

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.

&nbs= p;

IMHO, = the document is Almost ready.



 

This i-d contains a detailed = Security Consideration sections which is = great.

However I have a few questions and = comments.

 

1/ Section 5 = says:

   "The interaction in a mixed scenario = comprising SEND and non-SEND

   devices should be = addressed in other document."

What happens if an attacker behaves = as a non-SEND host? Is it sufficient

to escape SEND SAVI and launch an = attack? This is not said.

 

Yes, this is not said and it should. I have modified the first = paragraph to say:

 

=A0=A0 SEND SAVI operates only with validated SEND = messages.=A0 Note that IPv6

=A0=A0 packets generated by non-SEND nodes will be = discarded by the first

=A0=A0 SEND SAVI device receiving it.=A0 Therefore, = attackers cannot obtain

=A0=A0 any benefit by not using SEND.=A0 In order to = perform address

=A0=A0 validation in a mixed scenario comprising = SEND and non-SEND devices,

=A0=A0 a different solution is required, which = should be addressed in other

=A0=A0=A0 document.

 

2/ Section 5.2 = says:

   "The recommended = minimum

   is the memory needed to store 4 bindings = associated to the port."

If there are several hosts behind = this port (e.g., several hosts behind a = hub

attached to this switch, or several virtual machines), this = value of 4 may not

be sufficient. I agree that having = per-port buffers is fine, but specifying = a

value is risky.

 

This text is = also included in RFC 6620 (FCFS SAVI)

Note that the = value specified is a *minimum*, which means that =

-        = Implementors = of SEND SAVI devices could raise this number, of course, probably = depending on the memory they have.

-        = This is the = minimum in case malicious nodes are connected to other ports trying to = exhaust memory; i.e., there will always be at least 4 bindings, which = should be a minimum number of addresses for one basic host (link local = address + global unicast address…). Even if this is the minimum = being set, when an attack is not occurring more than 4 bindings could be = available to certain ports, assuming that the device can store more = bindings than 4*number_of_ports.

 

In order to = stress the first idea, I have rephrased the paragraph as = follows:

 

=A0=A0 The =
recommended minimum
=A0=A0 is the memory needed to store four =
bindings associated to the port,
=A0=A0 although it should be raised =
if the ratio between the maximum =
number
=A0=A0 of bindings allowed in the device and the =
number of ports is high.

 

 

By the way, = you raise an interesting issue that has not been considered in the = previous versions of the document: the virtual machine case. In order to = address this, at least cursorily, I have included the following text in = section 2.4 ‘Special Cases’:

 

=A0=A0 Virtual switches: A hypervisor or a host =
Operating System may perform
=A0=A0 bridging functions between virtual hosts =
running on the same machine.
=A0=A0 The hypervisor or host OS may in turn =
connect to a SEND SAVI system.
=A0=A0 This scenario is depicted in the next =
figure, with two virtual
=A0=A0 machines VM1 and VM2 connected through a =
virtual switch VS1 to SEND
=A0=A0 SAVI device SEND-SAVI1.=A0 The attachment =
points of VS1 to VM1 and VM2
=A0=A0 are configured as =
Validating.
 
 
=A0=A0=A0=A0=A0=A0 =
Host1
=A0=A0=A0=A0=A0=A0 =
+----------------+
=A0=A0=A0=A0=A0=A0 | +---+=A0=A0 +---+=A0 =
|
=A0=A0=A0=A0=A0=A0 | |VM1|=A0=A0 =
|VM2|=A0 |
=A0=A0=A0=A0=A0=A0 | +---+=A0=A0 =
+---+=A0 |
=A0=A0=A0=A0=A0=A0 |=A0=A0 =
|=A0=A0=A0=A0 |=A0=A0=A0=A0=A0 |
=A0=A0=A0=A0=A0=A0 | +-1-----2--+=A0=A0 =
|
=A0=A0=A0=A0=A0=A0 | |=A0=A0 =
VS1=A0=A0=A0 |=A0=A0 |
=A0=A0=A0=A0=A0=A0 | +--3-------+=A0=A0 =
|
=A0=A0=A0=A0=A0=A0 |=A0=A0=A0 =
|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
=A0=A0=A0=A0=A0=A0 =
+----|-----------+
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
|
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
|
=A0=A0=A0=A0=A0=A0=A0=A0 =
+--1-----2--+
=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0 SEND-=A0=A0 =
|
=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0 =
SAVI1=A0=A0 |
=A0=A0=A0=A0=A0=A0=A0=A0 =
+--3---4----+
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 =
=A0|
 
 
 
=A0=A0 In order to provide proper security =
against replay attacks, it is
=A0=A0 recommended to perform SEND SAVI =
filtering as close to untrusted
=A0=A0 hosts as possible (see Section 3.4 and =
Section 5.1).=A0 In this
=A0=A0 scenario, this objective can be achieved =
by enabling SEND SAVI
=A0=A0 validation in VS1.=A0 Ideally, VS1 could =
be integrated into the SEND
=A0=A0 SAVI protection perimeter, if the =
hypervisor or host OS at Host1 can
=A0=A0 be trusted (even though VM1 and VM2 could =
not be trusted).=A0 To do so,
=A0=A0 both the attachment to SEND-SAVI1 at VS1, =
and port 1 at SEND-SAVI1,
=A0=A0 are configured as =
Trusted.
 
=A0=A0 If the administrator of the network does =
not trust on VS1, port 1 of
=A0=A0 SEND-SAVI1 is configured as Validating, =
so that every address being
=A0=A0 used at Host1 is validated at SEND-SAVI1 =
by SEND SAVI.=A0 The
=A0=A0 attachment point to the physical network =
at VS1 should be configured
=A0=A0 as Trusted, if the host administrator =
knows that it is connected to a
=A0=A0 SEND SAVI device; in this case, VS1 =
relies on the infrastructure
=A0=A0 comprised by the physical SEND SAVI =
devices, but not the other way.
=A0=A0 Packets egressing from VM1 are validated =
twice, first at VS1, and
=A0=A0 then at SEND-SAVI1; packets going in the =
reverse direction (from an
=A0=A0 external host to VM1) are validated once, =
when they first reach a
=A0=A0 SEND SAVI device.=A0 If the administrator =
of VS1 does not trust on the
=A0=A0 physical switch to which it attaches, it =
can configure the attachment
=A0=A0 to SEND-SAVI1 as Validating.=A0 In the =
figure above, this means that a
=A0=A0 packet going from another host to VM1 =
would be validated twice, once
=A0=A0 when entering the SEND SAVI perimeter =
formed by the physical devices,
=A0=A0 and the other when entering =
at VS1.

 

 

 

 

3/ Section 5.2 is a bit confusing and I'm wondering if it = could not be simplified.

 

Just to provide some background about this section: it is almost the = same text as section 4.1 of RFC 6620, since the DoS problems are mostly = the same (except for the last paragraph of the section, which insists in = the extra cost of cryptographic operations due to the use of SEND. =

This being said, I do not pretend that RFC6620 text could not be = improved.

 

Basically, it says:

- in case of memory shortage, it is = RECOMMENDED to "delete the entries = with

  a higher Creation = time".

  BTW, what do you mean by "higher creation = time"? The oldest entries = el?

 
 
No, the newer ones, as the next sentence clarifies: ‘This =
implies that older =
entries are preserved and newer entries overwrite each other. =

 

- it is RECOMMENDED to reserve some memory for each port in = order to isolate

  the effects to the = attacker's port;

- one MUST limit the maximum amount = of memory used to store data packets

  in order to keep memory for = other tasks;

- one SHOULD rate limit packets which may trigger SEND SAVI = events, since

  it requires costly crypto = operations.

  BTW, why do you say "which may trigger" = instead of "which trigger"?

I remove = ‘may’.

Your summary is = correct.

 

 

Third paragraph is strange.

 

According to your comments, I have changed the text to (I explain = later the changes):

=A0=A0 The SEND SAVI device may store data =
packets while the address is
=A0=A0 being verified, for example, =
when a DAD_NSOL was lost before =
arriving
=A0=A0 to the SEND SAVI device to which the host =
attaches, and the host
=A0=A0 sends data packets, these data packets =
may be stored until the SEND
=A0=A0 SAVI device verifies the =
binding by means of a NUD packet =
exchange.
=A0=A0 In this case, the memory for data packet =
storage may also be a target
=A0=A0 of DoS attacks.=A0 A SEND =
SAVI device MUST limit the amount of =
memory
=A0=A0 used to store data packets, allowing the =
other functions (such as
=A0=A0 being able to store new bindings) to have =
available memory even in
=A0=A0 the case of an attacks such those =
described above.
 

 

 

 

I = read:

   "As the SEND SAVI device may store data = packets while the address is

   being = verified..."

If the incoming packet rate is = higher than the packet verification rate, = sure

there will be problems. Is it what the authors mean? I = don't see any good

solution except rate limiting the = incoming packet flow.

 

I think it was not clear enough the case to which we were referring. = That’s why I changed the first sentence.

What I want to note is that this is a particular case, but not = ‘normal operation’ of the SAVI device, because in most cases = (well-behaved hosts), DAD_NSOL is going to be issued first, and the host = will not send packets until the address is valid (and so the state at = the SEND SAVI devices).

However, we do not want malicious nodes to exploit the fact that = memory (especially for other more relevant uses, such as storing = bindings) could be exhausted in this way.

 

Later:

   "The effects of = such attacks may be limited to

   the lack of capacity = to store new data packets."

=A0=A0=A0=A0=A0=A0=A0=A0=A0 Does it mean that setting an upper limit to the amount of = memory devoted

to store data packets is a way to = mitigate the attack (last sentence),

or does it mean that the attack = will lead packets to be dropped = (following

sentence)?

 

I agree that the two sentences starting by the one you copy here were = hard to understand. As you see in the new version of the text (above), I = have removed them. What I think is the most relevant problem is that = using memory for this could drain resources for other functions, and = this is stated in the last sentence.

 

And when it is said = that:

   "A SEND SAVI device MUST limit the amount = of

   memory used to store data packets, allowing = the other functions to

   have available memory = even in the case of an = attacks..."

What do you mean by "other = functions"? SEND SAVI functions? = Others?

I have clarified this in the = text

 

5/ Section 5.4 says that "a = SEND SAVI MUST NOT log binding anchor = information

except [if there's a good reason for that]". And later = that "information about

the majority of hosts that never = spoof SHOULD NOT be logged."

 

The intention is fine, but if I = understand correctly, SAVI requires to = identify

a host's legitimate IP source addresses (RFC 7039). It = means that this information

will be logged any away as SAVI = needs it (if I understand correctly).

Or may be by "logging" = you mean "long term logging" but in that case this = is

not clear. Or is there something else I've = missed?

 

You are right. I have changed this to

 

=A0=A0 A SEND SAVI device MUST delete binding =
anchor information as soon as
=A0=A0 possible (i.e., as soon as =
the state for a given address is back =
to
=A0=A0 NO_BIND), except where there is an =
identified reason why that
=A0=A0 information is likely to be =
involved in detection, prevention or
=A0=A0 tracing of actual source =
address spoofing.=A0 Information about =
the
=A0=A0 majority of hosts that never spoof SHOULD =
NOT be logged.

 

 

Typos:

 

** s/reply/replay =  in:

   "There are two different cases to analyze = when considering SEND SAVI

   reply = attacks:"

 

** s/In this two cases/In these two = cases/

 

** s/messages which does not result = in changes/messages which do not result in = changes/

 

** s/in the case of an attacks such = those described above/in the case of an attack like the one described = above/

 

Corrected!

Thanks again for your comments

Alberto

------=_NextPart_000_01AF_01CF0D2D.4BA0C2F0-- From kivinen@iki.fi Thu Jan 9 03:32:45 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C981AE10E for ; Thu, 9 Jan 2014 03:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.54 X-Spam-Level: X-Spam-Status: No, score=-0.54 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSNNfwX2pgDk for ; Thu, 9 Jan 2014 03:32:41 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id E45351ADEA6 for ; Thu, 9 Jan 2014 03:32:40 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s09BWSWd020875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 9 Jan 2014 13:32:28 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s09BWRdD020828; Thu, 9 Jan 2014 13:32:27 +0200 (EET) 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: <21198.35019.603857.732995@fireball.kivinen.iki.fi> Date: Thu, 9 Jan 2014 13:32:27 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jan 2014 11:32:45 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Dorothy Gellert is next in the rotation. For telechat 2014-01-09 Reviewer LC end Draft Derek Atkins TR2013-10-01 draft-ietf-siprec-architecture-11 Rob Austein T 2013-11-27 draft-turner-application-cms-media-type-07 Alan DeKok TR2013-12-01 draft-moonesamy-ietf-conduct-3184bis-06 Jeffrey Hutzelman T 2013-12-09 draft-ietf-avtcore-leap-second-07 Radia Perlman TR2013-11-27 draft-housley-ct-keypackage-receipt-n-error-07 Yaron Sheffer TR2013-12-23 draft-ietf-trill-o-pw-04 Zach Shelby T 2013-12-23 draft-ietf-trill-rfc6327bis-03 Glen Zorn T 2013-11-27 draft-turner-ct-keypackage-receipt-n-error-algs-04 For telechat 2014-01-23 Vincent Roca T 2013-12-25 draft-ietf-6man-stable-privacy-addresses-16 Tina TSOU T 2014-01-10 draft-moriarty-pkcs12v1-1-03 Carl Wallace T 2014-01-06 draft-ietf-opsawg-lsn-deployment-04 For telechat 2014-02-06 Klaas Wierenga T 2014-01-31 draft-crocker-id-adoption-05 Last calls and special requests: Derek Atkins 2014-01-16 draft-ietf-avtcore-clksrc-09 Rob Austein 2014-01-16 draft-ietf-mpls-tp-p2mp-framework-05 Dave Cridland E 2013-11-21 draft-dunbar-armd-arp-nd-scaling-practices-07 Alan DeKok 2014-01-17 draft-ietf-mpls-multipath-use-03 Donald Eastlake 2014-01-22 draft-ietf-netmod-system-mgmt-10 Shawn Emery 2014-01-22 draft-ietf-isis-rfc6326bis-01 Steve Hanna E 2013-11-28 draft-ietf-pcp-nat64-prefix64-04 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-05 Julien Laganier E 2013-11-21 draft-ietf-websec-key-pinning-09 Julien Laganier 2013-12-11 draft-ietf-stox-core-09 Ben Laurie 2013-12-11 draft-ietf-stox-presence-06 Sandy Murphy 2013-12-17 draft-ietf-netmod-iana-timezones-03 Joe Salowey 2013-12-23 draft-ietf-soc-overload-control-14 Ondrej Sury 2013-12-27 draft-ietf-tls-applayerprotoneg-03 David Waltermire 2014-01-16 draft-ietf-pwe3-mpls-tp-cv-adv-04 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-09 Tom Yu 2014-01-17 draft-ietf-abfab-arch-10 Dacheng Zhang 2014-01-22 draft-ietf-ancp-mc-extensions-14 Glen Zorn 2013-08-30 draft-kaplan-insipid-session-id-03 Glen Zorn 2014-01-17 draft-ietf-mpls-moving-iana-registries-03 -- kivinen@iki.fi From vincent.roca@inria.fr Fri Jan 10 06:48:59 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A771AE029; Fri, 10 Jan 2014 06:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.787 X-Spam-Level: X-Spam-Status: No, score=-6.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oo1taOS2v7zb; Fri, 10 Jan 2014 06:48:55 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by ietfa.amsl.com (Postfix) with ESMTP id 91DFF1ADF33; Fri, 10 Jan 2014 06:48:54 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,638,1384297200"; d="scan'208,217";a="44345714" Received: from demeter.inrialpes.fr ([194.199.24.102]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 10 Jan 2014 15:48:43 +0100 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-66-888747167 From: Vincent Roca In-Reply-To: <01ae01cf0d24$e9d492c0$bd7db840$@it.uc3m.es> Date: Fri, 10 Jan 2014 15:48:43 +0100 Message-Id: <1AB135AC-8BE6-4653-945A-15FC226F162E@inria.fr> References: <206CF360-2CE2-4472-9252-707E0CB0888A@inria.fr> <01ae01cf0d24$e9d492c0$bd7db840$@it.uc3m.es> To: =?iso-8859-1?Q?Alberto_Garc=EDa?= X-Mailer: Apple Mail (2.1085) Cc: secdir@ietf.org, 'IESG' , draft-ietf-savi-send@tools.ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-savi-send-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 14:49:00 -0000 --Apple-Mail-66-888747167 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello Alberto, > This i-d contains a detailed Security Consideration sections which is = great. > However I have a few questions and comments. > =20 > 1/ Section 5 says: > "The interaction in a mixed scenario comprising SEND and non-SEND > devices should be addressed in other document." > What happens if an attacker behaves as a non-SEND host? Is it = sufficient > to escape SEND SAVI and launch an attack? This is not said. > =20 > Yes, this is not said and it should. I have modified the first = paragraph to say: > =20 > SEND SAVI operates only with validated SEND messages. Note that = IPv6 > packets generated by non-SEND nodes will be discarded by the first > SEND SAVI device receiving it. Therefore, attackers cannot obtain > any benefit by not using SEND. In order to perform address > validation in a mixed scenario comprising SEND and non-SEND = devices, > a different solution is required, which should be addressed in = other > document. VR: perfect. > 2/ Section 5.2 says: > "The recommended minimum > is the memory needed to store 4 bindings associated to the port." > If there are several hosts behind this port (e.g., several hosts = behind a hub > attached to this switch, or several virtual machines), this value of 4 = may not > be sufficient. I agree that having per-port buffers is fine, but = specifying a > value is risky. > =20 > This text is also included in RFC 6620 (FCFS SAVI) > Note that the value specified is a *minimum*, which means that > - Implementors of SEND SAVI devices could raise this number, of = course, probably depending on the memory they have. > - This is the minimum in case malicious nodes are connected to = other ports trying to exhaust memory; i.e., there will always be at = least 4 bindings, which should be a minimum number of addresses for one = basic host (link local address + global unicast address=85). Even if = this is the minimum being set, when an attack is not occurring more than = 4 bindings could be available to certain ports, assuming that the device = can store more bindings than 4*number_of_ports. > =20 > In order to stress the first idea, I have rephrased the paragraph as = follows: > =20 > The recommended minimum > is the memory needed to store four bindings associated to the port, > although it should be raised if the ratio between the maximum = number > of bindings allowed in the device and the number of ports is high. VR: I understand that this is a minimum, but don't you think that = because a value is mentioned, there is a risk? In the new text, you're saying: "it should be raised if...". First of = all, it's better to use RFC2119 keywords. Then why do you say "should"? I'd rather say "MUST" since there is no choice = in that case. > By the way, you raise an interesting issue that has not been = considered in the previous versions of the document: the virtual machine = case. In order to address this, at least cursorily, I have included the = following text in section 2.4 =91Special Cases=92: > =20 > Virtual switches: A hypervisor or a host Operating System may = perform > bridging functions between virtual hosts running on the same = machine. > The hypervisor or host OS may in turn connect to a SEND SAVI = system. > This scenario is depicted in the next figure, with two virtual > machines VM1 and VM2 connected through a virtual switch VS1 to SEND > SAVI device SEND-SAVI1. The attachment points of VS1 to VM1 and = VM2 > are configured as Validating. > =20 > =20 > Host1 > +----------------+ > | +---+ +---+ | > | |VM1| |VM2| | > | +---+ +---+ | > | | | | > | +-1-----2--+ | > | | VS1 | | > | +--3-------+ | > | | | > +----|-----------+ > | > | > +--1-----2--+ > | SEND- | > | SAVI1 | > +--3---4----+ > | | > =20 > =20 > =20 > In order to provide proper security against replay attacks, it is > recommended to perform SEND SAVI filtering as close to untrusted > hosts as possible (see Section 3.4 and Section 5.1). In this > scenario, this objective can be achieved by enabling SEND SAVI > validation in VS1. Ideally, VS1 could be integrated into the SEND > SAVI protection perimeter, if the hypervisor or host OS at Host1 = can > be trusted (even though VM1 and VM2 could not be trusted). To do = so, > both the attachment to SEND-SAVI1 at VS1, and port 1 at SEND-SAVI1, > are configured as Trusted. > =20 > If the administrator of the network does not trust on VS1, port 1 = of > SEND-SAVI1 is configured as Validating, so that every address being > used at Host1 is validated at SEND-SAVI1 by SEND SAVI. The > attachment point to the physical network at VS1 should be = configured > as Trusted, if the host administrator knows that it is connected to = a > SEND SAVI device; in this case, VS1 relies on the infrastructure > comprised by the physical SEND SAVI devices, but not the other way. > Packets egressing from VM1 are validated twice, first at VS1, and > then at SEND-SAVI1; packets going in the reverse direction (from an > external host to VM1) are validated once, when they first reach a > SEND SAVI device. If the administrator of VS1 does not trust on = the > physical switch to which it attaches, it can configure the = attachment > to SEND-SAVI1 as Validating. In the figure above, this means that = a > packet going from another host to VM1 would be validated twice, = once > when entering the SEND SAVI perimeter formed by the physical = devices, > and the other when entering at VS1. > =20 > =20 > =20 > =20 > 3/ Section 5.2 is a bit confusing and I'm wondering if it could not be = simplified. > =20 > Just to provide some background about this section: it is almost the = same text as section 4.1 of RFC 6620, since the DoS problems are mostly = the same (except for the last paragraph of the section, which insists in = the extra cost of cryptographic operations due to the use of SEND. > This being said, I do not pretend that RFC6620 text could not be = improved. VR: It makes sense to borrow text from previous documents, but improving = it makes sense too. Anyway, the only think that matters is the result. > Basically, it says: > - in case of memory shortage, it is RECOMMENDED to "delete the entries = with > a higher Creation time". > BTW, what do you mean by "higher creation time"? The oldest entries = el? > =20 > =20 > No, the newer ones, as the next sentence clarifies: =91This implies = that older entries are preserved and newer entries overwrite each other.=20= VR: The new text is much better and avoids any misunderstanding. > - it is RECOMMENDED to reserve some memory for each port in order to = isolate > the effects to the attacker's port; > - one MUST limit the maximum amount of memory used to store data = packets > in order to keep memory for other tasks; > - one SHOULD rate limit packets which may trigger SEND SAVI events, = since > it requires costly crypto operations. > BTW, why do you say "which may trigger" instead of "which trigger"? > I remove =91may=92. > Your summary is correct. > =20 > =20 > Third paragraph is strange. > =20 > According to your comments, I have changed the text to (I explain = later the changes): > The SEND SAVI device may store data packets while the address is > being verified, for example, when a DAD_NSOL was lost before = arriving > to the SEND SAVI device to which the host attaches, and the host > sends data packets, these data packets may be stored until the SEND > SAVI device verifies the binding by means of a NUD packet exchange. > In this case, the memory for data packet storage may also be a = target > of DoS attacks. A SEND SAVI device MUST limit the amount of memory > used to store data packets, allowing the other functions (such as > being able to store new bindings) to have available memory even in > the case of an attacks such those described above. > =20 > =20 > =20 > =20 > I read: > "As the SEND SAVI device may store data packets while the address = is > being verified..." > If the incoming packet rate is higher than the packet verification = rate, sure > there will be problems. Is it what the authors mean? I don't see any = good > solution except rate limiting the incoming packet flow. > =20 > I think it was not clear enough the case to which we were referring. = That=92s why I changed the first sentence. > What I want to note is that this is a particular case, but not =91normal= operation=92 of the SAVI device, because in most cases (well-behaved = hosts), DAD_NSOL is going to be issued first, and the host will not send = packets until the address is valid (and so the state at the SEND SAVI = devices). > However, we do not want malicious nodes to exploit the fact that = memory (especially for other more relevant uses, such as storing = bindings) could be exhausted in this way. VR: agreed. > Later: > "The effects of such attacks may be limited to > the lack of capacity to store new data packets." > Does it mean that setting an upper limit to the amount of = memory devoted > to store data packets is a way to mitigate the attack (last sentence), > or does it mean that the attack will lead packets to be dropped = (following > sentence)? > =20 > I agree that the two sentences starting by the one you copy here were = hard to understand. As you see in the new version of the text (above), I = have removed them. What I think is the most relevant problem is that = using memory for this could drain resources for other functions, and = this is stated in the last sentence. VR: okay. > And when it is said that: > "A SEND SAVI device MUST limit the amount of > memory used to store data packets, allowing the other functions to > have available memory even in the case of an attacks..." > What do you mean by "other functions"? SEND SAVI functions? Others? > I have clarified this in the text > =20 > 5/ Section 5.4 says that "a SEND SAVI MUST NOT log binding anchor = information > except [if there's a good reason for that]". And later that = "information about > the majority of hosts that never spoof SHOULD NOT be logged." > =20 > The intention is fine, but if I understand correctly, SAVI requires to = identify > a host's legitimate IP source addresses (RFC 7039). It means that this = information > will be logged any away as SAVI needs it (if I understand correctly). > Or may be by "logging" you mean "long term logging" but in that case = this is > not clear. Or is there something else I've missed? > =20 > You are right. I have changed this to > =20 > A SEND SAVI device MUST delete binding anchor information as soon = as > possible (i.e., as soon as the state for a given address is back to > NO_BIND), except where there is an identified reason why that > information is likely to be involved in detection, prevention or > tracing of actual source address spoofing. Information about the > majority of hosts that never spoof SHOULD NOT be logged. VR: okay > Typos: > =20 > ** s/reply/replay in: > "There are two different cases to analyze when considering SEND = SAVI > reply attacks:" > =20 > ** s/In this two cases/In these two cases/ > =20 > ** s/messages which does not result in changes/messages which do not = result in changes/ > =20 > ** s/in the case of an attacks such those described above/in the case = of an attack like the one described above/ > =20 > Corrected! > Thanks again for your comments You're welcome. Cheers, Vincent= --Apple-Mail-66-888747167 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hello Alberto,

This = i-d contains a detailed Security Consideration sections which is = great.
However I have a few questions and = comments.
 
1/ Section 5 = says:
 =  "The interaction in a mixed scenario comprising SEND and = non-SEND
   devices should be addressed in other = document."
What happens if an attacker behaves as a non-SEND host? = Is it sufficient
to escape SEND SAVI and launch an = attack? This is not said.
Yes, this is not said and it should. I have modified = the first paragraph to say:
   SEND SAVI operates only with = validated SEND messages.  Note that = IPv6
   packets generated by non-SEND nodes will be = discarded by the first
   SEND SAVI device receiving = it.  Therefore, attackers cannot obtain
   any = benefit by not using SEND.  In order to perform = address
   validation in a mixed scenario = comprising SEND and non-SEND devices,
   a = different solution is required, which should be addressed in = other
    = document.

VR: perfect.


2/ Section 5.2 = says:
 =  "The recommended minimum
   is the memory needed = to store 4 bindings associated to the = port."
If = there are several hosts behind this port (e.g., several hosts behind a = hub
attached to this switch, or several virtual machines), = this value of 4 may not
be sufficient. I agree that having = per-port buffers is fine, but specifying = a
value = is risky.
 
This text is also included in RFC = 6620 (FCFS SAVI)
- Implementors of SEND SAVI devices could raise this number, = of course, probably depending on the memory they = have.
        This is the minimum in case malicious nodes are connected = to other ports trying to exhaust memory; i.e., there will always be at = least 4 bindings, which should be a minimum number of addresses for one = basic host (link local address + global unicast address=85). Even if = this is the minimum being set, when an attack is not occurring more than = 4 bindings could be available to certain ports, assuming that the device = can store more bindings than = 4*number_of_ports.
 
In order to stress the first idea, I have rephrased the = paragraph as follows:
 
   The recommended =
minimum
   is the memory needed to store four =
bindings associated to the port,
   =
although it should be raised if the ratio between the maximum =
number
   of bindings allowed in the device and =
the number of ports is high.
why do you say = "should"? I'd rather say "MUST" since there is no choice in that = case.


By = the way, you raise an interesting issue that has not been considered in = the previous versions of the document: the virtual machine case. In = order to address this, at least cursorily, I have included the following = text in section 2.4 =91Special Cases=92:
   Virtual switches: A hypervisor or a = host Operating System may perform
   =
bridging functions between virtual hosts running on the same =
machine.
   The hypervisor or host =
OS may in turn connect to a SEND SAVI =
system.
   This scenario is =
depicted in the next figure, with two =
virtual
   machines VM1 and VM2 =
connected through a virtual switch VS1 to =
SEND
   SAVI device SEND-SAVI1.  The =
attachment points of VS1 to VM1 and VM2
   =
are configured as Validating.
 
       =
| +---+   +---+  |
       | =
+---+   +---+  |
       | =
+-1-----2--+   |
       =
|    =
|           =
|
       =
+----|-----------+
         =
+--1-----2--+
 
 
   =
In order to provide proper security against replay attacks, it =
is
   recommended to perform SEND SAVI =
filtering as close to untrusted
   =
hosts as possible (see Section 3.4 and Section 5.1).  In =
this
   scenario, this objective can be =
achieved by enabling SEND SAVI
   =
validation in VS1.  Ideally, VS1 could be integrated into the =
SEND
   SAVI protection perimeter, if the =
hypervisor or host OS at Host1 can
   =
be trusted (even though VM1 and VM2 could not be trusted).  To do =
so,
   both the attachment to SEND-SAVI1 at =
VS1, and port 1 at SEND-SAVI1,
   =
are configured as Trusted.
   If the administrator of =
the network does not trust on VS1, port 1 of
   =
SEND-SAVI1 is configured as Validating, so that every address =
being
   used at Host1 is =
validated at SEND-SAVI1 by SEND SAVI.  =
The
   attachment point to the physical =
network at VS1 should be configured
   =
as Trusted, if the host administrator knows that it is connected to =
a
   SEND SAVI device; in this case, VS1 =
relies on the infrastructure
   =
comprised by the physical SEND SAVI devices, but not the other =
way.
   Packets egressing from VM1 are =
validated twice, first at VS1, and
   =
then at SEND-SAVI1; packets going in the reverse direction (from =
an
   external host to VM1) are validated =
once, when they first reach a
   =
SEND SAVI device.  If the administrator of VS1 does not trust on =
the
   physical switch to which it attaches, =
it can configure the attachment
   =
to SEND-SAVI1 as Validating.  In the figure above, this means that =
a
   packet going from another host to VM1 =
would be validated twice, once
   =
when entering the SEND SAVI perimeter formed by the physical =
devices,
   and the other when entering at =
VS1.
 
 
3/ Section 5.2 is a bit confusing and I'm wondering if it = could not be simplified.
Just to provide some background about this section: = it is almost the same text as section 4.1 of RFC 6620, since the DoS = problems are mostly the same (except for the last paragraph of the = section, which insists in the extra cost of cryptographic operations due = to the use of SEND.
This being said, I do not pretend = that RFC6620 text could not be improved.
Basically, it says:
- in case of memory shortage, it = is RECOMMENDED to "delete the entries = with
  a higher = Creation time".
 = BTW, what do you mean by "higher creation time"? The oldest = entries el?<= /div>
 
No, the newer ones, as the next =
sentence clarifies: =91This implies that older entries are preserved and newer =
entries overwrite each other.
- it is RECOMMENDED to = reserve some memory for each port in order to = isolate
 = the effects to the attacker's port;
- one MUST limit the maximum = amount of memory used to store data = packets
 = in order to keep memory for other = tasks;
- = one SHOULD rate limit packets which may trigger SEND SAVI events, = since
  it requires = costly crypto operations.
  BTW, why do you say "which = may trigger" instead of "which = trigger"?
I remove = =91may=92.
Your summary is = correct.
 
Third = paragraph is strange. 
According = to your comments, I have changed the text to (I explain later the = changes):
   The SEND SAVI device may store data =
packets while the address is
   =
being verified, for example, when a DAD_NSOL was lost before =
arriving
   to the SEND SAVI device to which the =
host attaches, and the host
   =
sends data packets, these data packets may be stored until the =
SEND
   SAVI device verifies the binding by =
means of a NUD packet exchange.
   =
In this case, the memory for data packet storage may also be a =
target
   of DoS attacks.  A SEND SAVI =
device MUST limit the amount of memory
   =
used to store data packets, allowing the other functions (such =
as
   being able to store new bindings) to =
have available memory even in
   =
the case of an attacks such those described =
above.
 
 
I = read:
   "As the = SEND SAVI device may store data packets while the address = is
   being = verified..."
If = the incoming packet rate is higher than the packet verification rate, = sure
there will be problems. = Is it what the authors mean? I don't see any = good
solution except rate = limiting the incoming packet flow.
I think it was not clear enough the case to which we = were referring. That=92s why I changed the first = sentence.
What I want to note is that this is a particular = case, but not =91normal operation=92 of the SAVI device, because in most = cases (well-behaved hosts), DAD_NSOL is going to be issued first, and = the host will not send packets until the address is valid (and so the = state at the SEND SAVI devices).
However, we = do not want malicious nodes to exploit the fact that memory (especially = for other more relevant uses, such as storing bindings) could be = exhausted in this = way.
VR: agreed.


Later:
   "The effects of such = attacks may be limited to
   the lack of capacity = to store new data packets."
          Does it mean that setting an upper limit to the amount of = memory devoted
to = store data packets is a way to mitigate the attack (last = sentence),
or = does it mean that the attack will lead packets to be dropped = (following
sentence)?
I agree that the two sentences starting by the one = you copy here were hard to understand. As you see in the new version of = the text (above), I have removed them. What I think is the most relevant = problem is that using memory for this could drain resources for other = functions, and this is stated in the last = sentence.

VR: okay.


And when it is said = that:
   "A SEND = SAVI device MUST limit the amount of
   memory used to store = data packets, allowing the other functions = to
   have = available memory even in the case of an = attacks..."
What = do you mean by "other functions"? SEND SAVI functions? = Others?
I have clarified this in the = text
 
5/ Section 5.4 says that "a SEND = SAVI MUST NOT log binding anchor = information
except= [if there's a good reason for that]". And later that "information = about
the majority of hosts = that never spoof SHOULD NOT be = logged."
 
The intention is fine, but if I = understand correctly, SAVI requires to = identify
a = host's legitimate IP source addresses (RFC 7039). It means that this = information
will = be logged any away as SAVI needs it (if I understand = correctly).
Or = may be by "logging" you mean "long term logging" but in that case this = is
not clear. Or is there = something else I've missed?
You are right. I have changed this = to
 
   =
A SEND SAVI device MUST delete binding anchor information as soon =
as
   possible (i.e., as soon as the state =
for a given address is back to
   =
NO_BIND), except where there is an identified reason why =
that
   information is likely to be involved in =
detection, prevention or
   tracing of actual =
source address spoofing.  Information about =
the
   majority of hosts that never spoof =
SHOULD NOT be logged.
Typos:
 
** s/reply/replay =  in:
   "There are two different cases to analyze = when considering SEND SAVI
   reply = attacks:"
 
** s/In this two cases/In these = two cases/
 
** s/messages which does not = result in changes/messages which do not result in = changes/
 
** s/in the case of an attacks = such those described above/in the case of an attack like the one = described above/
, "draft-moriarty-pkcs12v1-1.all@tools.ietf.org" , "Org Secdir@Ietf." Thread-Topic: Secdir review of draft-moriarty-pkcs12v1-1-03 Thread-Index: Ac8OoNNjmUASwqpuQRqIGLIzjfx0kA== Date: Sat, 11 Jan 2014 07:43:32 +0000 Message-ID: <37320726-3F8C-43B8-BCBD-5C40DF1F2572@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_373207263F8C43B8BCBD5C40DF1F2572huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [secdir] Secdir review of draft-moriarty-pkcs12v1-1-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 07:44:01 -0000 --_000_373207263F8C43B8BCBD5C40DF1F2572huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQpJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBz ZWN1cml0eSBkaXJlY3RvcmF0ZSdzDQpvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYg ZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUNCklFU0cuICBUaGVzZSBjb21tZW50cyB3 ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUNCnNlY3VyaXR5IGFy ZWEgZGlyZWN0b3JzLiBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0 DQp0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4N Cg0KTW9zdCBvZiB0aGUgY29udGVudHMgaW4gdGhpcyBkcmFmdCBpcyB0YWtlbiBkaXJlY3RseSBm cm9tIGEgcHVibGlzaGVkIFJTQSBkb2N1bWVudCBQS0NTICMxMi4gSW4gdGhpcyB2ZXJzaW9uLCBu ZWFybHkgYWxsIHRoZSB0eXBvcyBhcmUgY29ycmVjdGVkLiBJIHRoaW5rIHRoaXMgZG9jdW1lbnQg aXMgZ29vZCBlbm91Z2ggZm9yIHB1YmxpY2F0aW9uLg0KDQpJbiBzZWN1cml0eSBjb25zaWRlcmF0 aW9uLCBpdCBpcyBzdWdnZXN0ZWQgdG8gZm9sbG93IFBLQ1MgIzUgKFJGQzI4OTgpIHRvIHNlbGVj dCBwYXNzd29yZHMuIEkgcmVhbGl6ZSB0aGF0IGluIFJGQzI4OTggdGhlcmUgaXMgbm8gZGlzY3Vz c2lvbiBhYm91dCBob3cgdG8gZW5zdXJlIGEgZ29vZCByYW5kb21uZXNzIG9mIHRoZSBzYWx0LiAg VGhlcmVmb3JlLCBJIHN1Z2dlc3QgdG8gY2l0ZSBSRkM0MDg2Lg0KTWF5YmUgdGhlcmUgc2hvdWxk IGFsc28gYmUgYSByZWZlcmVuY2UgdG8gQXBwZW5kaXggQiwganVzdCB0byBwdXQgdGhhdCBBcHBl bmRpeCBpbnRvIHBlcnNwZWN0aXZlIC4uLiBzYXlpbmcgdGhhdCBSRkMgNDA4NiBpcyB0aGUgc3Vw ZXJpb3IgZ3VpZGUsIGJ1dCBmb3IgaW50ZWdyaXR5IHByb3RlY3Rpb24gb25seSwgdGhlIG1ldGhv ZCBvZiBBcHBlbmRpeCBCIG1heSBiZSBhZGVxdWF0ZS4NCg0KVHlwbzogc2Vjb25kIGxpbmUgb2Yg QWJzdHJhY3QNCihSZXB1YmxpY2F0aW9uKSBGcm9tIC0+IChSZXB1YmxpY2F0aW9uKSBmcm9tDQoN ClR5cG8sIFNlYy4gMS4xLCB0aGlyZCBmcm9tIGxhc3QgYnVsbGV0IHJlZ2FyZGluZyBTUCA4MDAt MTMyDQpzZWxlY3Rpb24gb2YgYSB0aGUgLT4gc2VsZWN0aW9uIG9mIHRoZQ0KDQpOaXQ6IEFwcGVu ZGl4IEIsIFNlYy4gQi40DQpwYXNzd29yZHMgYW5kIHNhbHQgdGhhdCB3YXMgZ2l2ZW4gaW4gQXBw ZW5kaXggQw0KIC0+IHBhc3N3b3JkcyBhbmQgc2FsdCB0aGF0IGlzIGdpdmVuIGluIEFwcGVuZGl4 IEMNCg0KVGhhbmsgeW91LA0KVGluYQ0K --_000_373207263F8C43B8BCBD5C40DF1F2572huaweicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2IHN0eWxlPSItd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87Ij48c3Bhbj48L3NwYW4+ PC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRv OyI+PHNwYW4+PC9zcGFuPjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Ii13ZWJraXQtdGV4dC1z aXplLWFkanVzdDogYXV0bzsiPjxzcGFuPjwvc3Bhbj48L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxl PSItd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87Ij48c3Bhbj48L3NwYW4+PC9kaXY+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTNwdDsiPkRlYXIgYWxsLDwvc3Bhbj48L2Rpdj4NCjxkaXY+PHNw YW4gc3R5bGU9Ii13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgYmFja2dyb3VuZC1jb2xv cjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50 IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3M8YnI+DQpvbmdvaW5nIGVmZm9y dCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGU8YnI+ DQpJRVNHLiAmbmJzcDtUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0 aGUgYmVuZWZpdCBvZiB0aGU8YnI+DQpzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4gRG9jdW1lbnQg ZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdDxicj4NCnRoZXNlIGNvbW1lbnRzIGp1 c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLjxicj4NCjwvc3Bhbj48L2Rpdj4N CjxkaXYgc3R5bGU9Ii13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsiPjxicj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0iLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyI+DQo8ZGl2Pjxm b250IGNvbG9yPSIjMDAwMDAwIj48c3BhbiBzdHlsZT0iLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0 OiBhdXRvOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+TW9zdCBv ZiB0aGUgY29udGVudHMgaW4gdGhpcyBkcmFmdCBpcyB0YWtlbiBkaXJlY3RseSBmcm9tIGEgcHVi bGlzaGVkJm5ic3A7PC9zcGFuPjwvZm9udD48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjog cmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyI+ UlNBDQogZG9jdW1lbnQgUEtDUyAjMTIuIEluIHRoaXMgdmVyc2lvbiwgbmVhcmx5IGFsbCB0aGUg dHlwb3MgYXJlJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2Jh KDI1NSwgMjU1LCAyNTUsIDApOyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87Ij5jb3Jy ZWN0ZWQuIEkgdGhpbmsgdGhpcyBkb2N1bWVudCBpcyBnb29kIGVub3VnaCBmb3IgcHVibGljYXRp b24uPC9zcGFuPjwvZGl2Pg0KPGRpdj48Zm9udCBjb2xvcj0iIzAwMDAwMCI+PHNwYW4gc3R5bGU9 Ii13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgYmFja2dyb3VuZC1jb2xvcjogcmdiYSgy NTUsIDI1NSwgMjU1LCAwKTsiPjxicj4NCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250 IGNvbG9yPSIjMDAwMDAwIj48c3BhbiBzdHlsZT0iLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBh dXRvOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+SW4gc2VjdXJp dHkgY29uc2lkZXJhdGlvbiwgaXQgaXMgc3VnZ2VzdGVkIHRvIGZvbGxvdyBQS0NTICM1IChSRkMy ODk4KSZuYnNwOzwvc3Bhbj48L2ZvbnQ+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJn YmEoMjU1LCAyNTUsIDI1NSwgMCk7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsiPnRv DQogc2VsZWN0IHBhc3N3b3Jkcy4gSSByZWFsaXplIHRoYXQgaW4gUkZDMjg5OCB0aGVyZSBpcyBu byBkaXNjdXNzaW9uJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiBy Z2JhKDI1NSwgMjU1LCAyNTUsIDApOyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87Ij5h Ym91dCBob3cgdG8gZW5zdXJlIGEgZ29vZCByYW5kb21uZXNzIG9mIHRoZSBzYWx0LiAmbmJzcDtU aGVyZWZvcmUsIEkmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJn YmEoMjU1LCAyNTUsIDI1NSwgMCk7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsiPnN1 Z2dlc3QNCiB0byBjaXRlIFJGQzQwODYuPC9zcGFuPjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+PC9ibG9ja3F1b3RlPg0KPHNwYW4gc3R5bGU9Ii13ZWJraXQtdGV4dC1zaXplLWFkanVz dDogYXV0bzsgYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPk1heWJl IHRoZXJlIHNob3VsZCBhbHNvIGJlIGEgcmVmZXJlbmNlIHRvIEFwcGVuZGl4IEIsIGp1c3QgdG8g cHV0IHRoYXQgQXBwZW5kaXggaW50byBwZXJzcGVjdGl2ZSAuLi4gc2F5aW5nIHRoYXQgUkZDIDQw ODYgaXMgdGhlIHN1cGVyaW9yIGd1aWRlLCBidXQgZm9yIGludGVncml0eSBwcm90ZWN0aW9uDQog b25seSwgdGhlIG1ldGhvZCBvZiBBcHBlbmRpeCBCIG1heSBiZSBhZGVxdWF0ZS48L3NwYW4+PC9k aXY+DQo8ZGl2IHN0eWxlPSItd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87Ij48YnI+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9Ii13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsiPjxzcGFu IHN0eWxlPSItd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IGJhY2tncm91bmQtY29sb3I6 IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij5UeXBvOiBzZWNvbmQgbGluZSBvZiBBYnN0cmFjdDxi cj4NCihSZXB1YmxpY2F0aW9uKSBGcm9tIC0mZ3Q7IChSZXB1YmxpY2F0aW9uKSBmcm9tPGJyPg0K PGJyPg0KVHlwbywgU2VjLiAxLjEsIHRoaXJkIGZyb20gbGFzdCBidWxsZXQgcmVnYXJkaW5nIFNQ IDgwMC0xMzI8YnI+DQpzZWxlY3Rpb24gb2YgYSB0aGUgLSZndDsgc2VsZWN0aW9uIG9mIHRoZTxi cj4NCjxicj4NCk5pdDogQXBwZW5kaXggQiwgU2VjLiBCLjQ8YnI+DQpwYXNzd29yZHMgYW5kIHNh bHQgdGhhdCB3YXMgZ2l2ZW4gaW4gQXBwZW5kaXggQzxicj4NCiZuYnNwOy0mZ3Q7IHBhc3N3b3Jk cyBhbmQgc2FsdCB0aGF0IGlzIGdpdmVuIGluIEFwcGVuZGl4IEM8L3NwYW4+PGJyPg0KPGRpdiBz dHlsZT0iLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyI+PGJyPg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSItd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87Ij5UaGFuayB5b3UsPC9kaXY+ DQo8ZGl2IHN0eWxlPSItd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87Ij5UaW5hPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_373207263F8C43B8BCBD5C40DF1F2572huaweicom_-- From jsalowey@cisco.com Sun Jan 12 20:45:11 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5BA41AE02A; Sun, 12 Jan 2014 20:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLN5xQWkvP2N; Sun, 12 Jan 2014 20:45:10 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 809D01AE027; Sun, 12 Jan 2014 20:45:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1982; q=dns/txt; s=iport; t=1389588300; x=1390797900; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=fFlNTeKGCnAGBYwl78SK+tdSi17i1STXHEylFydwQ9I=; b=jQLRCfA3j61LR1N6Voa308cQTlgVXrBcBPlHYI/Yp4d5nPcjWqTZMk8Y Lib/6G+eXJF5kxgLNsZxflDzTEgbrVarkBhtGoECWcoMBoY9al4eGEE4E p1d/LMSNvBgM4u1aMQWDUROPJn9aengR49OYhaW+QCLVpS1gDXAt+rK3v g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAONu01KtJXG8/2dsb2JhbABagwuBDrpwFnSCLDpRAT5CJwQBiBbEMheSMoETBJgXkhWDLYIq X-IronPort-AV: E=Sophos;i="4.95,650,1384300800"; d="scan'208";a="12343004" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-6.cisco.com with ESMTP; 13 Jan 2014 04:44:59 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0D4ixiN019101 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Jan 2014 04:44:59 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.86]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Sun, 12 Jan 2014 22:44:59 -0600 From: "Joseph Salowey (jsalowey)" To: "draft-ietf-soc-overload-control.all@tools.ietf.org" , "" , "iesg@ietf.org IESG" Thread-Topic: secdir review of draft-ietf-soc-overload-control-14 Thread-Index: AQHPEBo2YX1Dg/QDZk2cs+kAGN4Y7A== Date: Mon, 13 Jan 2014 04:44:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.158] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] secdir review of draft-ietf-soc-overload-control-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 04:45:12 -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. I think this document is ready with some minor issues.=20 First I like what you have done with the security considerations section. = It defines the attacks of concern in a clear way and describes some mitigat= ions. =20 1. The security considerations section mentions several mitigations for f= alse overload control messages including TCP, Websockets, BCP-38 and TLS. = While TCP and Websockets provide more protection than UDP its not clear to= me that they are providing sufficient protection. In addition, it seems = that BCP-38 should be encouraged in all cases (not just the TLS case). I'= d feel better about the recommendation if it stated some thing like "TCP an= d Websockets in conjunction with BCP-38 make it more difficult for an attac= ker to insert or modify messages, but it is still possible depending on wh= ere the attacker is positioned in the network. TLS provides better protect= ion from an attacker that has access to the network link." 2. Some privacy considerations are mentioned in section 5.3. Its not real= ly clear to me what these considerations are so it would be good to expand = upon them in the security considerations section. =20 3. Is it possible that some of the oc-agorithms might have their own secur= ity considerations. If this is likely then it might be good to indicate th= e reader should check to see if the individual algorithm specifications sec= urity considerations.=20 4. Is there any mitigation for the attack involving a proxy that does not = support mechanism from blindly forwarding an attacker's oc headers? Cheers, Joe= From Attila.Takacs@ericsson.com Sat Jan 11 22:43:21 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6B11ADF4F; Sat, 11 Jan 2014 22:43:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.55 X-Spam-Level: X-Spam-Status: No, score=-3.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTB62EZse-gU; Sat, 11 Jan 2014 22:43:19 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 169EF1ADF0F; Sat, 11 Jan 2014 22:43:17 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-6a-52d2397ae4fc Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id FC.05.23787.A7932D25; Sun, 12 Jan 2014 07:43:06 +0100 (CET) Received: from ESESSMB201.ericsson.se ([169.254.1.59]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0347.000; Sun, 12 Jan 2014 07:43:06 +0100 From: Attila Takacs To: =?iso-8859-2?Q?Magnus_Nystr=F6m?= , "secdir@ietf.org" , "draft-ietf-ccamp-oam-configuration-fwk@tools.ietf.org" Thread-Topic: Security directorate review of draft-ietf-ccamp-oam-configuration-fwk Thread-Index: AQHPCbXXYPN/St4ZLU2A1aRWLct1u5qAr0Fw Date: Sun, 12 Jan 2014 06:43:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_B336D1B7DDD08C44AE2B75E37932D09C1C42137BESESSMB201erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM+JvjW6V5aUgg02NVhYvNu1itJjxZyKz xfGty1ktPix8yOLA4rFz1l12jyVLfjJ5fLn8mS2AOYrLJiU1J7MstUjfLoErY8WK7UwF1/Qr Vv6PaGC8o9nFyMEhIWAicXF+VBcjJ5ApJnHh3nq2LkYuDiGBQ4wS59a1s4EkhAQWM0rs3KsB YrMJGEhcaJ7MDFIkInAZKP79FxNIgllAWeLmkVfMILawQIhE251DYM0iAqESFzZtYIKwjSS2 H4EYyiKgKnGl8Q4LiM0r4CvReGsyK8hBQgIBEh9bGEHCnAKBElPnzwErYQQ67vupNVCrxCVu PZnPBHG0gMSSPeeZIWxRiZeP/7FC2EoSaw9vZ4Goz5fYubwDapWgxMmZT1gmMIrOQjJqFpKy WUjKIOJ6Es9OzYKytSWWLXzNDGHrSlx6uI4VWXwBI/sqRvbcxMyc9HLDTYzAaDu45bfuDsZT 50QOMUpzsCiJ83546xwkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgZFpT70JN0/u5ku1kp9+ VaZczpg0O9/abZMzMwMH0wnerwbGJr+2/vmccfbf/Zj4Tb8W2d18axXtkJISc33+bE3jNw+f 7UxfXvNcw9nq9KPj95amSc+WWzJVN6PyaKvUo57+FMF4/ps6B24ssYvXnGvELOTutn7LTaEf x6eETHFsy7qeYJtmmaLEUpyRaKjFXFScCAC7mGbYhAIAAA== X-Mailman-Approved-At: Mon, 13 Jan 2014 08:08:57 -0800 Cc: "iesg@ietf.org" Subject: Re: [secdir] Security directorate review of draft-ietf-ccamp-oam-configuration-fwk X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 06:43:21 -0000 --_000_B336D1B7DDD08C44AE2B75E37932D09C1C42137BESESSMB201erics_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hi Magnus, Thanks for the review! We will update the Security section based on your proposal below. Attila From: Magnus Nystr=F6m [mailto:magnusn@gmail.com] Sent: Saturday, January 04, 2014 5:32 PM To: secdir@ietf.org; draft-ietf-ccamp-oam-configuration-fwk@tools.ietf.org Cc: iesg@ietf.org Subject: Security directorate review of draft-ietf-ccamp-oam-configuration-= fwk 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 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. This document describes extensions to RSVP-TE in support of the establishme= nt of Operation, Administration and Management entities in the context of G= MPLS . The document seems well written. I would suggest removing the last sentence= of the Security Considerations section ("Cryptography can be used...") sin= ce it does not really offer any hint as to how to use cryptography. Instead= , the previous sentence could be replaced with something like: "For a more = comprehensive discussion of GMPLS security, and attack mitigation technique= s, please see the Security Framework for MPLS and GMPLS Networks [RFC5920]." -- Magnus --_000_B336D1B7DDD08C44AE2B75E37932D09C1C42137BESESSMB201erics_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Hi Magnus,=

Thanks for= the review!

We will up= date the Security section based on your proposal below.

Attila

 <= /p>

From: Magnus Nystr=F6m [mailto:magnusn@gmail.com]
Sent: Saturday, January 04, 2014 5:32 PM
To: secdir@ietf.org; draft-ietf-ccamp-oam-configuration-fwk@tools.ie= tf.org
Cc: iesg@ietf.org
Subject: Security directorate review of draft-ietf-ccamp-oam-configu= ration-fwk

 

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

This document describes extensions to RSVP-TE in support of the establishme= nt of Operation, Administration and Management entities in the context of G= MPLS .

The document seems well written. I would suggest removing the last sentence= of the Security Considerations section ("Cryptography can be used...&= quot;) since it does not really offer any hint as to how to use cryptograph= y. Instead, the previous sentence could be replaced with something like: "For a more comprehensive discussion of= GMPLS security, and attack mitigation techniques, please see the Security = Framework for MPLS and GMPLS Networks [RFC5920]."

 
-- Magnus

--_000_B336D1B7DDD08C44AE2B75E37932D09C1C42137BESESSMB201erics_-- From alberto@it.uc3m.es Mon Jan 13 08:12:17 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58931ACCED; Mon, 13 Jan 2014 08:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.772 X-Spam-Level: X-Spam-Status: No, score=-3.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IS1ilX768pIg; Mon, 13 Jan 2014 08:12:08 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 37C071AC4A7; Mon, 13 Jan 2014 08:12:07 -0800 (PST) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id CA126CC478B; Mon, 13 Jan 2014 16:55:01 +0100 (CET) X-uc3m-safe: yes X-uc3m-safe: yes Received: from BOMBO (unknown [163.117.139.50]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: alberto@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id A8D0FCB7C48; Mon, 13 Jan 2014 16:55:01 +0100 (CET) From: =?iso-8859-1?Q?Alberto_Garc=EDa?= To: "'Vincent Roca'" References: <206CF360-2CE2-4472-9252-707E0CB0888A@inria.fr> <01ae01cf0d24$e9d492c0$bd7db840$@it.uc3m.es> <1AB135AC-8BE6-4653-945A-15FC226F162E@inria.fr> In-Reply-To: <1AB135AC-8BE6-4653-945A-15FC226F162E@inria.fr> Date: Mon, 13 Jan 2014 16:55:02 +0100 Message-ID: <00cd01cf1077$d1e28630$75a79290$@it.uc3m.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CE_01CF1080.33B0B230" X-Mailer: Microsoft Outlook 14.0 Content-Language: es Thread-Index: AQHaNKwdfSYJOwgcxKKswh9HGthMUQJ23Yl1AfEP2nKaSUIHIA== X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20430.000 Cc: secdir@ietf.org, 'IESG' , draft-ietf-savi-send@tools.ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-savi-send-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 16:12:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00CE_01CF1080.33B0B230 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Vincent, I think there is a single issue left to solve in this email, which I = comment in brown color. =20 =20 De: Vincent Roca [mailto:vincent.roca@inria.fr]=20 Enviado el: viernes, 10 de enero de 2014 15:49 Para: Alberto Garc=EDa CC: Vincent Roca; 'IESG'; draft-ietf-savi-send@tools.ietf.org; secdir@ietf.org Asunto: Re: Secdir review of draft-ietf-savi-send-10 =20 Hello Alberto, =20 This i-d contains a detailed Security Consideration sections which is = great. However I have a few questions and comments. =20 1/ Section 5 says: "The interaction in a mixed scenario comprising SEND and non-SEND devices should be addressed in other document." What happens if an attacker behaves as a non-SEND host? Is it sufficient to escape SEND SAVI and launch an attack? This is not said. =20 Yes, this is not said and it should. I have modified the first paragraph = to say: =20 SEND SAVI operates only with validated SEND messages. Note that IPv6 packets generated by non-SEND nodes will be discarded by the first SEND SAVI device receiving it. Therefore, attackers cannot obtain any benefit by not using SEND. In order to perform address validation in a mixed scenario comprising SEND and non-SEND devices, a different solution is required, which should be addressed in other document. =20 VR: perfect. =20 2/ Section 5.2 says: "The recommended minimum is the memory needed to store 4 bindings associated to the port." If there are several hosts behind this port (e.g., several hosts behind = a hub attached to this switch, or several virtual machines), this value of 4 = may not be sufficient. I agree that having per-port buffers is fine, but = specifying a value is risky. =20 This text is also included in RFC 6620 (FCFS SAVI) Note that the value specified is a *minimum*, which means that - Implementors of SEND SAVI devices could raise this number, of course, probably depending on the memory they have. - This is the minimum in case malicious nodes are connected to = other ports trying to exhaust memory; i.e., there will always be at least 4 bindings, which should be a minimum number of addresses for one basic = host (link local address + global unicast address=85). Even if this is the = minimum being set, when an attack is not occurring more than 4 bindings could be available to certain ports, assuming that the device can store more = bindings than 4*number_of_ports. =20 In order to stress the first idea, I have rephrased the paragraph as follows: =20 The recommended minimum is the memory needed to store four bindings associated to the port, although it should be raised if the ratio between the maximum number of bindings allowed in the device and the number of ports is high. =20 VR: I understand that this is a minimum, but don't you think that = because a value is mentioned, there is a risk? In the new text, you're saying: "it should be raised if...". First of = all, it's better to use RFC2119 keywords. Then why do you say "should"? I'd rather say "MUST" since there is no choice = in that case. =20 ALB: I think that if we include a MUST, then we should be much more = precise on how this minimum is computed as a function of the maximum number of bindings and the number of ports. And I don=92t think this must be = specified.=20 I agree that use of RFC2119 keywords MUST be improved, so I have = rephrased again as: =20 In addition, it is also RECOMMENDED that a SEND SAVI device reserves a minimum amount of memory for each available port (in the case where the port is used as part of the L2 anchor). The REQUIRED minimum is the memory needed to store four bindings associated to the port, although it SHOULD be raised if the ratio between the maximum number of bindings allowed in the device and the number of ports is high. =20 Do you think this is acceptable? =20 Regards, Alberto By the way, you raise an interesting issue that has not been considered = in the previous versions of the document: the virtual machine case. In = order to address this, at least cursorily, I have included the following text in section 2.4 =91Special Cases=92: =20 Virtual switches: A hypervisor or a host Operating System may perform bridging functions between virtual hosts running on the same machine. The hypervisor or host OS may in turn connect to a SEND SAVI system. This scenario is depicted in the next figure, with two virtual machines VM1 and VM2 connected through a virtual switch VS1 to SEND SAVI device SEND-SAVI1. The attachment points of VS1 to VM1 and VM2 are configured as Validating. =20 =20 Host1 +----------------+ | +---+ +---+ | | |VM1| |VM2| | | +---+ +---+ | | | | | | +-1-----2--+ | | | VS1 | | | +--3-------+ | | | | +----|-----------+ | | +--1-----2--+ | SEND- | | SAVI1 | +--3---4----+ | | =20 =20 =20 In order to provide proper security against replay attacks, it is recommended to perform SEND SAVI filtering as close to untrusted hosts as possible (see Section 3.4 and Section 5.1). In this scenario, this objective can be achieved by enabling SEND SAVI validation in VS1. Ideally, VS1 could be integrated into the SEND SAVI protection perimeter, if the hypervisor or host OS at Host1 can be trusted (even though VM1 and VM2 could not be trusted). To do so, both the attachment to SEND-SAVI1 at VS1, and port 1 at SEND-SAVI1, are configured as Trusted. =20 If the administrator of the network does not trust on VS1, port 1 of SEND-SAVI1 is configured as Validating, so that every address being used at Host1 is validated at SEND-SAVI1 by SEND SAVI. The attachment point to the physical network at VS1 should be configured as Trusted, if the host administrator knows that it is connected to a SEND SAVI device; in this case, VS1 relies on the infrastructure comprised by the physical SEND SAVI devices, but not the other way. Packets egressing from VM1 are validated twice, first at VS1, and then at SEND-SAVI1; packets going in the reverse direction (from an external host to VM1) are validated once, when they first reach a SEND SAVI device. If the administrator of VS1 does not trust on the physical switch to which it attaches, it can configure the attachment to SEND-SAVI1 as Validating. In the figure above, this means that a packet going from another host to VM1 would be validated twice, once when entering the SEND SAVI perimeter formed by the physical devices, and the other when entering at VS1. =20 =20 =20 =20 3/ Section 5.2 is a bit confusing and I'm wondering if it could not be simplified. =20 Just to provide some background about this section: it is almost the = same text as section 4.1 of RFC 6620, since the DoS problems are mostly the = same (except for the last paragraph of the section, which insists in the = extra cost of cryptographic operations due to the use of SEND. This being said, I do not pretend that RFC6620 text could not be = improved. =20 VR: It makes sense to borrow text from previous documents, but improving = it makes sense too. Anyway, the only think that matters is the result. =20 =20 Basically, it says: - in case of memory shortage, it is RECOMMENDED to "delete the entries = with a higher Creation time". BTW, what do you mean by "higher creation time"? The oldest entries = el? =20 =20 No, the newer ones, as the next sentence clarifies: =91This implies that = older entries are preserved and newer entries overwrite each other.=20 =20 VR: The new text is much better and avoids any misunderstanding. =20 - it is RECOMMENDED to reserve some memory for each port in order to = isolate the effects to the attacker's port; - one MUST limit the maximum amount of memory used to store data packets in order to keep memory for other tasks; - one SHOULD rate limit packets which may trigger SEND SAVI events, = since it requires costly crypto operations. BTW, why do you say "which may trigger" instead of "which trigger"? I remove =91may=92. Your summary is correct. =20 =20 Third paragraph is strange. =20 According to your comments, I have changed the text to (I explain later = the changes): The SEND SAVI device may store data packets while the address is being verified, for example, when a DAD_NSOL was lost before arriving to the SEND SAVI device to which the host attaches, and the host sends data packets, these data packets may be stored until the SEND SAVI device verifies the binding by means of a NUD packet exchange. In this case, the memory for data packet storage may also be a target of DoS attacks. A SEND SAVI device MUST limit the amount of memory used to store data packets, allowing the other functions (such as being able to store new bindings) to have available memory even in the case of an attacks such those described above. =20 =20 =20 =20 I read: "As the SEND SAVI device may store data packets while the address is being verified..." If the incoming packet rate is higher than the packet verification rate, sure there will be problems. Is it what the authors mean? I don't see any = good solution except rate limiting the incoming packet flow. =20 I think it was not clear enough the case to which we were referring. = That=92s why I changed the first sentence. What I want to note is that this is a particular case, but not =91normal operation=92 of the SAVI device, because in most cases (well-behaved = hosts), DAD_NSOL is going to be issued first, and the host will not send packets until the address is valid (and so the state at the SEND SAVI devices). However, we do not want malicious nodes to exploit the fact that memory (especially for other more relevant uses, such as storing bindings) = could be exhausted in this way. =20 VR: agreed. =20 Later: "The effects of such attacks may be limited to the lack of capacity to store new data packets." Does it mean that setting an upper limit to the amount of = memory devoted to store data packets is a way to mitigate the attack (last sentence), or does it mean that the attack will lead packets to be dropped = (following sentence)? =20 I agree that the two sentences starting by the one you copy here were = hard to understand. As you see in the new version of the text (above), I have removed them. What I think is the most relevant problem is that using = memory for this could drain resources for other functions, and this is stated = in the last sentence. =20 VR: okay. =20 And when it is said that: "A SEND SAVI device MUST limit the amount of memory used to store data packets, allowing the other functions to have available memory even in the case of an attacks..." What do you mean by "other functions"? SEND SAVI functions? Others? I have clarified this in the text =20 5/ Section 5.4 says that "a SEND SAVI MUST NOT log binding anchor information except [if there's a good reason for that]". And later that "information about the majority of hosts that never spoof SHOULD NOT be logged." =20 The intention is fine, but if I understand correctly, SAVI requires to identify a host's legitimate IP source addresses (RFC 7039). It means that this information will be logged any away as SAVI needs it (if I understand correctly). Or may be by "logging" you mean "long term logging" but in that case = this is not clear. Or is there something else I've missed? =20 You are right. I have changed this to =20 A SEND SAVI device MUST delete binding anchor information as soon as possible (i.e., as soon as the state for a given address is back to NO_BIND), except where there is an identified reason why that information is likely to be involved in detection, prevention or tracing of actual source address spoofing. Information about the majority of hosts that never spoof SHOULD NOT be logged. =20 =20 VR: okay =20 Typos: =20 ** s/reply/replay in: "There are two different cases to analyze when considering SEND SAVI reply attacks:" =20 ** s/In this two cases/In these two cases/ =20 ** s/messages which does not result in changes/messages which do not = result in changes/ =20 ** s/in the case of an attacks such those described above/in the case of = an attack like the one described above/ =20 Corrected! Thanks again for your comments =20 You're welcome. Cheers, =20 Vincent ------=_NextPart_000_00CE_01CF1080.33B0B230 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Vincent,

I think there is a single issue left to solve in this email, which I = comment in brown color.

 

 

De: = Vincent Roca [mailto:vincent.roca@inria.fr]
Enviado el: = viernes, 10 de enero de 2014 15:49
Para: Alberto = Garc=EDa
CC: Vincent Roca; 'IESG'; = draft-ietf-savi-send@tools.ietf.org; secdir@ietf.org
Asunto: = Re: Secdir review of = draft-ietf-savi-send-10

 

Hello = Alberto,

 

<= div>

This i-d contains a detailed = Security Consideration sections which is = great.

However I have a few questions and = comments.

 

1/ Section 5 = says:

   "The interaction = in a mixed scenario comprising SEND and = non-SEND

   devices should be = addressed in other = document."

What happens if an attacker behaves = as a non-SEND host? Is it = sufficient

to escape SEND SAVI and launch an = attack? This is not said.

 

Yes, this is not said and it should. I have modified the first = paragraph to say:

 

   SEND SAVI operates only with validated = SEND messages.  Note that IPv6

   packets generated by non-SEND nodes = will be discarded by the first

   SEND SAVI device receiving it.  = Therefore, attackers cannot obtain

   any benefit by not using SEND.  In = order to perform address

   validation in a mixed scenario = comprising SEND and non-SEND devices,

   a different solution is required, which = should be addressed in other

    = document.

 

VR: perfect.

 



<= div>

2/ Section 5.2 = says:

   "The recommended = minimum

   is the memory needed = to store 4 bindings associated to the = port."

If there are several hosts behind = this port (e.g., several hosts behind a = hub

attached to this switch, or several = virtual machines), this value of 4 may = not

be sufficient. I agree that having = per-port buffers is fine, but specifying = a

value is = risky.

 

This text is = also included in RFC 6620 (FCFS SAVI)

Note that the = value specified is a *minimum*, which means = that

-     &nb= sp;  Implementors = of SEND SAVI devices could raise this number, of course, probably = depending on the memory they have.

-     &nb= sp;  This is the = minimum in case malicious nodes are connected to other ports trying to = exhaust memory; i.e., there will always be at least 4 bindings, which = should be a minimum number of addresses for one basic host (link local = address + global unicast address…). Even if this is the minimum = being set, when an attack is not occurring more than 4 bindings could be = available to certain ports, assuming that the device can store more = bindings than 4*number_of_ports.

 <= o:p>

In order to = stress the first idea, I have rephrased the paragraph as = follows:

 <= o:p>

   The recommended =
minimum
   is the memory needed to store four =
bindings associated to the port,
   although it should be =
raised if the ratio between the maximum =
number
   of bindings allowed in the device =
and the number of ports is =
high.

 

VR: I understand that this is a minimum, but don't you = think that because a value is mentioned, there is a = risk?

In the new text, = you're saying: "it should be raised if...". First of all, it's = better to use RFC2119 keywords. Then

why do you say "should"? I'd rather say = "MUST" since there is no choice in that = case.

 

ALB: I think that if we include a MUST, then = we should be much more precise on how this minimum is computed as a = function of the maximum number of bindings and the number of ports. And = I don’t think this must be specified.

I agree that use of RFC2119 keywords MUST be = improved, so I have rephrased again as:

 

=A0=A0 In addition, it is also RECOMMENDED that a = SEND SAVI device reserves

=A0=A0 a minimum amount of memory for each = available port (in the case where

=A0=A0 the port is used as part of the L2 = anchor).=A0 The REQUIRED minimum is

=A0=A0 the memory needed to store four bindings = associated to the port,

=A0=A0 although it SHOULD be raised if the ratio = between the maximum number

=A0=A0 of bindings allowed in the device and the = number of ports is high.

 

Do you think this is = acceptable?

 

Regards,

Alberto



<= div>

By the way, = you raise an interesting issue that has not been considered in the = previous versions of the document: the virtual machine case. In order to = address this, at least cursorily, I have included the following text in = section 2.4 ‘Special = Cases’:

 <= o:p>

   Virtual switches: A hypervisor or a host =
Operating System may perform
   bridging functions between virtual =
hosts running on the same machine.
   The hypervisor or host OS may in =
turn connect to a SEND SAVI system.
   This scenario is depicted in the =
next figure, with two virtual
   machines VM1 and VM2 connected =
through a virtual switch VS1 to SEND
   SAVI device SEND-SAVI1.  The =
attachment points of VS1 to VM1 and VM2
   are configured as =
Validating.
 
 
       =
Host1
       =
+----------------+
       | =
+---+   +---+  |
       | =
|VM1|   |VM2|  |
       | =
+---+   +---+  |
       =
|   |     |      =
|
       | =
+-1-----2--+   |
       | =
|   VS1    |   =
|
       | =
+--3-------+   |
       =
|    =
|           =
|
       =
+----|-----------+
        &=
nbsp;   |
        &=
nbsp;   |
         =
+--1-----2--+
         =
|   SEND-   |
         =
|   SAVI1   |
         =
+--3---4----+
        &=
nbsp;   |   |
 
 
 
   In order to provide proper security =
against replay attacks, it is
   recommended to perform SEND SAVI =
filtering as close to untrusted
   hosts as possible (see Section 3.4 =
and Section 5.1).  In this
   scenario, this objective can be =
achieved by enabling SEND SAVI
   validation in VS1.  Ideally, =
VS1 could be integrated into the SEND
   SAVI protection perimeter, if the =
hypervisor or host OS at Host1 can
   be trusted (even though VM1 and VM2 =
could not be trusted).  To do so,
   both the attachment to SEND-SAVI1 =
at VS1, and port 1 at SEND-SAVI1,
   are configured as =
Trusted.
 
   If the administrator of the network =
does not trust on VS1, port 1 of
   SEND-SAVI1 is configured as =
Validating, so that every address being
   used at Host1 is validated at =
SEND-SAVI1 by SEND SAVI.  The
   attachment point to the physical =
network at VS1 should be configured
   as Trusted, if the host =
administrator knows that it is connected to =
a
   SEND SAVI device; in =
this case, VS1 relies on the infrastructure
   comprised by the physical SEND SAVI =
devices, but not the other way.
   Packets egressing from VM1 are =
validated twice, first at VS1, and
   then at SEND-SAVI1; packets going =
in the reverse direction (from an
   external host to VM1) are validated =
once, when they first reach a
   SEND SAVI device.  If the =
administrator of VS1 does not trust on the
   physical switch to which it =
attaches, it can configure the attachment
   to SEND-SAVI1 as Validating.  =
In the figure above, this means that a
   packet going from another host to =
VM1 would be validated twice, once
   when entering the SEND SAVI =
perimeter formed by the physical =
devices,
   and the other when entering at =
VS1.

 

 

 

 

3/ Section 5.2 is a bit confusing = and I'm wondering if it could not be = simplified.

 

Just to provide some background about this section: it is almost the = same text as section 4.1 of RFC 6620, since the DoS problems are mostly = the same (except for the last paragraph of the section, which insists in = the extra cost of cryptographic operations due to the use of = SEND.

This being said, I do not pretend that RFC6620 text could not be = improved.

 

VR: It makes sense to borrow text from previous = documents, but improving it makes sense too.

Anyway, the only think that matters is the = result.

 

 

<= div>

Basically, it = says:

- in case of memory shortage, it is = RECOMMENDED to "delete the entries = with

  a higher Creation = time".

  BTW, what do you mean by = "higher creation time"? The oldest entries el?

 
 
No, the newer ones, as the next sentence clarifies: ‘This =
implies that older =
entries are preserved and newer entries overwrite each other. =

 

VR: The new text is much better and avoids any = misunderstanding.

 



<= div>

- it is RECOMMENDED to = reserve some memory for each port in order to = isolate

  the effects to the = attacker's port;

- one MUST limit the maximum amount = of memory used to store data = packets

  in order to keep memory for = other tasks;

- one SHOULD rate limit packets = which may trigger SEND SAVI events, = since

  it requires costly crypto = operations.

  BTW, why do you say = "which may trigger" instead of "which = trigger"?

I remove = ‘may’.

Your = summary is correct.

 

 

Third paragraph is = strange.

 

According to your comments, I have changed the text to (I explain = later the changes):

   The SEND SAVI device may store data =
packets while the address is
   being verified, for =
example, when a DAD_NSOL was lost before =
arriving
   to the SEND SAVI device to which =
the host attaches, and the host
   sends data packets, =
these data packets may be stored until the =
SEND
   SAVI device verifies the binding by =
means of a NUD packet exchange.
   In this case, the =
memory for data packet storage may also be a =
target
   of DoS attacks.  A SEND SAVI =
device MUST limit the amount of memory
   used to store data =
packets, allowing the other functions (such =
as
   being able to store new bindings) =
to have available memory even in
   the case of an attacks =
such those described above.
 

 

 

 

I read:

   "As the SEND SAVI = device may store data packets while the address = is

   being = verified..."

If the incoming packet rate is = higher than the packet verification rate, = sure

there will be problems. Is it what = the authors mean? I don't see any = good

solution except rate limiting the = incoming packet flow.

 

I think it was not clear enough the case to which we were referring. = That’s why I changed the first = sentence.

What I want to note is that this is a particular case, but not = ‘normal operation’ of the SAVI device, because in most cases = (well-behaved hosts), DAD_NSOL is going to be issued first, and the host = will not send packets until the address is valid (and so the state at = the SEND SAVI devices).

However, we do not want malicious nodes to exploit the fact that = memory (especially for other more relevant uses, such as storing = bindings) could be exhausted in this = way.

 

VR: agreed.

 



<= div>

Later:

   "The effects of = such attacks may be limited = to

   the lack of capacity to store new data = packets."

          Does it mean that = setting an upper limit to the amount of memory = devoted

to store data packets is a way to = mitigate the attack (last = sentence),

or does it mean that the attack = will lead packets to be dropped = (following

sentence)?

 

I agree that the two sentences starting by the one you copy here were = hard to understand. As you see in the new version of the text (above), I = have removed them. What I think is the most relevant problem is that = using memory for this could drain resources for other functions, and = this is stated in the last = sentence.

 

VR: okay.

 



<= div>

And when it is said = that:

   "A SEND SAVI = device MUST limit the amount = of

   memory used to store data packets, allowing = the other functions to

   have available memory = even in the case of an = attacks..."

What do you mean by "other = functions"? SEND SAVI functions? = Others?

I have = clarified this in the text

 

5/ Section 5.4 says that "a = SEND SAVI MUST NOT log binding anchor = information

except [if there's a good reason = for that]". And later that "information = about

the majority of hosts that never = spoof SHOULD NOT be = logged."

 

The intention is fine, but if I = understand correctly, SAVI requires to = identify

a host's legitimate IP source = addresses (RFC 7039). It means that this = information

will be logged any away as SAVI = needs it (if I understand = correctly).

Or may be by "logging" = you mean "long term logging" but in that case this = is

not clear. Or is there something else I've = missed?

 

You are right. I have changed this = to

 

   A SEND SAVI device MUST delete =
binding anchor information as soon as
   possible (i.e., as =
soon as the state for a given address is back =
to
   NO_BIND), except where there is an =
identified reason why that
   information is likely =
to be involved in detection, prevention =
or
   tracing of actual source address =
spoofing.  Information about the
   majority of hosts that =
never spoof SHOULD NOT be =
logged.

 

 

VR: okay

 



<= div>

Typos:

 

** s/reply/replay =  in:

   "There are two = different cases to analyze when considering SEND = SAVI

   reply = attacks:"

 

** s/In this two cases/In these two = cases/

 

** s/messages which does not result = in changes/messages which do not result in = changes/

 

** s/in the case of an attacks such = those described above/in the case of an attack like the one described = above/

 

Corrected!

Thanks again for your = comments

 

You're welcome.

Cheers,

 

  =  Vincent

------=_NextPart_000_00CE_01CF1080.33B0B230-- From vincent.roca@inria.fr Mon Jan 13 09:08:55 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E29561AE165; Mon, 13 Jan 2014 09:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.787 X-Spam-Level: X-Spam-Status: No, score=-6.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBNjbl3dE4Zc; Mon, 13 Jan 2014 09:08:49 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by ietfa.amsl.com (Postfix) with ESMTP id 95FA81ADFA3; Mon, 13 Jan 2014 09:08:48 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,653,1384297200"; d="scan'208,217";a="53043220" Received: from demeter.inrialpes.fr ([194.199.24.102]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 13 Jan 2014 18:08:36 +0100 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-29--991144238 From: Vincent Roca In-Reply-To: <00cd01cf1077$d1e28630$75a79290$@it.uc3m.es> Date: Mon, 13 Jan 2014 18:08:35 +0100 Message-Id: <1F88FB09-4603-49C0-B859-E65B61BF084D@inria.fr> References: <206CF360-2CE2-4472-9252-707E0CB0888A@inria.fr> <01ae01cf0d24$e9d492c0$bd7db840$@it.uc3m.es> <1AB135AC-8BE6-4653-945A-15FC226F162E@inria.fr> <00cd01cf1077$d1e28630$75a79290$@it.uc3m.es> To: =?iso-8859-1?Q?Alberto_Garc=EDa?= X-Mailer: Apple Mail (2.1085) Cc: secdir@ietf.org, 'IESG' , draft-ietf-savi-send@tools.ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-savi-send-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 17:08:55 -0000 --Apple-Mail-29--991144238 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear Alberto, I'm okay with the new sentence. Thanks, Vincent Le 13 janv. 2014 =E0 16:55, Alberto Garc=EDa a =E9crit : > Hi Vincent, > I think there is a single issue left to solve in this email, which I = comment in brown color. > =20 > =20 > De: Vincent Roca [mailto:vincent.roca@inria.fr]=20 > Enviado el: viernes, 10 de enero de 2014 15:49 > Para: Alberto Garc=EDa > CC: Vincent Roca; 'IESG'; draft-ietf-savi-send@tools.ietf.org; = secdir@ietf.org > Asunto: Re: Secdir review of draft-ietf-savi-send-10 > =20 > Hello Alberto, > =20 > This i-d contains a detailed Security Consideration sections which is = great. > However I have a few questions and comments. > =20 > 1/ Section 5 says: > "The interaction in a mixed scenario comprising SEND and non-SEND > devices should be addressed in other document." > What happens if an attacker behaves as a non-SEND host? Is it = sufficient > to escape SEND SAVI and launch an attack? This is not said. > =20 > Yes, this is not said and it should. I have modified the first = paragraph to say: > =20 > SEND SAVI operates only with validated SEND messages. Note that = IPv6 > packets generated by non-SEND nodes will be discarded by the first > SEND SAVI device receiving it. Therefore, attackers cannot obtain > any benefit by not using SEND. In order to perform address > validation in a mixed scenario comprising SEND and non-SEND = devices, > a different solution is required, which should be addressed in = other > document. > =20 > VR: perfect. > =20 >=20 >=20 > 2/ Section 5.2 says: > "The recommended minimum > is the memory needed to store 4 bindings associated to the port." > If there are several hosts behind this port (e.g., several hosts = behind a hub > attached to this switch, or several virtual machines), this value of 4 = may not > be sufficient. I agree that having per-port buffers is fine, but = specifying a > value is risky. > =20 > This text is also included in RFC 6620 (FCFS SAVI) > Note that the value specified is a *minimum*, which means that > - Implementors of SEND SAVI devices could raise this number, of = course, probably depending on the memory they have. > - This is the minimum in case malicious nodes are connected to = other ports trying to exhaust memory; i.e., there will always be at = least 4 bindings, which should be a minimum number of addresses for one = basic host (link local address + global unicast address=85). Even if = this is the minimum being set, when an attack is not occurring more than = 4 bindings could be available to certain ports, assuming that the device = can store more bindings than 4*number_of_ports. > =20 > In order to stress the first idea, I have rephrased the paragraph as = follows: > =20 > The recommended minimum > is the memory needed to store four bindings associated to the port, > although it should be raised if the ratio between the maximum = number > of bindings allowed in the device and the number of ports is high. > =20 > VR: I understand that this is a minimum, but don't you think that = because a value is mentioned, there is a risk? > In the new text, you're saying: "it should be raised if...". First of = all, it's better to use RFC2119 keywords. Then > why do you say "should"? I'd rather say "MUST" since there is no = choice in that case. > =20 > ALB: I think that if we include a MUST, then we should be much more = precise on how this minimum is computed as a function of the maximum = number of bindings and the number of ports. And I don=92t think this = must be specified. > I agree that use of RFC2119 keywords MUST be improved, so I have = rephrased again as: > =20 > In addition, it is also RECOMMENDED that a SEND SAVI device = reserves > a minimum amount of memory for each available port (in the case = where > the port is used as part of the L2 anchor). The REQUIRED minimum = is > the memory needed to store four bindings associated to the port, > although it SHOULD be raised if the ratio between the maximum = number > of bindings allowed in the device and the number of ports is high. > =20 > Do you think this is acceptable? > =20 > Regards, > Alberto >=20 >=20 > By the way, you raise an interesting issue that has not been = considered in the previous versions of the document: the virtual machine = case. In order to address this, at least cursorily, I have included the = following text in section 2.4 =91Special Cases=92: > =20 > Virtual switches: A hypervisor or a host Operating System may = perform > bridging functions between virtual hosts running on the same = machine. > The hypervisor or host OS may in turn connect to a SEND SAVI = system. > This scenario is depicted in the next figure, with two virtual > machines VM1 and VM2 connected through a virtual switch VS1 to SEND > SAVI device SEND-SAVI1. The attachment points of VS1 to VM1 and = VM2 > are configured as Validating. > =20 > =20 > Host1 > +----------------+ > | +---+ +---+ | > | |VM1| |VM2| | > | +---+ +---+ | > | | | | > | +-1-----2--+ | > | | VS1 | | > | +--3-------+ | > | | | > +----|-----------+ > | > | > +--1-----2--+ > | SEND- | > | SAVI1 | > +--3---4----+ > | | > =20 > =20 > =20 > In order to provide proper security against replay attacks, it is > recommended to perform SEND SAVI filtering as close to untrusted > hosts as possible (see Section 3.4 and Section 5.1). In this > scenario, this objective can be achieved by enabling SEND SAVI > validation in VS1. Ideally, VS1 could be integrated into the SEND > SAVI protection perimeter, if the hypervisor or host OS at Host1 = can > be trusted (even though VM1 and VM2 could not be trusted). To do = so, > both the attachment to SEND-SAVI1 at VS1, and port 1 at SEND-SAVI1, > are configured as Trusted. > =20 > If the administrator of the network does not trust on VS1, port 1 = of > SEND-SAVI1 is configured as Validating, so that every address being > used at Host1 is validated at SEND-SAVI1 by SEND SAVI. The > attachment point to the physical network at VS1 should be = configured > as Trusted, if the host administrator knows that it is connected to = a > SEND SAVI device; in this case, VS1 relies on the infrastructure > comprised by the physical SEND SAVI devices, but not the other way. > Packets egressing from VM1 are validated twice, first at VS1, and > then at SEND-SAVI1; packets going in the reverse direction (from an > external host to VM1) are validated once, when they first reach a > SEND SAVI device. If the administrator of VS1 does not trust on = the > physical switch to which it attaches, it can configure the = attachment > to SEND-SAVI1 as Validating. In the figure above, this means that = a > packet going from another host to VM1 would be validated twice, = once > when entering the SEND SAVI perimeter formed by the physical = devices, > and the other when entering at VS1. > =20 > =20 > =20 > =20 > 3/ Section 5.2 is a bit confusing and I'm wondering if it could not be = simplified. > =20 > Just to provide some background about this section: it is almost the = same text as section 4.1 of RFC 6620, since the DoS problems are mostly = the same (except for the last paragraph of the section, which insists in = the extra cost of cryptographic operations due to the use of SEND. > This being said, I do not pretend that RFC6620 text could not be = improved. > =20 > VR: It makes sense to borrow text from previous documents, but = improving it makes sense too. > Anyway, the only think that matters is the result. > =20 > =20 > Basically, it says: > - in case of memory shortage, it is RECOMMENDED to "delete the entries = with > a higher Creation time". > BTW, what do you mean by "higher creation time"? The oldest entries = el? > =20 > =20 > No, the newer ones, as the next sentence clarifies: =91This implies = that older entries are preserved and newer entries overwrite each other.=20= > =20 > VR: The new text is much better and avoids any misunderstanding. > =20 >=20 >=20 > - it is RECOMMENDED to reserve some memory for each port in order to = isolate > the effects to the attacker's port; > - one MUST limit the maximum amount of memory used to store data = packets > in order to keep memory for other tasks; > - one SHOULD rate limit packets which may trigger SEND SAVI events, = since > it requires costly crypto operations. > BTW, why do you say "which may trigger" instead of "which trigger"? > I remove =91may=92. > Your summary is correct. > =20 > =20 > Third paragraph is strange. > =20 > According to your comments, I have changed the text to (I explain = later the changes): > The SEND SAVI device may store data packets while the address is > being verified, for example, when a DAD_NSOL was lost before = arriving > to the SEND SAVI device to which the host attaches, and the host > sends data packets, these data packets may be stored until the SEND > SAVI device verifies the binding by means of a NUD packet exchange. > In this case, the memory for data packet storage may also be a = target > of DoS attacks. A SEND SAVI device MUST limit the amount of memory > used to store data packets, allowing the other functions (such as > being able to store new bindings) to have available memory even in > the case of an attacks such those described above. > =20 > =20 > =20 > =20 > I read: > "As the SEND SAVI device may store data packets while the address = is > being verified..." > If the incoming packet rate is higher than the packet verification = rate, sure > there will be problems. Is it what the authors mean? I don't see any = good > solution except rate limiting the incoming packet flow. > =20 > I think it was not clear enough the case to which we were referring. = That=92s why I changed the first sentence. > What I want to note is that this is a particular case, but not =91normal= operation=92 of the SAVI device, because in most cases (well-behaved = hosts), DAD_NSOL is going to be issued first, and the host will not send = packets until the address is valid (and so the state at the SEND SAVI = devices). > However, we do not want malicious nodes to exploit the fact that = memory (especially for other more relevant uses, such as storing = bindings) could be exhausted in this way. > =20 > VR: agreed. > =20 >=20 >=20 > Later: > "The effects of such attacks may be limited to > the lack of capacity to store new data packets." > Does it mean that setting an upper limit to the amount of = memory devoted > to store data packets is a way to mitigate the attack (last sentence), > or does it mean that the attack will lead packets to be dropped = (following > sentence)? > =20 > I agree that the two sentences starting by the one you copy here were = hard to understand. As you see in the new version of the text (above), I = have removed them. What I think is the most relevant problem is that = using memory for this could drain resources for other functions, and = this is stated in the last sentence. > =20 > VR: okay. > =20 >=20 >=20 > And when it is said that: > "A SEND SAVI device MUST limit the amount of > memory used to store data packets, allowing the other functions to > have available memory even in the case of an attacks..." > What do you mean by "other functions"? SEND SAVI functions? Others? > I have clarified this in the text > =20 > 5/ Section 5.4 says that "a SEND SAVI MUST NOT log binding anchor = information > except [if there's a good reason for that]". And later that = "information about > the majority of hosts that never spoof SHOULD NOT be logged." > =20 > The intention is fine, but if I understand correctly, SAVI requires to = identify > a host's legitimate IP source addresses (RFC 7039). It means that this = information > will be logged any away as SAVI needs it (if I understand correctly). > Or may be by "logging" you mean "long term logging" but in that case = this is > not clear. Or is there something else I've missed? > =20 > You are right. I have changed this to > =20 > A SEND SAVI device MUST delete binding anchor information as soon = as > possible (i.e., as soon as the state for a given address is back to > NO_BIND), except where there is an identified reason why that > information is likely to be involved in detection, prevention or > tracing of actual source address spoofing. Information about the > majority of hosts that never spoof SHOULD NOT be logged. > =20 > =20 > VR: okay > =20 >=20 >=20 > Typos: > =20 > ** s/reply/replay in: > "There are two different cases to analyze when considering SEND = SAVI > reply attacks:" > =20 > ** s/In this two cases/In these two cases/ > =20 > ** s/messages which does not result in changes/messages which do not = result in changes/ > =20 > ** s/in the case of an attacks such those described above/in the case = of an attack like the one described above/ > =20 > Corrected! > Thanks again for your comments > =20 > You're welcome. > Cheers, > =20 > Vincent --Apple-Mail-29--991144238 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Dear Alberto,

I'm okay with the = new sentence.
Thanks,

  = Vincent

Hi Vincent,
I think = there is a single issue left to solve in this email, which I comment in = brown color.
 
 Vincent = Roca [mailto:vincent.roca@inria.fr] 
Enviado el: viernes, 10 de enero de = 2014 15:49
Para: Alberto = Garc=EDa
CC: Vincent Roca; 'IESG';  secdir@ietf.org
Asunto: Re: Secdir review of = draft-ietf-savi-send-10
 
Hello = Alberto,
This i-d contains a = detailed Security Consideration sections which is = great.
However I have a few questions and = comments.
 
1/ Section 5 = says:
   "The interaction in a = mixed scenario comprising SEND and = non-SEND
   devices should be = addressed in other = document."
What happens if an attacker = behaves as a non-SEND host? Is it = sufficient
to escape SEND SAVI and launch an = attack? This is not = said.
Yes, this is not said and it = should. I have modified the first paragraph to = say:
 
   SEND SAVI operates only with validated SEND = messages.  Note that IPv6
   packets generated by non-SEND nodes will be = discarded by the first
   SEND SAVI device receiving it.  Therefore, = attackers cannot obtain
   any benefit by not using SEND.  In order to = perform address
   = validation in a mixed scenario comprising SEND and non-SEND = devices,
   a = different solution is required, which should be addressed in = other
    = document.
 
VR: perfect.
 
2/ Section 5.2 = says:
   "The recommended = minimum
   is the memory needed = to store 4 bindings associated to the = port."
If there are several hosts behind = this port (e.g., several hosts behind a = hub
attached to this switch, or several virtual machines), = this value of 4 may = not
be sufficient. I agree that having per-port buffers is = fine, but specifying a
value is = risky.
 
This text is also included in RFC = 6620 (FCFS SAVI)
Note that the value specified is = a *minimum*, which means that
- - 
In order to stress the first idea, I have rephrased the = paragraph as follows:
   The recommended = minimum
   is the memory needed to store four =
bindings associated to the port,
   =
although it should be raised if the ratio between the maximum =
number
   of bindings allowed in the device and =
the number of ports is =
high.
 
VR: I understand that this is a minimum, but don't you = think that because a value is mentioned, there is a = risk?
In the new text, you're = saying: "it should be raised if...". First of all, it's better to = use RFC2119 keywords. Then
why do you say "should"? I'd rather say "MUST" since = there is no choice in that case.
 
ALB: I think that if = we include a MUST, then we should be much more precise on how this = minimum is computed as a function of the maximum number of bindings and = the number of ports. And I don=92t think this must be = specified.
I agree that use of RFC2119 keywords = MUST be improved, so I have rephrased again = as:
   In addition, it is also RECOMMENDED that a SEND = SAVI device reserves
   a minimum amount of memory for = each available port (in the case where
   the = port is used as part of the L2 anchor).  The REQUIRED minimum = is
   the memory needed to store four bindings = associated to the port,
   although it SHOULD be raised if = the ratio between the maximum number
   of = bindings allowed in the device and the number of ports is = high.
 
Regards,


By the way, you raise an = interesting issue that has not been considered in the previous versions = of the document: the virtual machine case. In order to address this, at = least cursorily, I have included the following text in section 2.4 = =91Special Cases=92:
   Virtual switches: A hypervisor or a = host Operating System may perform
   =
bridging functions between virtual hosts running on the same =
machine.
   The hypervisor or host =
OS may in turn connect to a SEND SAVI =
system.
   This scenario is =
depicted in the next figure, with two =
virtual
   machines VM1 and VM2 =
connected through a virtual switch VS1 to =
SEND
   SAVI device SEND-SAVI1.  The =
attachment points of VS1 to VM1 and VM2
   =
are configured as Validating.
 
       =
| +---+   +---+  |
       | =
+---+   +---+  |
       | =
+-1-----2--+   |
       =
|    =
|           =
|
       =
+----|-----------+
         =
+--1-----2--+
 
 
   =
In order to provide proper security against replay attacks, it =
is
   recommended to perform SEND SAVI =
filtering as close to untrusted
   =
hosts as possible (see Section 3.4 and Section 5.1).  In =
this
   scenario, this objective can be =
achieved by enabling SEND SAVI
   =
validation in VS1.  Ideally, VS1 could be integrated into the =
SEND
   SAVI protection perimeter, if the =
hypervisor or host OS at Host1 can
   =
be trusted (even though VM1 and VM2 could not be trusted).  To do =
so,
   both the attachment to SEND-SAVI1 at =
VS1, and port 1 at SEND-SAVI1,
   =
are configured as Trusted.
   If the administrator of =
the network does not trust on VS1, port 1 of
   =
SEND-SAVI1 is configured as Validating, so that every address =
being
   used at Host1 is =
validated at SEND-SAVI1 by SEND SAVI.  =
The
   attachment point to the physical =
network at VS1 should be configured
   =
as Trusted, if the host administrator knows that it is connected to =
a
   SEND SAVI device; in this case, VS1 =
relies on the infrastructure
   =
comprised by the physical SEND SAVI devices, but not the other =
way.
   Packets egressing from VM1 are =
validated twice, first at VS1, and
   =
then at SEND-SAVI1; packets going in the reverse direction (from =
an
   external host to VM1) are validated =
once, when they first reach a
   =
SEND SAVI device.  If the administrator of VS1 does not trust on =
the
   physical switch to which it attaches, =
it can configure the attachment
   =
to SEND-SAVI1 as Validating.  In the figure above, this means that =
a
   packet going from another host to VM1 =
would be validated twice, once
   =
when entering the SEND SAVI perimeter formed by the physical =
devices,
   and the other when entering at =
VS1.
3/ Section 5.2 is a bit confusing = and I'm wondering if it could not be = simplified.
Just to provide some background = about this section: it is almost the same text as section 4.1 of RFC = 6620, since the DoS problems are mostly the same (except for the last = paragraph of the section, which insists in the extra cost of = cryptographic operations due to the use of = SEND.
This being said, I do not pretend that RFC6620 text = could not be = improved.
 
VR: It makes sense to borrow text from previous = documents, but improving it makes sense = too.
Anyway, the only think = that matters is the result.
 
 
Basically, it = says:
- in case of memory shortage, it = is RECOMMENDED to "delete the entries = with
  a higher Creation = time".
  BTW, what do you mean by = "higher creation time"? The oldest entries 
No, the newer ones, as the next sentence clarifies: =
=91This  
VR: The new text is much better and avoids any = misunderstanding.
- it is RECOMMENDED to = reserve some memory for each port in order to = isolate
  the effects to the = attacker's port;
- one MUST limit the maximum = amount of memory used to store data = packets
  in order to keep memory for = other tasks;
- one SHOULD rate limit packets = which may trigger SEND SAVI events, = since
  it requires costly crypto = operations.
  BTW, why do you say "which = may trigger" instead of "which = trigger"?
Third paragraph is = strange.
According to your comments, I = have changed the text to (I explain later the = changes):
   The SEND SAVI device may store data =
packets while the address is
   =
being verified, for example, when a DAD_NSOL was lost before =
arriving
   to the SEND SAVI device to which the =
host attaches, and the host
   =
sends data packets, these data packets may be stored until the =
SEND
   SAVI device verifies the binding by =
means of a NUD packet exchange.
   =
In this case, the memory for data packet storage may also be a =
target
   of DoS attacks.  A SEND SAVI =
device MUST limit the amount of memory
   =
used to store data packets, allowing the other functions (such =
as
   being able to store new bindings) to =
have available memory even in
   =
the case of an attacks such those described =
above.
 
I read:
   "As the SEND SAVI = device may store data packets while the address = is
   being = verified..."
If the incoming packet rate is = higher than the packet verification rate, = sure
there will be problems. Is it what = the authors mean? I don't see any = good
solution except rate limiting the = incoming packet flow.
I think it was not clear enough = the case to which we were referring. That=92s why I changed the first = sentence.
What I want to note is that this = is a particular case, but not =91normal operation=92 of the SAVI device, = because in most cases (well-behaved hosts), DAD_NSOL is going to be = issued first, and the host will not send packets until the address is = valid (and so the state at the SEND SAVI = devices).
However, we do not want malicious = nodes to exploit the fact that memory (especially for other more = relevant uses, such as storing bindings) could be exhausted in this = way.
 
VR: agreed.
 
Later:
   "The effects of such = attacks may be limited = to
   the lack of capacity to store new data = packets."
          Does it mean = that setting an upper limit to the amount of memory = devoted
to store data packets is a way to = mitigate the attack (last = sentence),
or does it mean that the attack = will lead packets to be dropped = (following
sentence)?
I agree that the two sentences = starting by the one you copy here were hard to understand. As you see in = the new version of the text (above), I have removed them. What I think = is the most relevant problem is that using memory for this could drain = resources for other functions, and this is stated in the last = sentence.
 
VR: okay.
 
And when it is said = that:
   "A SEND SAVI device = MUST limit the amount = of
   memory used to store data packets, allowing = the other functions to
   have available memory = even in the case of an = attacks..."
What do you mean by "other = functions"? SEND SAVI functions? = Others?
 
5/ Section 5.4 says that "a SEND = SAVI MUST NOT log binding anchor = information
except [if there's a good reason = for that]". And later that "information = about
the majority of hosts that never = spoof SHOULD NOT be = logged."
 
The intention is fine, but if I = understand correctly, SAVI requires to = identify
a host's legitimate IP source = addresses (RFC 7039). It means that this = information
will be logged any away as SAVI = needs it (if I understand = correctly).
Or may be by "logging" you mean = "long term logging" but in that case this = is
not clear. Or is there something else I've = missed?
You are right. I have changed = this to
 
   =
A SEND SAVI device MUST delete binding anchor information as soon =
as
   possible (i.e., as soon as the state =
for a given address is back to
   =
NO_BIND), except where there is an identified reason why =
that
   information is likely to be involved in =
detection, prevention or
   tracing of actual =
source address spoofing.  Information about =
the
   majority of hosts that never spoof =
SHOULD NOT be =
logged.
 
 
VR: okay
 
Typos:
 
<= div>
** s/reply/replay =  in:
   "There are two = different cases to analyze when considering SEND = SAVI
   reply = attacks:"
 
** s/In this two cases/In these = two cases/
 
** s/messages which does not = result in changes/messages which do not result in = changes/
 
** s/in the case of an attacks = such those described above/in the case of an attack like the one = described above/
Corrected!
Thanks again for your = comments
 
You're welcome.
Cheers,
 
  =  Vincent
=
= --Apple-Mail-29--991144238-- From kivinen@iki.fi Thu Jan 16 01:52:22 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA90B1AE2FB for ; Thu, 16 Jan 2014 01:52:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.54 X-Spam-Level: X-Spam-Status: No, score=-0.54 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzkrch45sWVy for ; Thu, 16 Jan 2014 01:52:20 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id F237E1AE1F5 for ; Thu, 16 Jan 2014 01:52:19 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s0G9q4tD022609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 16 Jan 2014 11:52:04 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s0G9q44W025156; Thu, 16 Jan 2014 11:52:04 +0200 (EET) 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: <21207.43972.486035.307055@fireball.kivinen.iki.fi> Date: Thu, 16 Jan 2014 11:52:04 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jan 2014 09:52:22 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Dan Harkins is next in the rotation. For telechat 2014-01-23 Reviewer LC end Draft Alan DeKok T 2014-01-17 draft-ietf-mpls-multipath-use-03 Donald Eastlake T 2014-01-22 draft-ietf-netmod-system-mgmt-10 Shawn Emery T 2014-01-22 draft-ietf-isis-rfc6326bis-01 Hilarie Orman TR2013-11-18 draft-shore-icmp-aup-09 Vincent Roca T 2013-12-25 draft-ietf-6man-stable-privacy-addresses-16 Carl Wallace T 2014-01-06 draft-ietf-opsawg-lsn-deployment-04 Glen Zorn T 2014-01-17 draft-ietf-mpls-moving-iana-registries-03 For telechat 2014-02-06 Klaas Wierenga T 2014-01-31 draft-crocker-id-adoption-05 For telechat 2014-02-20 Dorothy Gellert T 2014-02-11 draft-housley-pkix-test-oids-00 Last calls and special requests: Derek Atkins 2014-01-16 draft-ietf-avtcore-clksrc-09 Rob Austein 2014-01-16 draft-ietf-mpls-tp-p2mp-framework-05 Dave Cridland E 2013-11-21 draft-dunbar-armd-arp-nd-scaling-practices-07 Tobias Gondrom 2014-01-23 draft-ietf-dane-registry-acronyms-03 Phillip Hallam-Baker 2014-01-27 draft-ietf-qresync-rfc5162bis-09 Steve Hanna E 2013-11-28 draft-ietf-pcp-nat64-prefix64-04 Steve Hanna 2014-01-28 draft-ietf-v6ops-nat64-experience-09 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-05 Julien Laganier E 2013-11-21 draft-ietf-websec-key-pinning-09 Julien Laganier 2013-12-11 draft-ietf-stox-core-09 Ben Laurie 2013-12-11 draft-ietf-stox-presence-06 Sandy Murphy 2013-12-17 draft-ietf-netmod-iana-timezones-03 Ondrej Sury 2013-12-27 draft-ietf-tls-applayerprotoneg-03 David Waltermire 2014-01-16 draft-ietf-pwe3-mpls-tp-cv-adv-04 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-09 Tom Yu 2014-01-17 draft-ietf-abfab-arch-10 Dacheng Zhang 2014-01-22 draft-ietf-ancp-mc-extensions-14 Glen Zorn 2013-08-30 draft-kaplan-insipid-session-id-03 -- kivinen@iki.fi From kwiereng@cisco.com Fri Jan 17 06:41:54 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0E91AE109; Fri, 17 Jan 2014 06:41:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uj2YQYRCxLVd; Fri, 17 Jan 2014 06:41:53 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 521901AE0E0; Fri, 17 Jan 2014 06:41:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3034; q=dns/txt; s=iport; t=1389969701; x=1391179301; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=+kaz49v1Y942gisi6QJl3G/xHHl7SOVeuX6JAHCp+Ac=; b=eTsT9Vr9HlOb/o3oAiPZT9D2byoyA6LABcPbt5s09nJ5cjMwiDkTB/mA MO0vc2ZejHV6huOHTM1d2kBe1ypaYlNozbuUIbhCbMPZusM4orEmLm80X vGaCQA8oRBHTemz/EaIGmeJaef3Em+acMyPRDK8S3am1A1NTmYNWP03gg 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAJFf2FKtJV2Z/2dsb2JhbABZgwuBDrwgFnSCLDo6FwE+QicEAYgWxUEXkiqBFASYIZIXgy2CKg X-IronPort-AV: E=Sophos;i="4.95,670,1384300800"; d="scan'208";a="13629145" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP; 17 Jan 2014 14:41:40 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0HEfePd022135 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Jan 2014 14:41:40 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.104]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Fri, 17 Jan 2014 08:41:40 -0600 From: "Klaas Wierenga (kwiereng)" To: "iesg@ietf.org" , "secdir@ietf.org" , "draft-crocker-id-adoption.all@tools.ietf.org" Thread-Topic: review of draft-crocker-id-adoption-05 Thread-Index: AQHPE5I77i18p0U40EKrtcrrUBqywg== Date: Fri, 17 Jan 2014 14:41:39 +0000 Message-ID: <8D28F665-CDF8-4FAA-869E-CA5EF6E673D2@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.101.245] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] review of draft-crocker-id-adoption-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 14:41:54 -0000 Hi Dave, Adrian, 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 draft describes the typical process for handling the working group dra= fts workflow. Let me start with saying that the draft is well written and a pleasure to r= ead. I believe the non-inclusion of any security considerations makes sense. Major issues ----------------- none Minor issues ----------------- General: - I think the title "Creating an IETF Working Group Draft" is a misnomer, a= t least it led me to believe that it would be a guide for creating a draft,= i.e. what template, what sections, how to use the tools etc. Something lik= e "the lifecycle of an IETF WG Draft" seems more appropriate. - Since this is a document that aims to document the actual way the WG draf= ts are handled I wonder whether you should mention that reality is not alwa= ys what is put on paper. For example whereas change control lies with the W= G rather then the author, in reality the author often has a strong influenc= e on what is being published. 1.1: - since in section 5.1 the individual submissions pops up, it may make sens= e to add a note here that says something like: "NOTE: in addition to WG dr= afts each individual can also independently submit a draft (that may at a l= ater stage either or not be adopted by a WG)" 2.1: - I usually (especially with relative newcomers) explicitly make the author= s of a submitted draft aware of the fact that they give up change control f= or their love baby to the WG. 2.2: - Also in other sections, but especially when it is about adopting a draft = and/or determining whether it fits in the charter there is often quite a bi= t of involvement from the AD's, I think you need to at least mention the ro= le of the AD wrt the WG process. - I usually also try to judge if we have a reasonable expectation of finish= ing up the to be adopted work (workload WG, research character etc.) - "is a simple modification to the charter feasible and warranted", how abo= ut large modifications, are they ever feasible and warranted? - "Group, not chairs: Concerning the draft, the position of the working group chairs has no special authority.", I think that is o= nly true wrt technical content, the chair does have special authority to ma= ke sure that WG consensus is properly represented, that due process is foll= owed etc. 3:=20 - Typo in the sentence: "A simplistic rule of thumb is that editors tend to do the mechanics of incorporating working group detail, whereas tend to create the detail, subject to working group approval." whereas tend to =3D>> whereas authors tend to Hope this helps, Klaas= From dcrocker@bbiw.net Fri Jan 17 07:49:42 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE231AE12D; Fri, 17 Jan 2014 07:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcskBeLTe0Qg; Fri, 17 Jan 2014 07:49:40 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5B36C1AE10B; Fri, 17 Jan 2014 07:49:40 -0800 (PST) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s0HFnMR8024934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 Jan 2014 07:49:26 -0800 Message-ID: <52D950F9.7050909@bbiw.net> Date: Fri, 17 Jan 2014 07:49:13 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Klaas Wierenga (kwiereng)" , "iesg@ietf.org" , "secdir@ietf.org" , "draft-crocker-id-adoption.all@tools.ietf.org" References: <8D28F665-CDF8-4FAA-869E-CA5EF6E673D2@cisco.com> In-Reply-To: <8D28F665-CDF8-4FAA-869E-CA5EF6E673D2@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.67]); Fri, 17 Jan 2014 07:49:26 -0800 (PST) Subject: Re: [secdir] review of draft-crocker-id-adoption-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 15:49:42 -0000 Klass, Thanks for your thoughtful comments. On 1/17/2014 6:41 AM, Klaas Wierenga (kwiereng) wrote: > - I think the title "Creating an IETF Working Group Draft" is a > misnomer, at least it led me to believe that it would be a guide for > creating a draft, i.e. what template, what sections, how to use the > tools etc. Something like "the lifecycle of an IETF WG Draft" seems > more appropriate. Well, the scope of the document did expand, over iterations. At this point I'm probably too deep in the details to have a good sense of a good title, though I always appreciate efforts at better titles. If folks think the document really is broad enough to cover wg doc lifecycle, that's fine with me. Adrian? > - Since this is a document that aims to document the actual way the > WG drafts are handled I wonder whether you should mention that > reality is not always what is put on paper. For example whereas > change control lies with the WG rather then the author, in reality > the author often has a strong influence on what is being published. I thought there were enough qualifiers in the document, to this point. So please suggest specific addition/changes. Sometimes too much of that kind of commentary can overload a doc to the point of distraction, but that's not likely for this case. So you point and suggest text and I'll add it. (Adrian has also been easy-going about such things with the draft.) > 1.1: > > - since in section 5.1 the individual submissions pops up, it may > make sense to add a note here that says something like: "NOTE: in > addition to WG drafts each individual can also independently submit a > draft (that may at a later stage either or not be adopted by a WG)" How's this (adding after ): 1.1 What is a Working Group Draft? Documents under development in the IETF community are distributed as Internet Drafts (I-D) [ID-Info]. Working groups use this mechanism for producing their official output, per Section 7.2 of [RFC2418] and Section 6.3 of [Tao]. The convention for identifying an I-D formally under the ownership of a working group is by the inclusion of "ietf" in the second field of the I-D filename and the working group name in the third field, per Section 7 of [ID-Guidelines]. That is: draft-ietf--... Individual submissions are drafts being created and pursued outside of a working group, although a working group might choose to adopt the draft later, as discussed below. Anyone is free to create an individual submission at any time. Such documents are typically distinguished through the use of the author's last name, in the style of: draft--... Responsibility for direct revision of a working group I-D is assigned to its editors and authors. See Section 3 for discussion about their selection and role. > 2.1: > > - I usually (especially with relative newcomers) explicitly make the > authors of a submitted draft aware of the fact that they give up > change control for their love baby to the WG. What is the specific change you want? > 2.2: > > - Also in other sections, but especially when it is about adopting a > draft and/or determining whether it fits in the charter there is > often quite a bit of involvement from the AD's, I think you need to > at least mention the role of the AD wrt the WG process. I think this varies quite a bit, and suggest we be careful about saying anything that sounds like a requirement for this, especially since there is a long-standing desire to /reduce/ AD load, not increase it. In formal terms, I believe the AD is /not/ part of the draft adoption process. They can interact about anything in the wg, of course, but noting any specific like this could too easily confuse folk that it is necessary. > - I usually also try to judge if we have a reasonable expectation of > finishing up the to be adopted work (workload WG, research character > etc.) So add to Criteria: o Is the draft likely to be completed in a timely manner? That's more generic than you've suggested, but I figure the whole point of such a bullet is simply to get folk to think about the going-forward pragmatics. > - "is a simple modification to the charter feasible and warranted", > how about large modifications, are they ever feasible and warranted? I think the first bullet implies this issue well enough: o Is there a charter milestone that explicitly calls for such a document? We need to be careful that the list isn't too picky with details. > - "Group, not chairs: Concerning the draft, the position of the > working group chairs has no special authority.", I think that is only > true wrt technical content, the chair does have special authority to > make sure that WG consensus is properly represented, that due process > is followed etc. Concerning the draft, the position of the working group chairs has no special authority, except to assess working group consensus. > 3: > > - Typo in the sentence: "A simplistic rule of thumb is that editors > tend to do the mechanics of incorporating working group detail, > whereas tend to create the detail, subject to working group > approval." > > whereas tend to =>> whereas authors tend to ack. tnx. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From kwiereng@cisco.com Fri Jan 17 08:07:30 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7998B1AE169; Fri, 17 Jan 2014 08:07:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.039 X-Spam-Level: X-Spam-Status: No, score=-15.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qi4LsN6eF0sq; Fri, 17 Jan 2014 08:07:27 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9411AE14E; Fri, 17 Jan 2014 08:07:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6332; q=dns/txt; s=iport; t=1389974835; x=1391184435; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7s+NGf4yLXbAjLyCjXKJ7H0LnMAHhOqRFMUCdViwVtM=; b=XVj4cC87qGXwsQRoF/SyEtkIEl/l4Go3qvoNfjBj166PV8FCZQhAP2SH CUObNWAxDiqs0/P/UXl3g9AFqKqCaF0oDaJOIxNhFPrQJxd6/MlNbC8bk shHfiC6cDhbvdROdVuA50flZNtKhg28YmOa9vPCV9RTyv8VVAR1QN9Vrw Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAJFf2FKtJV2d/2dsb2JhbABZgwuBDrsRgQ8WdIIlAQEBAwF0BQULAgEIDgouMiUCBAoEBRSHaAjFQReOTDMHgySBFASJD48SkheDLYIq X-IronPort-AV: E=Sophos;i="4.95,674,1384300800"; d="scan'208";a="297843688" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 17 Jan 2014 16:07:14 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s0HG7EO8030552 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Jan 2014 16:07:14 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.104]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Fri, 17 Jan 2014 10:07:14 -0600 From: "Klaas Wierenga (kwiereng)" To: Dave Crocker Thread-Topic: review of draft-crocker-id-adoption-05 Thread-Index: AQHPE5I77i18p0U40EKrtcrrUBqywpqJdMeAgAAFB4A= Date: Fri, 17 Jan 2014 16:07:13 +0000 Message-ID: References: <8D28F665-CDF8-4FAA-869E-CA5EF6E673D2@cisco.com> <52D950F9.7050909@bbiw.net> In-Reply-To: <52D950F9.7050909@bbiw.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.101.245] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <238B074326EB154CA7E6D36379B624BC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-crocker-id-adoption.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] review of draft-crocker-id-adoption-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 16:07:30 -0000 On Jan 17, 2014, at 4:49 PM, Dave Crocker wrote: >=20 Dave, > Thanks for your thoughtful comments. >=20 >=20 > On 1/17/2014 6:41 AM, Klaas Wierenga (kwiereng) wrote: >> - I think the title "Creating an IETF Working Group Draft" is a >> misnomer, at least it led me to believe that it would be a guide for >> creating a draft, i.e. what template, what sections, how to use the >> tools etc. Something like "the lifecycle of an IETF WG Draft" seems >> more appropriate. >=20 > Well, the scope of the document did expand, over iterations. At this poi= nt I'm probably too deep in the details to have a good sense of a good titl= e, though I always appreciate efforts at better titles. If folks think the= document really is broad enough to cover wg doc lifecycle, that's fine wit= h me. >=20 > Adrian? >=20 >=20 >> - Since this is a document that aims to document the actual way the >> WG drafts are handled I wonder whether you should mention that >> reality is not always what is put on paper. For example whereas >> change control lies with the WG rather then the author, in reality >> the author often has a strong influence on what is being published. >=20 > I thought there were enough qualifiers in the document, to this point. So= please suggest specific addition/changes. Sometimes too much of that kind= of commentary can overload a doc to the point of distraction, but that's n= ot likely for this case. So you point and suggest text and I'll add it. (= Adrian has also been easy-going about such things with the draft.) ;-) ok, I'll go through it again (probably not today as the week is coming = to an end for me) >> 1.1: >>=20 >> - since in section 5.1 the individual submissions pops up, it may >> make sense to add a note here that says something like: "NOTE: in >> addition to WG drafts each individual can also independently submit a >> draft (that may at a later stage either or not be adopted by a WG)" >=20 > How's this (adding after ): >=20 > 1.1 What is a Working Group Draft? >=20 > Documents under development in the IETF community are distributed as Inte= rnet Drafts (I-D) [ID-Info]. Working groups use this mechanism for producin= g their official output, per Section 7.2 of [RFC2418] and Section 6.3 of [T= ao]. The convention for identifying an I-D formally under the ownership of = a working group is by the inclusion of "ietf" in the second field of the I-= D filename and the working group name in the third field, per Section 7 of = [ID-Guidelines]. That is: >=20 > draft-ietf--... >=20 > Individual submissions are drafts being created and pursued outside of a = working group, although a working group might choose to adopt the draft lat= er, as discussed below. Anyone is free to create an individual submission a= t any time. Such documents are typically distinguished through the use of t= he author's last name, in the style of: >=20 > draft--... >=20 > Responsibility for direct revision of a working group I-D is assigned to = its editors and authors. See Section 3 for discussion about their selection= and role. perfect! >=20 >=20 >=20 >> 2.1: >>=20 >> - I usually (especially with relative newcomers) explicitly make the >> authors of a submitted draft aware of the fact that they give up >> change control for their love baby to the WG. >=20 > What is the specific change you want? between bullit 2 and 3 add: - verify that the draft submitters are aware that they transfer change cont= rol for the document to the WG (and the IETF) (not trying to be picky, but this particular point I have seen go wrong oft= en, leading to rubber stamp discussions etc) >=20 >=20 >> 2.2: >>=20 >> - Also in other sections, but especially when it is about adopting a >> draft and/or determining whether it fits in the charter there is >> often quite a bit of involvement from the AD's, I think you need to >> at least mention the role of the AD wrt the WG process. >=20 > I think this varies quite a bit, and suggest we be careful about saying a= nything that sounds like a requirement for this, especially since there is = a long-standing desire to /reduce/ AD load, not increase it. >=20 > In formal terms, I believe the AD is /not/ part of the draft adoption pro= cess. They can interact about anything in the wg, of course, but noting an= y specific like this could too easily confuse folk that it is necessary. Ehm, yes I understand what you are saying. But I think the AD has a formal = role in approving a recharter, right? =20 >=20 >=20 >> - I usually also try to judge if we have a reasonable expectation of >> finishing up the to be adopted work (workload WG, research character >> etc.) >=20 > So add to Criteria: >=20 > o Is the draft likely to be completed in a timely manner? >=20 > That's more generic than you've suggested, but I figure the whole point o= f such a bullet is simply to get folk to think about the going-forward prag= matics. yes, better than my suggestion >=20 >=20 >> - "is a simple modification to the charter feasible and warranted", >> how about large modifications, are they ever feasible and warranted? >=20 > I think the first bullet implies this issue well enough: >=20 > o Is there a charter milestone that explicitly calls for such a documen= t? >=20 > We need to be careful that the list isn't too picky with details. ok, agreed >> - "Group, not chairs: Concerning the draft, the position of the >> working group chairs has no special authority.", I think that is only >> true wrt technical content, the chair does have special authority to >> make sure that WG consensus is properly represented, that due process >> is followed etc. >=20 > Concerning the draft, the position of the working group chairs has > no special authority, except to assess working group consensus. >=20 ack >=20 >=20 >> 3: >>=20 >> - Typo in the sentence: "A simplistic rule of thumb is that editors >> tend to do the mechanics of incorporating working group detail, >> whereas tend to create the detail, subject to working group >> approval." >>=20 >> whereas tend to =3D>> whereas authors tend to >=20 > ack. tnx. >=20 Klaas From dcrocker@bbiw.net Fri Jan 17 08:08:45 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403081AE169; Fri, 17 Jan 2014 08:08:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ok5mva_8ecnf; Fri, 17 Jan 2014 08:08:44 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 67E0B1ADFA9; Fri, 17 Jan 2014 08:08:44 -0800 (PST) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s0HG8PTa025324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 Jan 2014 08:08:30 -0800 Message-ID: <52D9556F.6090704@bbiw.net> Date: Fri, 17 Jan 2014 08:08:15 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Klaas Wierenga (kwiereng)" References: <8D28F665-CDF8-4FAA-869E-CA5EF6E673D2@cisco.com> <52D950F9.7050909@bbiw.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.67]); Fri, 17 Jan 2014 08:08:30 -0800 (PST) Cc: "draft-crocker-id-adoption.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] review of draft-crocker-id-adoption-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 16:08:45 -0000 On 1/17/2014 8:07 AM, Klaas Wierenga (kwiereng) wrote: > Ehm, yes I understand what you are saying. But I think the AD has a formal role in approving a recharter, right? charter concerns are handled by the bullet that refers to charter scope. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From adrian@olddog.co.uk Fri Jan 17 08:45:29 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E36F1AE152; Fri, 17 Jan 2014 08:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0F2Ry9HXiTtj; Fri, 17 Jan 2014 08:45:27 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 262E81AE11E; Fri, 17 Jan 2014 08:45:27 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0HGj4Zv009647; Fri, 17 Jan 2014 16:45:04 GMT Received: from 950129200 (13.17.90.92.rev.sfr.net [92.90.17.13]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0HGj0Ym009606 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 17 Jan 2014 16:45:02 GMT From: "Adrian Farrel" To: "'Dave Crocker'" , "'Klaas Wierenga \(kwiereng\)'" , , , References: <8D28F665-CDF8-4FAA-869E-CA5EF6E673D2@cisco.com> <52D950F9.7050909@bbiw.net> In-Reply-To: <52D950F9.7050909@bbiw.net> Date: Fri, 17 Jan 2014 16:45:03 -0000 Message-ID: <05a201cf13a3$7a2e10b0$6e8a3210$@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: AQHG90e9rK7IrlCmVkLUD6+RlR5XMgENcrQtmpDof/A= Content-Language: en-gb Subject: Re: [secdir] review of draft-crocker-id-adoption-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 17 Jan 2014 16:45:29 -0000 Hi all, > > - I think the title "Creating an IETF Working Group Draft" is a > > misnomer, at least it led me to believe that it would be a guide for > > creating a draft, i.e. what template, what sections, how to use the > > tools etc. Something like "the lifecycle of an IETF WG Draft" seems > > more appropriate. > > Well, the scope of the document did expand, over iterations. At this > point I'm probably too deep in the details to have a good sense of a > good title, though I always appreciate efforts at better titles. If > folks think the document really is broad enough to cover wg doc > lifecycle, that's fine with me. > > Adrian? Noting that the filename is I offer "Observations on the Process for Creating an IETF Working Group Draft" or "Adopting an IETF Working Group Draft" or "Handling of Internet Drafts by IETF Working Groups" > > - Since this is a document that aims to document the actual way the > > WG drafts are handled I wonder whether you should mention that > > reality is not always what is put on paper. For example whereas > > change control lies with the WG rather then the author, in reality > > the author often has a strong influence on what is being published. > > I thought there were enough qualifiers in the document, to this point. > So please suggest specific addition/changes. Sometimes too much of that > kind of commentary can overload a doc to the point of distraction, but > that's not likely for this case. So you point and suggest text and I'll > add it. (Adrian has also been easy-going about such things with the draft.) While I would welcome suggestions of text on this point I am less that easy-going about documenting worst current practice. In fact, I think I take issue with what Klaas says: it may well be that document editors/authors have strong influence on the text that is generated, but if the WG is being denied the opportunity to review and object to the text (possibly after a revision of the I-D has been posted), then the WG is not being run well. So I am happy with the text as it stands. > > 1.1: > > > > - since in section 5.1 the individual submissions pops up, it may > > make sense to add a note here that says something like: "NOTE: in > > addition to WG drafts each individual can also independently submit a > > draft (that may at a later stage either or not be adopted by a WG)" > > How's this (adding after ): It's a good change as Dave presents it, but this document is not attempting to reproduce a discussion of all the mechanics of the IETF. [snip] > > 2.1: > > > > - I usually (especially with relative newcomers) explicitly make the > > authors of a submitted draft aware of the fact that they give up > > change control for their love baby to the WG. Which was, I thought, the point of the text that you objected to before! > What is the specific change you want? [KW] between bullit 2 and 3 add: [KW] [KW] - verify that the draft submitters are aware that they transfer [KW] change control for the document to the WG (and the IETF) Works for me, but maybe... - remind the draft submitters that they transfer change control for the document to the WG (and the IETF) > > 2.2: > > > > - Also in other sections, but especially when it is about adopting a > > draft and/or determining whether it fits in the charter there is > > often quite a bit of involvement from the AD's, I think you need to > > at least mention the role of the AD wrt the WG process. > > I think this varies quite a bit, and suggest we be careful about saying > anything that sounds like a requirement for this, especially since there > is a long-standing desire to /reduce/ AD load, not increase it. > > In formal terms, I believe the AD is /not/ part of the draft adoption > process. They can interact about anything in the wg, of course, but > noting any specific like this could too easily confuse folk that it is > necessary. Whether it is a matter of AD load or obsessive micro-management, the chairs run the WGs not the ADs. Sure, if a chair is found to be in the weeds, the AD will yank him back or cut him loose, but that is not the AD making the decisions. (Oh and a chair can ask the AD for any advice, of course.) Thus, the point of this document is to tell chairs what they are free to do. If the ADs object, no doubt they will shout at us during IESG review, but I am pretty confident that the current IESG will say that it is not the AD's job to make the decisions, merely to hold chairs' feet to the flames. > > - I usually also try to judge if we have a reasonable expectation of > > finishing up the to be adopted work (workload WG, research character > > etc.) > > So add to Criteria: > > o Is the draft likely to be completed in a timely manner? > > That's more generic than you've suggested, but I figure the whole point > of such a bullet is simply to get folk to think about the going-forward > pragmatics. Looks good. > > - "is a simple modification to the charter feasible and warranted", > > how about large modifications, are they ever feasible and warranted? > > I think the first bullet implies this issue well enough: > > o Is there a charter milestone that explicitly calls for such a > document? > > We need to be careful that the list isn't too picky with details. > > > > - "Group, not chairs: Concerning the draft, the position of the > > working group chairs has no special authority.", I think that is only > > true wrt technical content, the chair does have special authority to > > make sure that WG consensus is properly represented, that due process > > is followed etc. > > Concerning the draft, the position of the working group chairs has > no special authority, except to assess working group consensus. Yes. Thanks, Adrian From kwiereng@cisco.com Fri Jan 17 09:46:26 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 763451A16F0; Fri, 17 Jan 2014 09:46:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPqV9SGw10Wf; Fri, 17 Jan 2014 09:46:24 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 372951A1F1B; Fri, 17 Jan 2014 09:46:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5750; q=dns/txt; s=iport; t=1389980772; x=1391190372; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=S2dH8f+vA3/gCPgO5PhxP9HeHbuw2AM53eqPhluxjbk=; b=mweZJ/4uEU6Ee/WCHbXa1oJv/fSa6Zmt0osO/zjw/5vp7OcUVjawkbIR k9IxMYoPbbQc5U4AmwaKKhxhyrHGitGB2PRGv1UQZJ+pV92E6HIO8Gmng 18ZPvfK1fZVDQ4yXNOFEwP352iQ/mN8L6SaehJ5R+9eNn09IvT31HMtBd o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAAJp2VKtJXG8/2dsb2JhbABZgwuqPZFsgQ4WdIIlAQEBAwE6OgUFCwIBCBgeEDIlAgQKBAWHfAjEEBeOTDMHgySBFASYIZIXgy0 X-IronPort-AV: E=Sophos;i="4.95,675,1384300800"; d="scan'208";a="13662548" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-1.cisco.com with ESMTP; 17 Jan 2014 17:46:11 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0HHkBGL019621 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Jan 2014 17:46:11 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.104]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Fri, 17 Jan 2014 11:46:10 -0600 From: "Klaas Wierenga (kwiereng)" To: "" Thread-Topic: review of draft-crocker-id-adoption-05 Thread-Index: AQHPE5I77i18p0U40EKrtcrrUBqywpqJdMeAgAAPmYD//6x+FQ== Date: Fri, 17 Jan 2014 17:46:10 +0000 Message-ID: References: <8D28F665-CDF8-4FAA-869E-CA5EF6E673D2@cisco.com> <52D950F9.7050909@bbiw.net>,<05a201cf13a3$7a2e10b0$6e8a3210$@olddog.co.uk> In-Reply-To: <05a201cf13a3$7a2e10b0$6e8a3210$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-crocker-id-adoption.all@tools.ietf.org" , "secdir@ietf.org" , Dave Crocker , "iesg@ietf.org" Subject: Re: [secdir] review of draft-crocker-id-adoption-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 17:46:26 -0000 Hi, > On 17 jan. 2014, at 17:45, "Adrian Farrel" wrote: >=20 > Hi all, >=20 >>> - I think the title "Creating an IETF Working Group Draft" is a >>> misnomer, at least it led me to believe that it would be a guide for >>> creating a draft, i.e. what template, what sections, how to use the >>> tools etc. Something like "the lifecycle of an IETF WG Draft" seems >>> more appropriate. >>=20 >> Well, the scope of the document did expand, over iterations. At this >> point I'm probably too deep in the details to have a good sense of a >> good title, though I always appreciate efforts at better titles. If >> folks think the document really is broad enough to cover wg doc >> lifecycle, that's fine with me. >>=20 >> Adrian? >=20 > Noting that the filename is I offer >=20 > "Observations on the Process for Creating an IETF Working Group Draft" > or > "Adopting an IETF Working Group Draft" > or > "Handling of Internet Drafts by IETF Working Groups" I like the third >=20 >>> - Since this is a document that aims to document the actual way the >>> WG drafts are handled I wonder whether you should mention that >>> reality is not always what is put on paper. For example whereas >>> change control lies with the WG rather then the author, in reality >>> the author often has a strong influence on what is being published. >>=20 >> I thought there were enough qualifiers in the document, to this point. >> So please suggest specific addition/changes. Sometimes too much of that >> kind of commentary can overload a doc to the point of distraction, but >> that's not likely for this case. So you point and suggest text and I'll >> add it. (Adrian has also been easy-going about such things with the dra= ft.) >=20 > While I would welcome suggestions of text on this point I am less that > easy-going about documenting worst current practice. In fact, I think I t= ake > issue with what Klaas says: it may well be that document editors/authors = have > strong influence on the text that is generated, but if the WG is being de= nied > the opportunity to review and object to the text (possibly after a revisi= on of > the I-D has been posted), then the WG is not being run well. So I am happ= y with > the text as it stands. I think you misunderstand what I tried to say, I am in no way advocating th= is, I am stating behavior that I observe. What I am proposing text along th= e lines of "authors and/or editors may feel like that they "own" the docume= nt and strongly influence the final text. The WG chair will have to make su= re that WG consensus is properly reflected" >=20 >>> 1.1: >>>=20 >>> - since in section 5.1 the individual submissions pops up, it may >>> make sense to add a note here that says something like: "NOTE: in >>> addition to WG drafts each individual can also independently submit a >>> draft (that may at a later stage either or not be adopted by a WG)" >>=20 >> How's this (adding after ): >=20 > It's a good change as Dave presents it, but this document is not attempti= ng to > reproduce a discussion of all the mechanics of the IETF. I understand that, but further down in the document you mention individual = submissions without much explanation, I think including it here makes sense= to give the reader that is not familiar so the process (the target audienc= e of the document after all) a bit of context. >=20 > [snip] >=20 >>> 2.1: >>>=20 >>> - I usually (especially with relative newcomers) explicitly make the >>> authors of a submitted draft aware of the fact that they give up >>> change control for their love baby to the WG. >=20 > Which was, I thought, the point of the text that you objected to before! Yup, not making a value judgment before, just observing behavior >=20 >> What is the specific change you want? >=20 > [KW] between bullit 2 and 3 add: > [KW] > [KW] - verify that the draft submitters are aware that they transfer > [KW] change control for the document to the WG (and the IETF) >=20 > Works for me, but maybe... > - remind the draft submitters that they transfer change control for > the document to the WG (and the IETF) Yes, this non-native speaker humbly bows his head >=20 >>> 2.2: >>>=20 >>> - Also in other sections, but especially when it is about adopting a >>> draft and/or determining whether it fits in the charter there is >>> often quite a bit of involvement from the AD's, I think you need to >>> at least mention the role of the AD wrt the WG process. >>=20 >> I think this varies quite a bit, and suggest we be careful about saying >> anything that sounds like a requirement for this, especially since there >> is a long-standing desire to /reduce/ AD load, not increase it. >>=20 >> In formal terms, I believe the AD is /not/ part of the draft adoption >> process. They can interact about anything in the wg, of course, but >> noting any specific like this could too easily confuse folk that it is >> necessary. >=20 > Whether it is a matter of AD load or obsessive micro-management, the chai= rs run > the WGs not the ADs. Sure, if a chair is found to be in the weeds, the AD= will > yank him back or cut him loose, but that is not the AD making the decisio= ns. (Oh > and a chair can ask the AD for any advice, of course.) >=20 > Thus, the point of this document is to tell chairs what they are free to = do. If > the ADs object, no doubt they will shout at us during IESG review, but I = am > pretty confident that the current IESG will say that it is not the AD's j= ob to > make the decisions, merely to hold chairs' feet to the flames. Ok [snip] Klaas= From new-work-bounces@ietf.org Fri Jan 17 09:52:53 2014 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE121AC8F5; Fri, 17 Jan 2014 09:52:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1389981173; bh=s0jVZ78+ZzzOhjiZR0bzqD6iGZieqjQaCKFe8fjY8JM=; 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=BzfwSDRaWvV+nSbigmC2N8fVPXUY5nGycddrGv8YFqWk3MgoFiOGrCs2xRDCJvKde twRcfFjmclgelarZv/9Nk0BK7NXRsPwQicsyH194QwLSRvWoyZlQst315QXO6Pv++q oHXgbtUoYz8KqKg9b4wR0HzhLZPUJNr7u6PP5neg= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 064EE1AC421 for ; Fri, 17 Jan 2014 09:52:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oiOWJZDjNuwL for ; Fri, 17 Jan 2014 09:52:50 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCB01A1F4C for ; Fri, 17 Jan 2014 09:52:50 -0800 (PST) Received: from bleuazur.com ([88.173.33.195] helo=sith.local) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1W4Dap-0001Ia-VW; Fri, 17 Jan 2014 12:52:37 -0500 To: new-work@ietf.org Date: Fri, 17 Jan 2014 18:52:30 +0100 MIME-Version: 1.0 From: "Coralie Mercier" Organization: W3C Message-ID: User-Agent: Opera Mail/1.0 (MacIntel) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Errors-To: new-work-bounces@ietf.org Sender: "new-work" X-Mailman-Approved-At: Fri, 17 Jan 2014 09:55:21 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: HTML5 Chinese Interest Group (until 2014-02-24) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 17:52:53 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the HTML Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft revised charter for the HTML5 Chinese Interest Group: http://www.w3.org/2013/12/html-ig-zh-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 2014-02-24 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 Xiaoqian Wu, Team contact . Thank you, Coralie Mercier, W3C Communications [0] http://www.w3.org/MarkUp/Activity [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 mailto:coralie@w3.org +336 4322 0001 http://www.w3.org/People/CMercier/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From dcrocker@bbiw.net Fri Jan 17 10:01:13 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B411AD939; Fri, 17 Jan 2014 10:01:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZU071WpRiR95; Fri, 17 Jan 2014 10:01:12 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2571AC421; Fri, 17 Jan 2014 10:01:12 -0800 (PST) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s0HI0qEo027179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 Jan 2014 10:00:56 -0800 Message-ID: <52D96FCB.5010002@bbiw.net> Date: Fri, 17 Jan 2014 10:00:43 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Klaas Wierenga (kwiereng)" , "" References: <8D28F665-CDF8-4FAA-869E-CA5EF6E673D2@cisco.com> <52D950F9.7050909@bbiw.net>, <05a201cf13a3$7a2e10b0$6e8a3210$@olddog.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.67]); Fri, 17 Jan 2014 10:00:56 -0800 (PST) Cc: "draft-crocker-id-adoption.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] review of draft-crocker-id-adoption-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 18:01:14 -0000 On 1/17/2014 9:46 AM, Klaas Wierenga (kwiereng) wrote: > Hi, > >> On 17 jan. 2014, at 17:45, "Adrian Farrel" >> wrote: "Handling of Internet Drafts by IETF Working Groups" > > I like the third me too. >> >>>> - Since this is a document that aims to document the actual way >>>> the WG drafts are handled I wonder whether you should mention >>>> that reality is not always what is put on paper. ... >>> I thought there were enough qualifiers in the document, to this >>> point. So please suggest specific addition/changes. Sometimes ... >> While I would welcome suggestions of text on this point I am less >> that easy-going about documenting worst current practice. In fact, >> I think I take issue with what Klaas says: it may well be that >> document editors/authors have strong influence on the text that is >> generated, but if the WG is being denied the opportunity to review >> and object to the text (possibly after a revision of the I-D has >> been posted), then the WG is not being run well. So I am happy >> with the text as it stands. > > I think you misunderstand what I tried to say, I am in no way > advocating this, I am stating behavior that I observe. What I am > proposing text along the lines of "authors and/or editors may feel > like that they "own" the document and strongly influence the final > text. The WG chair will have to make sure that WG consensus is > properly reflected" I'm confused. I would have thought that the existing paragraph: 1.2 Working Group Authority and Consensus ... At times, a document author/editor can appear to have considerable authority over content, but this is (merely) for efficiency. That is, the chairs can permit authors and editors to proceed with an implied (default) working group agreement, as long as the working group is comfortable with that mode... and all of Section 3, deal with this concern sufficiently. >>>> 2.1: ... >>> What is the specific change you want? >> >> [KW] between bullit 2 and 3 add: [KW] [KW] - verify that the draft >> submitters are aware that they transfer [KW] change control for >> the document to the WG (and the IETF) >> >> Works for me, but maybe... - remind the draft submitters that they >> transfer change control for the document to the WG (and the IETF) > > Yes, this non-native speaker humbly bows his head added. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From kathleen.moriarty@emc.com Fri Jan 17 10:45:01 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C901ADEA1; Fri, 17 Jan 2014 10:45:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBCdguOspdoJ; Fri, 17 Jan 2014 10:44:58 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8D71AD939; Fri, 17 Jan 2014 10:44:58 -0800 (PST) Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0HIiZZt008112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Jan 2014 13:44:36 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s0HIiZZt008112 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1389984276; bh=QxJHZBMKEzLeteClehXM5ZlrA0s=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=juIRcLQO7L7SRJxjLNmZHIfYOkGps2YtocZugsuYb/de46v/7jHa3XLovNJsWX5bC hk50RxMu2XwZAdMr05qmxjr8VJvmFePrgYT0Vb6jA880RYOX2o6pACFntXLsoLi1jK klYdV33lpPRpyqSKRY6Z4sfaDDkPMv5+LdpgBDY4= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s0HIiZZt008112 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd52.lss.emc.com (RSA Interceptor); Fri, 17 Jan 2014 13:44:19 -0500 Received: from mxhub29.corp.emc.com (mxhub29.corp.emc.com [128.222.70.169]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0HIiILc009677 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Jan 2014 13:44:19 -0500 Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub29.corp.emc.com ([128.222.70.169]) with mapi; Fri, 17 Jan 2014 13:44:18 -0500 From: "Moriarty, Kathleen" To: Tina TSOU , "Org Iesg@Ietf." , "draft-moriarty-pkcs12v1-1.all@tools.ietf.org" , "Org Secdir@Ietf." Date: Fri, 17 Jan 2014 13:44:17 -0500 Thread-Topic: Secdir review of draft-moriarty-pkcs12v1-1-03 Thread-Index: Ac8OoNNjmUASwqpuQRqIGLIzjfx0kAFETBSA Message-ID: References: <37320726-3F8C-43B8-BCBD-5C40DF1F2572@huawei.com> In-Reply-To: <37320726-3F8C-43B8-BCBD-5C40DF1F2572@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5063677821E3B4F81ACFB7905573F2406584BA9C0MX15Acorpemcc_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: DLM_1, public Subject: Re: [secdir] Secdir review of draft-moriarty-pkcs12v1-1-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 18:45:01 -0000 --_000_F5063677821E3B4F81ACFB7905573F2406584BA9C0MX15Acorpemcc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gVGluYSwNCg0KVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgdGFraW5nIHRoZSB0aW1lIHRv IHJldmlldy4gIEkgbWFkZSB0aGUgZWRpdG9yaWFsIGNvcnJlY3Rpb25zIGluIHRoZSBuZXcgdmVy c2lvbiB0aGF0IHdpbGwgYmUgcG9zdGVkIHNob3J0bHkuICBXZSBkZWNpZGVkIHRvIHRyYW5zZmVy IGNoYW5nZSBjb250cm9sIHRvIHRoZSBJRVRGIGluIHRoaXMgdmVyc2lvbiBhbmQgd2lsbCBtYWtl IG1vcmUgc3Vic3RhbnRpYWwgdXBkYXRlcyB0byBmaXggcHJvYmxlbXMgaW4gdGhlIG5leHQgdmVy c2lvbi4NCg0KVGhhbmsgeW91LA0KS2F0aGxlZW4NCg0KRnJvbTogc2VjZGlyIFttYWlsdG86c2Vj ZGlyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUaW5hIFRTT1UNClNlbnQ6IFNhdHVy ZGF5LCBKYW51YXJ5IDExLCAyMDE0IDI6NDQgQU0NClRvOiBPcmcgSWVzZ0BJZXRmLjsgZHJhZnQt bW9yaWFydHktcGtjczEydjEtMS5hbGxAdG9vbHMuaWV0Zi5vcmc7IE9yZyBTZWNkaXJASWV0Zi4N ClN1YmplY3Q6IFtzZWNkaXJdIFNlY2RpciByZXZpZXcgb2YgZHJhZnQtbW9yaWFydHktcGtjczEy djEtMS0wMw0KDQpEZWFyIGFsbCwNCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBh cnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3MNCm9uZ29pbmcgZWZmb3J0IHRvIHJldmll dyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZQ0KSUVTRy4gIFRoZXNl IGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZQ0K c2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMuIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBz aG91bGQgdHJlYXQNCnRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxs IGNvbW1lbnRzLg0KDQoNCk1vc3Qgb2YgdGhlIGNvbnRlbnRzIGluIHRoaXMgZHJhZnQgaXMgdGFr ZW4gZGlyZWN0bHkgZnJvbSBhIHB1Ymxpc2hlZCBSU0EgZG9jdW1lbnQgUEtDUyAjMTIuIEluIHRo aXMgdmVyc2lvbiwgbmVhcmx5IGFsbCB0aGUgdHlwb3MgYXJlIGNvcnJlY3RlZC4gSSB0aGluayB0 aGlzIGRvY3VtZW50IGlzIGdvb2QgZW5vdWdoIGZvciBwdWJsaWNhdGlvbi4NCg0KDQpJbiBzZWN1 cml0eSBjb25zaWRlcmF0aW9uLCBpdCBpcyBzdWdnZXN0ZWQgdG8gZm9sbG93IFBLQ1MgIzUgKFJG QzI4OTgpIHRvIHNlbGVjdCBwYXNzd29yZHMuIEkgcmVhbGl6ZSB0aGF0IGluIFJGQzI4OTggdGhl cmUgaXMgbm8gZGlzY3Vzc2lvbiBhYm91dCBob3cgdG8gZW5zdXJlIGEgZ29vZCByYW5kb21uZXNz IG9mIHRoZSBzYWx0LiAgVGhlcmVmb3JlLCBJIHN1Z2dlc3QgdG8gY2l0ZSBSRkM0MDg2Lg0KTWF5 YmUgdGhlcmUgc2hvdWxkIGFsc28gYmUgYSByZWZlcmVuY2UgdG8gQXBwZW5kaXggQiwganVzdCB0 byBwdXQgdGhhdCBBcHBlbmRpeCBpbnRvIHBlcnNwZWN0aXZlIC4uLiBzYXlpbmcgdGhhdCBSRkMg NDA4NiBpcyB0aGUgc3VwZXJpb3IgZ3VpZGUsIGJ1dCBmb3IgaW50ZWdyaXR5IHByb3RlY3Rpb24g b25seSwgdGhlIG1ldGhvZCBvZiBBcHBlbmRpeCBCIG1heSBiZSBhZGVxdWF0ZS4NCg0KVHlwbzog c2Vjb25kIGxpbmUgb2YgQWJzdHJhY3QNCihSZXB1YmxpY2F0aW9uKSBGcm9tIC0+IChSZXB1Ymxp Y2F0aW9uKSBmcm9tDQoNClR5cG8sIFNlYy4gMS4xLCB0aGlyZCBmcm9tIGxhc3QgYnVsbGV0IHJl Z2FyZGluZyBTUCA4MDAtMTMyDQpzZWxlY3Rpb24gb2YgYSB0aGUgLT4gc2VsZWN0aW9uIG9mIHRo ZQ0KDQpOaXQ6IEFwcGVuZGl4IEIsIFNlYy4gQi40DQpwYXNzd29yZHMgYW5kIHNhbHQgdGhhdCB3 YXMgZ2l2ZW4gaW4gQXBwZW5kaXggQw0KIC0+IHBhc3N3b3JkcyBhbmQgc2FsdCB0aGF0IGlzIGdp dmVuIGluIEFwcGVuZGl4IEMNCg0KVGhhbmsgeW91LA0KVGluYQ0K --_000_F5063677821E3B4F81ACFB7905573F2406584BA9C0MX15Acorpemcc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBs aW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkhlbGxvIFRpbmEsPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz5UaGFuayB5b3UgdmVyeSBtdWNoIGZvciB0YWtpbmcgdGhlIHRpbWUgdG8gcmV2aWV3LsKg IEkgbWFkZSB0aGUgZWRpdG9yaWFsIGNvcnJlY3Rpb25zIGluIHRoZSBuZXcgdmVyc2lvbiB0aGF0 IHdpbGwgYmUgcG9zdGVkIHNob3J0bHkuwqAgV2UgZGVjaWRlZCB0byB0cmFuc2ZlciBjaGFuZ2Ug Y29udHJvbCB0byB0aGUgSUVURiBpbiB0aGlzIHZlcnNpb24gYW5kIHdpbGwgbWFrZSBtb3JlIHN1 YnN0YW50aWFsIHVwZGF0ZXMgdG8gZml4IHByb2JsZW1zIGluIHRoZSBuZXh0IHZlcnNpb24uwqAg PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz5UaGFuayB5b3UsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkthdGhsZWVuPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBj bGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gc2VjZGly IFttYWlsdG86c2VjZGlyLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+VGlu YSBUU09VPGJyPjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgSmFudWFyeSAxMSwgMjAxNCAyOjQ0IEFN PGJyPjxiPlRvOjwvYj4gT3JnIEllc2dASWV0Zi47IGRyYWZ0LW1vcmlhcnR5LXBrY3MxMnYxLTEu YWxsQHRvb2xzLmlldGYub3JnOyBPcmcgU2VjZGlyQElldGYuPGJyPjxiPlN1YmplY3Q6PC9iPiBb c2VjZGlyXSBTZWNkaXIgcmV2aWV3IG9mIGRyYWZ0LW1vcmlhcnR5LXBrY3MxMnYxLTEtMDM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjxkaXY+PGRpdj48ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMy4wcHQnPkRlYXIgYWxsLDwvc3Bhbj48bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5JIGhhdmUgcmV2aWV3ZWQgdGhpcyBk b2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzPGJyPm9uZ29pbmcg ZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRo ZTxicj5JRVNHLiAmbmJzcDtUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZv ciB0aGUgYmVuZWZpdCBvZiB0aGU8YnI+c2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMuIERvY3VtZW50 IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQ8YnI+dGhlc2UgY29tbWVudHMganVz dCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuPGJyPjxicj48bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rp dj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ TW9zdCBvZiB0aGUgY29udGVudHMgaW4gdGhpcyBkcmFmdCBpcyB0YWtlbiBkaXJlY3RseSBmcm9t IGEgcHVibGlzaGVkJm5ic3A7PC9zcGFuPlJTQSBkb2N1bWVudCBQS0NTICMxMi4gSW4gdGhpcyB2 ZXJzaW9uLCBuZWFybHkgYWxsIHRoZSB0eXBvcyBhcmUmbmJzcDtjb3JyZWN0ZWQuIEkgdGhpbmsg dGhpcyBkb2N1bWVudCBpcyBnb29kIGVub3VnaCBmb3IgcHVibGljYXRpb24uPG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz48YnI+PGJyPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPkluIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24s IGl0IGlzIHN1Z2dlc3RlZCB0byBmb2xsb3cgUEtDUyAjNSAoUkZDMjg5OCkmbmJzcDs8L3NwYW4+ dG8gc2VsZWN0IHBhc3N3b3Jkcy4gSSByZWFsaXplIHRoYXQgaW4gUkZDMjg5OCB0aGVyZSBpcyBu byBkaXNjdXNzaW9uJm5ic3A7YWJvdXQgaG93IHRvIGVuc3VyZSBhIGdvb2QgcmFuZG9tbmVzcyBv ZiB0aGUgc2FsdC4gJm5ic3A7VGhlcmVmb3JlLCBJJm5ic3A7c3VnZ2VzdCB0byBjaXRlIFJGQzQw ODYuPG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPk1heWJlIHRoZXJlIHNo b3VsZCBhbHNvIGJlIGEgcmVmZXJlbmNlIHRvIEFwcGVuZGl4IEIsIGp1c3QgdG8gcHV0IHRoYXQg QXBwZW5kaXggaW50byBwZXJzcGVjdGl2ZSAuLi4gc2F5aW5nIHRoYXQgUkZDIDQwODYgaXMgdGhl IHN1cGVyaW9yIGd1aWRlLCBidXQgZm9yIGludGVncml0eSBwcm90ZWN0aW9uIG9ubHksIHRoZSBt ZXRob2Qgb2YgQXBwZW5kaXggQiBtYXkgYmUgYWRlcXVhdGUuPG86cD48L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+VHlwbzogc2Vjb25kIGxpbmUgb2YgQWJzdHJhY3Q8YnI+KFJlcHVi bGljYXRpb24pIEZyb20gLSZndDsgKFJlcHVibGljYXRpb24pIGZyb208YnI+PGJyPlR5cG8sIFNl Yy4gMS4xLCB0aGlyZCBmcm9tIGxhc3QgYnVsbGV0IHJlZ2FyZGluZyBTUCA4MDAtMTMyPGJyPnNl bGVjdGlvbiBvZiBhIHRoZSAtJmd0OyBzZWxlY3Rpb24gb2YgdGhlPGJyPjxicj5OaXQ6IEFwcGVu ZGl4IEIsIFNlYy4gQi40PGJyPnBhc3N3b3JkcyBhbmQgc2FsdCB0aGF0IHdhcyBnaXZlbiBpbiBB cHBlbmRpeCBDPGJyPiZuYnNwOy0mZ3Q7IHBhc3N3b3JkcyBhbmQgc2FsdCB0aGF0IGlzIGdpdmVu IGluIEFwcGVuZGl4IEM8bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpw PiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5UaGFuayB5b3Us PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+VGluYTxvOnA+PC9v OnA+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvYm9keT48 L2h0bWw+ --_000_F5063677821E3B4F81ACFB7905573F2406584BA9C0MX15Acorpemcc_-- From vkg@bell-labs.com Fri Jan 17 13:40:55 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 371A11AE181; Fri, 17 Jan 2014 13:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wp64D-hL6a2J; Fri, 17 Jan 2014 13:40:52 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 495451AD6C1; Fri, 17 Jan 2014 13:40:50 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s0HLeUTv015389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 17 Jan 2014 15:40:30 -0600 (CST) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id s0HLeTxe031797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 Jan 2014 15:40:30 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id s0HLeTgt022231; Fri, 17 Jan 2014 15:40:29 -0600 (CST) Message-ID: <52D9A37B.5020301@bell-labs.com> Date: Fri, 17 Jan 2014 15:41:15 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" , "draft-ietf-soc-overload-control.all@tools.ietf.org" , "" , "iesg@ietf.org IESG" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [secdir] secdir review of draft-ietf-soc-overload-control-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 21:40:55 -0000 On 01/12/2014 10:44 PM, Joseph Salowey (jsalowey) 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. > > I think this document is ready with some minor issues. Joe: Thank you for your time and attention to the details of the document in general, and the security considerations in particular. Please see inline for possible resolutions and follow ups. > First I like what you have done with the security considerations > section. It defines the attacks of concern in a clear way and > describes some mitigations. Excellent; thank you! > 1. The security considerations section mentions several mitigations > for false overload control messages including TCP, Websockets, BCP-38 > and TLS. While TCP and Websockets provide more protection than UDP > its not clear to me that they are providing sufficient protection. > In addition, it seems that BCP-38 should be encouraged in all cases > (not just the TLS case). I'd feel better about the recommendation > if it stated some thing like "TCP and Websockets in conjunction with > BCP-38 make it more difficult for an attacker to insert or modify > messages, but it is still possible depending on where the attacker > is positioned in the network. TLS provides better protection from an > attacker that has access to the network link." I think that is reasonable. I can pretty much include the text you provide above verbatim in Section 11 (Security Considerations) as follows: OLD: Attacks that indicate false overload control can be mitigated by using TCP or Websockets [RFC6455], or better yet, TLS in conjunction with applying BCP 38 [RFC2827]. Attacks that are mounted to suppress genuine overload conditions can be avoided by using TLS on the connection. NEW: Attacks that indicate false overload control can be mitigated by using TCP or Websockets [RFC6455], or better yet, TLS in conjunction with applying BCP 38 [RFC2827]. Attacks that are mounted to suppress genuine overload conditions can be avoided by using TLS on the connection. Generally, TCP and Websockets in conjunction with BCP-38 make it more difficult for an attacker to insert or modify messages, but it is still possible depending on where the attacker is positioned in the network. TLS provides better protection from an attacker that has access to the network link. Let me know if that addresses your concern. > 2. Some privacy considerations are mentioned in section 5.3. Its > not really clear to me what these considerations are so it would be > good to expand upon them in the security considerations section. I think you meant Section 5.2, above (the word "privacy" appears in Section 5.2). Essentially, what is meant by the loss of privacy here is the knowledge that a random upstream client gains --- without much effort on its part --- that the supports overload. If, on the other hand, the server had a policy of only indicating overload support for those requests it received over a trusted channel where the identity of the client could be asserted, then its may loosen its inhibitions and indicate overload control. It is the inadvertent leakage of a capability (supports overload) to untrusted clients that is of concern here. I could insert a couple of sentences as the last paragraph of Section 11; candidate text below: Indicating support for overload control in a request received on an untrusted link can leak privacy in the form of capability support of the server. To limit the knowledge that the server supports overload control, a server can adopt a policy of inserting overload control support in only those requests received over trusted links. Reasonable? > 3. Is it possible that some of the oc-agorithms might have their own > security considerations. If this is likely then it might be good to > indicate the reader should check to see if the individual algorithm > specifications security considerations. Do we need to add anything specific here? If other overload control algorithms beyond rate and loss are standardized, I suspect that they will contain an appropriate Security Consideration section of their own. I am happy to add some text exhorting the implementor to consult the specific overload control algorithm document if you feel strongly about it. Please let me know. > 4. Is there any mitigation for the attack involving a proxy that > does not support mechanism from blindly forwarding an attacker's oc > headers? Alas, no. As per the SIP processing rules, a proxy that does not understand any Via header parameters is asked to simply tokenize them on the way in and serialize them on the way out. Thus, a proxy that does not support this specification will simply forward the overload control markings downstream. Again, thanks for a close read. Please let me know if the resolutions specified in this email form a reasonable basis to move ahead. Cheers, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From kwiereng@cisco.com Mon Jan 20 06:16:09 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA5F1A0171; Mon, 20 Jan 2014 06:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f_hwCSRgWhxg; Mon, 20 Jan 2014 06:16:08 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFDD1A016A; Mon, 20 Jan 2014 06:16:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1473; q=dns/txt; s=iport; t=1390227369; x=1391436969; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=UncSiSwYNKuKHahwON4T5eUQp7wouVJXwHwDX9eERH4=; b=HlegLknh7tCaCSvQ89QsiQa/B4vqSONUPljRKM3fbvJ77sAT/QI36q6v nNDxyBD52LiBjDB5dSmHRKhxFc9EnyZWrXtJ8eBpYVJFBvM4G8q18F4gC swe8bpoCDylkcxQRUbBFHAqzphkkDiZzM3zA8K1BAfpsJbqGAJ5Ypdab2 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAN4u3VKtJV2Y/2dsb2JhbABZgwuBDrs8gQ0WdIIlAQEBAwF5EAIBCA44MiUCBA6IAgjDYReOTDMHgySBFAEDiQ+PE5IYgy2CKg X-IronPort-AV: E=Sophos;i="4.95,691,1384300800"; d="scan'208";a="298461786" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 20 Jan 2014 14:16:08 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0KEG8Du011564 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Jan 2014 14:16:08 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.104]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Mon, 20 Jan 2014 08:16:08 -0600 From: "Klaas Wierenga (kwiereng)" To: Dave Crocker Thread-Topic: review of draft-crocker-id-adoption-05 Thread-Index: AQHPE5I77i18p0U40EKrtcrrUBqywpqJdMeAgAAPmYD//6x+FYAAaKaAgAR4PoA= Date: Mon, 20 Jan 2014 14:16:08 +0000 Message-ID: References: <8D28F665-CDF8-4FAA-869E-CA5EF6E673D2@cisco.com> <52D950F9.7050909@bbiw.net>,<05a201cf13a3$7a2e10b0$6e8a3210$@olddog.co.uk> <52D96FCB.5010002@bbiw.net> In-Reply-To: <52D96FCB.5010002@bbiw.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.96.52] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-crocker-id-adoption.all@tools.ietf.org" , "" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] review of draft-crocker-id-adoption-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 14:16:09 -0000 [snip] >>> While I would welcome suggestions of text on this point I am less >>> that easy-going about documenting worst current practice. In fact, >>> I think I take issue with what Klaas says: it may well be that >>> document editors/authors have strong influence on the text that is >>> generated, but if the WG is being denied the opportunity to review >>> and object to the text (possibly after a revision of the I-D has >>> been posted), then the WG is not being run well. So I am happy >>> with the text as it stands. >>=20 >> I think you misunderstand what I tried to say, I am in no way >> advocating this, I am stating behavior that I observe. What I am >> proposing text along the lines of "authors and/or editors may feel >> like that they "own" the document and strongly influence the final >> text. The WG chair will have to make sure that WG consensus is >> properly reflected" >=20 > I'm confused. I would have thought that the existing paragraph: >=20 > 1.2 Working Group Authority and Consensus > ... > At times, a document author/editor can appear to have considerable author= ity over content, but this is (merely) for efficiency. That is, the chairs = can permit authors and editors to proceed with an implied (default) working= group agreement, as long as the working group is comfortable with that mod= e... >=20 > and all of Section 3, deal with this concern sufficiently. Yes, you are right, apologies. Klaas= From dcrocker@bbiw.net Mon Jan 20 06:27:19 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D6D1A0166; Mon, 20 Jan 2014 06:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qf7_7kYfAbJ5; Mon, 20 Jan 2014 06:27:18 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 088C61A0138; Mon, 20 Jan 2014 06:27:18 -0800 (PST) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s0KERBoj024595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 20 Jan 2014 06:27:14 -0800 Message-ID: <52DD3231.4060706@bbiw.net> Date: Mon, 20 Jan 2014 06:26:57 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Klaas Wierenga (kwiereng)" References: <8D28F665-CDF8-4FAA-869E-CA5EF6E673D2@cisco.com> <52D950F9.7050909@bbiw.net>, <05a201cf13a3$7a2e10b0$6e8a3210$@olddog.co.uk> <52D96FCB.5010002@bbiw.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.67]); Mon, 20 Jan 2014 06:27:17 -0800 (PST) Cc: "draft-crocker-id-adoption.all@tools.ietf.org" , "" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] review of draft-crocker-id-adoption-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 14:27:19 -0000 On 1/20/2014 6:16 AM, Klaas Wierenga (kwiereng) wrote: >> I'm confused. I would have thought that the existing paragraph: ... >> >and all of Section 3, deal with this concern sufficiently. > Yes, you are right, apologies. OK. Glad they suffice. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From Lindsay@worldcastsystems.com Tue Jan 21 04:20:03 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA261A00BF; Tue, 21 Jan 2014 04:20:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lh8Ivg3WQCPo; Tue, 21 Jan 2014 04:20:00 -0800 (PST) Received: from mailgate.aptcodecs.com (mailgate.aptcodecs.com [217.33.179.85]) by ietfa.amsl.com (Postfix) with ESMTP id 585231A006A; Tue, 21 Jan 2014 04:20:00 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Jan 2014 12:19:58 -0000 Message-ID: <8C4E0C2409735E4FBC22D754A238F94D0303D9C4@APTSBS.apt.local> In-Reply-To: <21152.30161.542379.749064@fireball.kivinen.iki.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Secdir review of draft-ietf-payload-rtp-aptx-04 thread-index: Ac7xusCplXnaV9qsQYWTwgG0ooxBcwk59InQ References: <21152.30161.542379.749064@fireball.kivinen.iki.fi> From: "John Lindsay" To: "Tero Kivinen" , , , X-Mailman-Approved-At: Tue, 21 Jan 2014 04:45:47 -0800 Subject: Re: [secdir] Secdir review of draft-ietf-payload-rtp-aptx-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 12:20:03 -0000 Hi Firstly apologies for the delay in replying, this is the first RFC draft I have been involved with and I was not sure of the process. You are correct the coded is a constant bit rate encoder and hence not vulnerable to the methods described in in the draft-ietf-avtcore-srtp-vbr-audio document. If its felt necessary a note to this affect can be added to the security considerations section. Regards John -----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi]=20 Sent: 05 December 2013 12:47 To: iesg@ietf.org; secdir@ietf.org; draft-ietf-payload-rtp-aptx.all@tools.ietf.org Subject: Secdir review of draft-ietf-payload-rtp-aptx-04 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 to transmit proprietary audio codec algorithms standard apt-X and enchanced apt-X in the RTP. The document has security considerations section which seems to be OK. If I have understood correctly the codec is constant bit rate codec, thus it is not vulnerable to the traffic analysis attacks described for example in the draft-ietf-avtcore-srtp-vbr-audio document. Perhaps the security considerations section could note that these codecs are not vulnerable to those attacks (if that is in deed true). -- kivinen@iki.fi From vincent.roca@inria.fr Tue Jan 21 06:42:57 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5136A1A0161; Tue, 21 Jan 2014 06:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.084 X-Spam-Level: X-Spam-Status: No, score=-7.084 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s_Jul-HXNyGA; Tue, 21 Jan 2014 06:42:55 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by ietfa.amsl.com (Postfix) with ESMTP id D426B1A014C; Tue, 21 Jan 2014 06:42:54 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,696,1384297200"; d="scan'208,217";a="54207257" Received: from eduroam-057014.grenet.fr ([130.190.57.14]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 21 Jan 2014 15:42:54 +0100 From: Vincent Roca Content-Type: multipart/alternative; boundary=Apple-Mail-60--308692148 Date: Tue, 21 Jan 2014 15:42:48 +0100 Message-Id: <9B3F20E5-7999-468D-8642-A9CAFA6C27DA@inria.fr> To: IESG , draft-ietf-6man-stable-privacy-addresses@tools.ietf.org, secdir@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [secdir] secdir review of draft-ietf-6man-stable-privacy-addresses-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 14:42:57 -0000 --Apple-Mail-60--308692148 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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. IMHO, the document is Almost ready. The document discusses security and privacy aspects and there is little = to add. I just have a couple of comments: - It is said: MD5 [RFC1321] and SHA-1 [FIPS-SHS] are two possible options for = F(). Although there is probably no harm in using MD5 in this context, it is probably not appropriate to explicitely mention it as an alternative given the known collision risks. Removing any reference to MD5 is probably wiser. Adding SHA-256 also... - The first bullet of Section 9 says: They prevent trivial host-tracking, since when a host moves from one network to another [...] the resulting Interface Identifier = will also change. There are many ways to track a device (or even a user across multiple = devices), e.g. in the Mobile OS context (Android, iOS...) that is one of the = targets of this document. So the above claim should be clarified a little bit IMHO, = highlighting the "trivial" idea. The benefits I see in having privacy preserving IPv6 addresses is that = it prevents an external attacker that analyzes flows captured in a backbone from linking a given device traffic before/after moves (especially if = the flow is encrypted). But of course it won't prevent an advertising and = analytics company to track a device if some higher level ID is used. Cheers, Vincent= --Apple-Mail-60--308692148 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
IMHO, the document is Almost = ready.


The = document discusses security and privacy aspects and there is little to = add.
I just have a couple of = comments:

- It is said:
    =   MD5 [RFC1321] and SHA-1 [FIPS-SHS] are two possible options for = F().
Although there is probably no harm in using MD5 in this = context, it is
probably not appropriate to explicitely mention = it as an alternative
given the known collision risks. Removing = any reference to MD5 is
probably wiser. Adding SHA-256 = also...


- The first bullet of = Section 9 says:
      They prevent trivial = host-tracking, since when a host moves from
    =   one network to another [...] the resulting = Interface Identifier will also change.
There are many = ways to track a device (or even a user across multiple = devices),
e.g. in the Mobile OS context (Android, iOS...) that = is one of the targets of this
document. So the above = claim should be clarified a little bit = IMHO, highlighting
the "trivial" idea.
The = benefits I see in having privacy preserving IPv6 addresses is that = it
prevents an external attacker that analyzes flows captured = in a backbone
from linking a given device traffic before/after = moves (especially if the flow
is encrypted). But of = course it won't prevent an advertising and = analytics
company to track a device if some higher = level ID is = used.

Cheers,


=
   Vincent
= --Apple-Mail-60--308692148-- From fgont@si6networks.com Tue Jan 21 08:00:58 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 354E31A0347; Tue, 21 Jan 2014 08:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXdmOZycTiyw; Tue, 21 Jan 2014 08:00:56 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id D296C1A01C0; Tue, 21 Jan 2014 08:00:50 -0800 (PST) Received: from 75-138-17-190.fibertel.com.ar ([190.17.138.75] helo=[192.168.3.102]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1W5dkr-00076C-W9; Tue, 21 Jan 2014 17:00:47 +0100 Message-ID: <52DE8B8B.4030905@si6networks.com> Date: Tue, 21 Jan 2014 12:00:27 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Vincent Roca , IESG , draft-ietf-6man-stable-privacy-addresses@tools.ietf.org, secdir@ietf.org References: <9B3F20E5-7999-468D-8642-A9CAFA6C27DA@inria.fr> In-Reply-To: <9B3F20E5-7999-468D-8642-A9CAFA6C27DA@inria.fr> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [secdir] secdir review of draft-ietf-6man-stable-privacy-addresses-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 16:00:58 -0000 Hi, Vincent, Thanks so muh for your review! Please find my comments inline... On 01/21/2014 11:42 AM, Vincent Roca wrote: > > The document discusses security and privacy aspects and there is little > to add. > I just have a couple of comments: > > - It is said: > MD5 [RFC1321] and SHA-1 [FIPS-SHS] are two possible options for F(). > Although there is probably no harm in using MD5 in this context, it is > probably not appropriate to explicitely mention it as an alternative > given the known collision risks. Removing any reference to MD5 is > probably wiser. Adding SHA-256 also... As you have correctly noted, MD5 is fine for this context. For instance, both RFC 6528 and RFC 6056 suggest the possible use of MD5 (and at the time we had this same exact discussion :-) ). Note that we do not require any specific hash function, since the choice always represents a tradeoff. > - The first bullet of Section 9 says: > They prevent trivial host-tracking, since when a host moves from > one network to another [...] the resulting Interface Identifier > will also change. > There are many ways to track a device (or even a user across multiple > devices), > e.g. in the Mobile OS context (Android, iOS...) that is one of > the targets of this > document. So the above claim should be clarified a little bit > IMHO, highlighting > the "trivial" idea. Maybe tweak the text to "...trivial host-tracking based on the IPv6 address"? > The benefits I see in having privacy preserving IPv6 addresses is that it > prevents an external attacker that analyzes flows captured in a backbone > from linking a given device traffic before/after moves (especially if > the flow is encrypted). But of course it won't prevent an advertising and analytics > company to track a device if some higher level ID is used. Clearly, this document aims to mitigate just host-tracking that is enabled by IPv6 addressing. But, as you correctly note, there might be other vectors (for instance, an attacker could have malware installed on the node he wants to track). Note, however, that tracking based on IP addresses wasn't really possible for IPv4.. and that the aforementioned tracking could be performed by just some guy that happens to run e.g. a web site you usually connect to. Thoughts? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From derek@ihtfp.com Tue Jan 21 09:32:36 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088A01A03F1; Tue, 21 Jan 2014 09:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gvtt2TSJ58C; Tue, 21 Jan 2014 09:32:33 -0800 (PST) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) by ietfa.amsl.com (Postfix) with ESMTP id 21EE81A042E; Tue, 21 Jan 2014 09:32:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 77BEEE247C; Tue, 21 Jan 2014 12:32:31 -0500 (EST) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 20908-10; Tue, 21 Jan 2014 12:32:29 -0500 (EST) Received: from mocana.ihtfp.org (unknown [IPv6:fe80::224:d7ff:fee7:8924]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 2B952E246B; Tue, 21 Jan 2014 12:32:29 -0500 (EST) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.7/8.14.7/Submit) id s0LHWOLL005539; Tue, 21 Jan 2014 12:32:24 -0500 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Date: Tue, 21 Jan 2014 12:32:24 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: aidan.williams@audinate.com, hans.stokking@tno.nl, avtcore-chairs@tools.ietf.org, kevin.gross@avanw.com, ray.vanbrandenburg@tno.nl Subject: [secdir] sec-dir review of draft-ietf-avtcore-clksrc-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 17:32:36 -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. NTP format timestamps are used by several RTP protocols for synchronisation and statistical measurements. This memo specifies SDP signalling identifying timestamp reference clock sources and SDP signalling identifying the media clock sources in a multimedia session. I see no security concerns with this document. I believe the security considerations section explains the ramifications of trusting unverified clock sources. Note, there is a typo in the Security Considerations section: Enough devices fraudulently assigned to a specific clock source (e.g. a particular IEEE 1588 grandmaster) may, however, constitute a successful a denial of service attack on that source. I think this should read "...constitute a successful denial..." (the extra "a" between "successful" and "denial" should be removed). -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From shawn.emery@oracle.com Tue Jan 21 10:08:12 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6894F1A0180; Tue, 21 Jan 2014 10:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utleH3r8vzUP; Tue, 21 Jan 2014 10:08:10 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 766221A011D; Tue, 21 Jan 2014 10:08:10 -0800 (PST) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s0LI87u1015796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Jan 2014 18:08:09 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s0LI86X5025894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 21 Jan 2014 18:08:07 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s0LI86BC017807; Tue, 21 Jan 2014 18:08:06 GMT Received: from [10.159.120.186] (/10.159.120.186) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 21 Jan 2014 10:08:05 -0800 Message-ID: <52DEB7D6.6050308@oracle.com> Date: Tue, 21 Jan 2014 11:09:26 -0700 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20131203 Thunderbird/17.0.6 MIME-Version: 1.0 To: secdir@ietf.org References: <526F612D.1020005@oracle.com> In-Reply-To: <526F612D.1020005@oracle.com> Content-Type: multipart/alternative; boundary="------------070007080705080201000805" X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: draft-ietf-isis-rfc6326bis.all@tools.ietf.org, iesg@ietf.org Subject: [secdir] Review of draft-ietf-isis-rfc6326bis-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 18:08:12 -0000 This is a multi-part message in MIME format. --------------070007080705080201000805 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 internet-draft intends to obsolete RFC 6326, which describes Transparent Interconnection of Lots of Links (TRILL) Use ofIntermediate System to Intermediate System (IS-IS). The security considerations section does exist and refers to the TRILL base protocol, RFC 6325, for its guidance. The section then states that the draft introduces no new security considerations when using IS-IS given that IS-IS authentication (as specified in RFC 5304 and 5310) can be used to secure its protocol messaging specified in the draft. I believe that this is true and don't see any other security concerns from what has been outlined and the changes from the base specification. General comments: None. Editorial comments: None. Shawn. -- --------------070007080705080201000805 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 internet-draft intends to obsolete RFC 6326, which describes Transparent Interconnection
of Lots of Links (TRILL) Use of Intermediate System to Intermediate System (IS-IS).

The security considerations section does exist and refers to the TRILL base protocol, RFC
6325, for its guidance.  The section then states that the draft introduces no new security
considerations when using IS-IS given that IS-IS authentication (as specified in RFC 5304 and 5310)
can be used to secure its protocol messaging specified in the draft.  I believe that this is true
and don't see any other security concerns from what has been outlined and the changes from the base
specification.

General comments:

None.

Editorial comments:

None.

Shawn.
--


    

  


--------------070007080705080201000805--

From shanna@juniper.net  Tue Jan 21 15:46:25 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16FED1A0263; Tue, 21 Jan 2014 15:46:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVqJSBC9GQzV; Tue, 21 Jan 2014 15:46:23 -0800 (PST)
Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id E8BCD1A0260; Tue, 21 Jan 2014 15:46:22 -0800 (PST)
Received: from mail134-co9-R.bigfish.com (10.236.132.252) by CO9EHSOBE025.bigfish.com (10.236.130.88) with Microsoft SMTP Server id 14.1.225.22; Tue, 21 Jan 2014 23:46:22 +0000
Received: from mail134-co9 (localhost [127.0.0.1])	by mail134-co9-R.bigfish.com (Postfix) with ESMTP id 6A7132A0251;	Tue, 21 Jan 2014 23:46:22 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: 1
X-BigFish: VPS1(zz4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzzz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h9a9j1155h)
Received-SPF: pass (mail134-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=shanna@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; 
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(189002)(199002)(164054003)(83072002)(79102001)(74876001)(93136001)(81342001)(74662001)(74502001)(54356001)(31966008)(81816001)(63696002)(47446002)(76176001)(76786001)(92566001)(65816001)(81542001)(53806001)(93516002)(2656002)(86362001)(81686001)(69226001)(87936001)(66066001)(76796001)(85852003)(90146001)(46102001)(56816005)(54316002)(33646001)(85306002)(74366001)(74706001)(74316001)(49866001)(77982001)(87266001)(80022001)(56776001)(76576001)(47736001)(83322001)(51856001)(76482001)(47976001)(80976001)(59766001)(4396001)(50986001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB740; H:BLUPR05MB737.namprd05.prod.outlook.com; CLIP:66.129.239.13; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; 
Received: from mail134-co9 (localhost.localdomain [127.0.0.1]) by mail134-co9 (MessageSwitch) id 1390347980469991_16598; Tue, 21 Jan 2014 23:46:20 +0000 (UTC)
Received: from CO9EHSMHS011.bigfish.com (unknown [10.236.132.229])	by mail134-co9.bigfish.com (Postfix) with ESMTP id 6DCE8E0048;	Tue, 21 Jan 2014 23:46:20 +0000 (UTC)
Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS011.bigfish.com (10.236.130.21) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 21 Jan 2014 23:46:20 +0000
Received: from BLUPR05MB740.namprd05.prod.outlook.com (10.141.208.28) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.395.1; Tue, 21 Jan 2014 23:46:19 +0000
Received: from BLUPR05MB737.namprd05.prod.outlook.com (10.141.208.17) by BLUPR05MB740.namprd05.prod.outlook.com (10.141.208.28) with Microsoft SMTP Server (TLS) id 15.0.851.15; Tue, 21 Jan 2014 23:46:18 +0000
Received: from BLUPR05MB737.namprd05.prod.outlook.com ([10.141.208.17]) by BLUPR05MB737.namprd05.prod.outlook.com ([10.141.208.17]) with mapi id 15.00.0851.011; Tue, 21 Jan 2014 23:46:18 +0000
From: Stephen Hanna 
To: "secdir@ietf.org" , The IESG , "draft-ietf-pcp-nat64-prefix64.all@tools.ietf.org" 
Thread-Topic: secdir Review of draft-ietf-pcp-nat64-prefix64-04
Thread-Index: Ac8XAvhsFQvpZlpNT8uP4E8QAIyyLQ==
Date: Tue, 21 Jan 2014 23:46:17 +0000
Message-ID: <1f794d77ca95458d9d7cf06e20950090@BLUPR05MB737.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.239.13]
x-forefront-prvs: 0098BA6C6C
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Subject: [secdir] secdir Review of draft-ietf-pcp-nat64-prefix64-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Jan 2014 23:46:25 -0000

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

This document defines a new PCP (Port Control Protocol) option
to learn the IPv6 prefix(es) used by a PCP-controlled NAT64
device to build IPv4-converted IPv6 addresses (known as
"Pref64::/n").

The Security Considerations for this draft are a good start
but they are missing some key information.

1) The second paragraph of the Security Considerations section
   points out that if an attacker can fool a host into using
   the wrong value for Pref64::/n, the traffic generated using
   that value will be delivered to the wrong location. That's
   right but not all the implications are mentioned. A MITM
   (Man In The Middle) attack can be performed in this manner,
   permitting alterations to the traffic (not just eavesdropping).
   This should be mentioned.

2) The next paragraph of the Security Considerations section
   suggests defenses to prevent the attacker from substituting
   the wrong value for Pref64::/n. However, the defense that
   is suggested (IP-based ACLs on the PCP server, client, or
   network) won't help much. Attackers can just place the
   PCP server's IP address in the source address of the fake
   PCP response packet sent by the attack. The nonce in the
   MAP or PEER response means that the attacker must capture
   or predict this value but no nonce is present in the ANNOUNCE
   response so that would probably be the preferred attack
   method, especially since ANNOUNCE responses can be sent
   out via multicast at any time. I suggest that the spec
   prohibit sending the PREFIX64 option in a multicast
   ANNOUNCE response, unless effective countermeasures for
   this attack are found.

In addition to these security issues, I found some other issues
that are not related to security:

1) You should explain that RFC 6146 defines Pref64::/n.
   Otherwise, that term is quite cryptic.

2) Several places in the document, you say that PREFIX64 is
   a PCP "extension". The PCP spec doesn't define what a PCP
   extension is. Say "PCP option" instead.

3) In section 3.2.1, say "synthesize" not "synthesizes".

4) In section 4.1 and several other places, the field Pref64
   is also called Prefix64. Come up with one name for the
   field and stick with it.

5) Split section 4.2 into Client Behavior and Server Behavior.
   The current text is too confusing. For example, the text at
   the bottom of page 7 is a confusing mishmash of server and
   client handling of multiple PREFIX64 options.

6) Text near the top of page 8 says "The PCP server can be
   configured with a customized IPv6 prefix list" but that
   won't work when PREFIX64 is added to a multicast ANNOUNCE
   response. That's another reason not to permit this, in
   addition to security issue 2) above.

7) When IPv4 prefix lists are configured and multiple IPv6
   prefix lists are also configured, the first PREFIX64
   option includes the IPv4 prefix lists. Can the later
   PREFIX64 options also include their own IPv4 prefix
   lists? If one or more of those later PREFIX64 options
   does NOT have its own IPv4 prefix list, what does that
   mean? Does it inherit the IPv4 prefix list of the
   previous PREFIX64 option? The current text is not clear.

8) The example in section 5.1 says that it "depicts a
   typical usage of the PREFIX64 option when a DNS64
   capability is embedded in the host." Did you mean
   "is not embedded"? I don't see how DNS64 is being
   used in this example.

9) Is this document still relevant? RFC 7051 says:

   Our conclusion is to recommend publishing the Well-Known DNS Name
   heuristic discovery-based method as a Standards Track IETF document
   for applications and host implementors to implement as-is.

   With that, is there still a need for this document?

I hope that you find these comments useful.

Thanks,

Steve



From zhangdacheng@huawei.com  Tue Jan 21 22:48:10 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E0D1A02E8; Tue, 21 Jan 2014 22:48:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.735
X-Spam-Level: 
X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cA4Vu0SJ9Yvy; Tue, 21 Jan 2014 22:48:07 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7441A02DD; Tue, 21 Jan 2014 22:48:05 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCT87475; Wed, 22 Jan 2014 06:48:04 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 22 Jan 2014 06:46:59 +0000
Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 22 Jan 2014 06:47:59 +0000
Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.75]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Wed, 22 Jan 2014 14:47:54 +0800
From: "Zhangdacheng (Dacheng)" 
To: "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-ancp-mc-extensions.all@tools.ietf.org" 
Thread-Topic: [secdir] secdir review of draft-ietf-ancp-mc-extensions-14
Thread-Index: Ac8XPd+LcI+ULRdMSv6oBbGFFsLvBw==
Date: Wed, 22 Jan 2014 06:47:53 +0000
Message-ID: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.139]
Content-Type: multipart/alternative; boundary="_000_C72CBD9FE3CA604887B1B3F1D145D05E3B4292C2nkgeml507mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: [secdir]  secdir review of draft-ietf-ancp-mc-extensions-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jan 2014 06:48:10 -0000

--_000_C72CBD9FE3CA604887B1B3F1D145D05E3B4292C2nkgeml507mbschi_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

SGVsbG+jug0KDQoNCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhl
IHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRG
IGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuICBUaGVzZSBjb21tZW50cyB3
ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJl
YSBkaXJlY3RvcnMuICBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0
IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0K
DQpUaGlzIGRyYWZ0IHNwZWNpZmllcyB0aGUgZXh0ZW5zaW9ucyB0byB0aGUgQWNjZXNzIE5vZGUg
Q29udHJvbCBQcm90b2NvbCBbUkZDNjMyMF0gcmVxdWlyZWQgZm9yIHN1cHBvcnQgb2YgdGhlIG11
bHRpY2FzdCB1c2UgY2FzZXMgcHJvcG9zZWQgaW4gW1JGQzU4NTFdLg0KDQpUaGlzIGh1Z2UgZG9j
dW1lbnQgaXMgd2VsbCB3cml0dGVuLiBUaGUgYXV0aG9ycyBtdXN0IGhhdmUgc3BlbnQgbXVjaCBl
bmVyZ3kgb24gdGhpcyB3b3JrLg0KDQpGb2xsb3dzIGFyZSBzb21lIHF1ZXN0aW9ucyBhbmQgY29t
bWVudHM6DQoNCjEpDQoNCkluIHRoZSBpbnRyb2R1Y3Rpb24sIHRoZXJlIGlzIGEgc3RhdGVtZW50
IKGwQ29uZGl0aW9uYWwgYWNjZXNzIGlzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuNC4xIGFuZCBT
ZWN0aW9uIDMuNC4yLjMgb2YgW1JGQzU4NTFdLCB3aXRoIHRoZSBsYXR0ZXIgc2VjdGlvbiBwYXJ0
aWN1bGFybHkgYXBwbGljYWJsZSB0byBvcGVyYXRpb24gd2l0aCB3aGl0ZSBhbmQgYmxhY2sgbGlz
dHMgb25seaGxDQoNClNlY3Rpb24gMy40LjIuMyBvZiBSRkM1ODUxIGFjdHVhbGx5IGRpc2N1c3Nl
cyBob3cgYWRtaXNzaW9uIGNvbnRyb2wgbWF5IGRlZmVhdCB0aGUgcHVycG9zZSBvZiB1c2luZyBh
IHdoaXRlIGFuZCBibGFjayBsaXN0LiBTbywgSSBzdWdnZXN0IHJlLXdyaXRpbmcgdGhpcyB0ZXh0
Lg0KDQoyKQ0KDQpJdCB3b3VsZCBtYWtlIHRoZSBkb2N1bWVudCBlYXNpZXIgdG8gdW5kZXJzdGFu
ZCBpZiB0aGUga2V5IHRlcm1zIGNhbiBiZSBjbGVhcmx5IGludHJvZHVjZWQuIFNvLCBJIHN1Z2dl
c3QgcmVmaW5pbmcgU2VjdGlvbiAyLg0KDQpJbiBkZXRhaWxzLCB0ZXJtcyBzdWNoIGFzIKGwQ29u
ZGl0aW9uYWwgQWNjZXNzobEsIKGwYWRtaXNzaW9uIGNvbnRyb2yhsSwgYW5kICJjb25kaXRpb25h
bCBhY2Nlc3MgYW5kIGFkbWlzc2lvbiBjb250cm9sIChDQUMpIiBhcmUgd2lkZWx5IHVzZWQgaW4g
dGhpcyBkcmFmdC4gSW4gYWRkaXRpb24sIHRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHRoYXQgY29u
ZGl0aW9uYWwgYWNjZXNzIGFuZCBhZG1pc3Npb24gY29udHJvbCBjYW4gY29uc2lzdCBvZiB0d28g
cGFydHM6IHBvbGljeS1iYXNlZCBhZG1pc3Npb24gY29udHJvbCBhbmQgcmVzb3VyY2UtYmFzZWQg
YWRtaXNzaW9uIGNvbnRyb2wuIEhvd2V2ZXIsIHRoZXJlIGlzIG5vIGNsZWFyIGRlZmluaXRpb24g
cHJvdmlkZWQgYWJvdXQgdGhvc2UgdGVybXMuDQoNCkFjY29yZGluZyB0byBSRkM1ODUxLCBjb25k
aXRpb25hbCBhY2Nlc3MgY2FuIHVzZSB3aGl0ZSwgYmFjaywgYW5kIGdyZXkgbGlzdHMgdG8gbWFu
YWdlIHRoZSBnZW5lcmF0aW9uIG9mIG11bHRpY2FzdCBmbG93cywgd2hpbGUgYWRtaXNzaW9uIGNv
bnRyb2wgaXMgdXNlZCBpbiB0aGUgY2FzZXMgd2hlcmUgdGhlIGJhbmR3aWR0aCByZXNlcnZhdGlv
biBmb3IgbmV3bHkgZ2VuZXJhdGVkIGZsb3dzIGlzIHJlcXVpcmVkLg0KDQpTbywgaXQgc2hvdWxk
IGJlIGNsYXJpZmllZCB3aGV0aGVyIHRoZXJlIGlzIGFueSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0
aGUgYWRtaXNzaW9uIGNvbnRyb2wgaW4gUkZDNTg1MSwgYW5kIHRoZSBwb2xpY3ktYmFzZWQgYWRt
aXNzaW9uIGNvbnRyb2wgYW5kIHJlc291cmNlLWJhc2VkIGFkbWlzc2lvbiBjb250cm9sIHByb3Bv
c2VkIGluIHRoaXMgZG9jdW1lbnQuIEV4YW1wbGVzIHdpbGwgaGVscCBhIGxvdC4NCg0KSW4gYWRk
aXRpb24sIGluIFJGQyA1ODUxLCBDQUMgaXMgYW4gYWJicmV2aWF0aW9uIG9mIENvbm5lY3Rpb24g
QWRtaXNzaW9uIENvbnRyb2wuIFRoaXMgbWF5IGNhdXNlIGNvbmZ1c2luZy4NCg0KDQoNCjMpDQoN
CkluIHNlY3Rpb24gNC4xLjEsIHRoZXJlIGlzIGEgc3RhdGVtZW50IKGwVGhlIE5BUyBTSE9VTEQg
Tk9UIGluY2x1ZGUgYW55IGxpc3QgdHlwZSAod2hpdGUsIGJsYWNrLCBvciBncmV5KSB0aGF0IGlz
IG5vdCBzdXBwb3J0ZWQgYnkgdGhlIHNldCBvZiBtdWx0aWNhc3QgY2FwYWJpbGl0aWVzIG5lZ290
aWF0ZWQgYmV0d2VlbiB0aGUgTkFTIGFuZCB0aGUgQU4uobEgSW4gc2VjdGlvbiA0LjEuMiwgdGhl
cmUgaXMgYSBjb3JyZXNwb25kaW5nIHN0YXRlbWVudCChsEluIGtlZXBpbmcgd2l0aCB0aGUgZ2Vu
ZXJhbCBydWxlIHN0YXRlZCBpbiBTZWN0aW9uIDQsIHRoZSBBTiBNVVNUIGlnbm9yZSBpbnN0YW5j
ZXMgb2YgdGhlIExpc3QtQWN0aW9uIFRMViByZWZlcnJpbmcgdG8gYW55IGxpc3QgdHlwZSAod2hp
dGUsIGJsYWNrLCBvciBncmV5KSB0aGF0IGlzIG5vdCBzdXBwb3J0ZWQgYnkgdGhlIHNldCBvZiBt
dWx0aWNhc3QgY2FwYWJpbGl0aWVzIG5lZ290aWF0ZWQgYmV0d2VlbiB0aGUgTkFTIGFuZCB0aGUg
QU4uobENCg0KU28sIEkgc3VnZ2VzdCB1c2luZyChsE1VU1ShsSB0byB0YWtlIHBsYWNlIG9mIKGw
U0hPVUxEobEgaW4gdGhlIGZpcnN0IHN0YXRlbWVudCB1bmxlc3Mgd2UgY2FuIGZpbmQgb3V0IGEg
c2NlbmFyaW8gd2hlcmUgdGhlIE5BUyBuZWVkcyB0byBzZW5kIG91dCBhIFRMViB3aGljaCBpcyBu
b3Qgc3VwcG9ydGVkIGJ5IHRoZSBBTiBhbmQgd2lsbCBiZSBldmVudHVhbGx5IGRpc2NhcmRlZC4N
Cg0KDQoNCjQpDQoNClNlY3Rpb24gNi4xLjMgbGlzdHMgdGhlIHByb3RvY29sIGVsZW1lbnRzIHRo
YXQgTVVTVCBiZSBpbXBsZW1lbnRlZCB0byBzdXBwb3J0IHRoZSBjb25kaXRpb25hbCBhY2Nlc3Mg
d2l0aCB3aGl0ZSBhbmQgYmxhY2sgbGlzdHMgbXVsdGljYXN0IGNhcGFiaWxpdHkuIEkgZm91bmQg
V2hpdGUtTGlzdC1DQUMgVExWIGlzIGluY2x1ZGVkIGluIHRoZSBsaXN0LiBIb3dldmVyLCB0aGUg
V2hpdGUtTGlzdC1DQUMgVExWIGlzIHVzZWQgdG8gaW5kaWNhdGUgdGhhdCB0aGUgTkFTIHdpc2hl
cyB0aGUgQU4gdG8gZG8gYWRtaXNzaW9uIGNvbnRyb2wgZm9yIHdoaXRlLWxpc3RlZCBmbG93cywg
YW5kIHRoaXMgdXNlIGNhc2UgaXMgZGlzY3Vzc2VkIGluIFNlY3Rpb24gMy40LjIuMyBvZiBSRkMg
NTg1MSChsE11bHRpY2FzdCBBZG1pc3Npb24gQ29udHJvbCBhbmQgV2hpdGUgTGlzdHOhsS4gU28s
IEkgZG91YnQgd2hldGhlciB0aGlzIFRMViBuZWVkcyB0byBiZSBzdXBwb3J0ZWQgaXMgdGhpcyBj
YXNlLg0KDQo1KQ0KDQpTZWN0aW9uIDQuMS4yLCBpdCBpcyBzdGF0ZWQgobBUaGUgYnVmZmVyaW5n
IHRpbWUgc3BlY2lmaWVkIGluIGFuIGluc3RhbmNlIG9mIHRoZSBSZXBvcnQtQnVmZmVyaW5nLSBU
aW1lIFRMViBhcHBsaWVzIG9ubHkgdG8gQ29tbWl0dGVkIEJhbmR3aWR0aCBSZXBvcnQgbWVzc2Fn
ZXMgaW5pdGlhdGVkIGFmdGVyIHRoZSBuZXcgYnVmZmVyaW5nIHRpbWUgaXMgcmVjZWl2ZWQgYXQg
dGhlIEFOLCBub3QgdG8gYW55IG1lc3NhZ2UgYWxyZWFkeSBpbiB0aGUgcHJvY2VzcyBvZiBhY2N1
bXVsYXRpb24gLqGxDQoNClRoaXMgcG9saWN5IGluZGljYXRlcyBhbiBpbXBsZW1lbnRhdGlvbiBt
YXkgaGF2ZSB0byBtYWludGFpbiB0d28gb3IgbXVsdGlwbGUgYWNjdW11bGF0aW9uIHByb2Nlc3Nl
cyB3aGVuIE5BUyBmcmVxdWVudGx5IHNlbmRzIHRoZSBSZXBvcnQtQnVmZmVyaW5nLSBUaW1lIFRM
VnMgdG8gdGhlIEFOIGFuZCB0aGVuIGNoYW5nZXMgdGhlIGJ1ZmZlcmluZyB0aW1lLiBUaGlzIG1h
eSBub3QgcmVzdWx0IGluIHNlcmlvdXMgc2VjdXJpdHkgcHJvYmxlbSBidXQgd2lsbCBpbnRyb2R1
Y2UgbW9yZSBjb21wbGV4aXR5IGluIHRoZSBzeXN0ZW0gaW1wbGVtZW50YXRpb24uIFNvLCBJIHN1
Z2dlc3QgY2hhbmdpbmcgdGhlIHRleHQgdG8gobBUaGUgYnVmZmVyaW5nIHRpbWUgc3BlY2lmaWVk
IGluIGFuIGluc3RhbmNlIG9mIHRoZSBSZXBvcnQtQnVmZmVyaW5nLSBUaW1lIFRMViB3aWxsIG5v
dCBiZSBhcHBsaWVkIHVudGlsIHRoZSBjdXJyZW50IGFjY3VtdWxhdGlvbiBwcm9jZXNzIG9mIENv
bW1pdHRlZCBCYW5kd2lkdGggUmVwb3J0IG1lc3NhZ2VzIGZpbmlzaGVzLqGxDQoNCjYpDQoNCklu
IHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9uLCB0aGUgaXNzdWVzIHdpdGggdGhlIGF0dGFja3Mg
b24gdGhlIGNvbW11bmljYXRpb24gY2hhbm5lbCBiZXR3ZWVuIEFBQSBhbmQgTkFTIGlzIG5vdCBz
dWZmaWNpZW50LiBJdCBpcyBtZW50aW9uZWQgaW4gdGhpcyBzZWN0aW9uIHRoYXQgaXQgaXMgcG9z
c2libGUgdG8gZG93bmxvYWQgcGVyLSBkZXZpY2UgcG9saWN5IHRvIHRoZSBOQVMgZGlyZWN0bHkg
c28gYXMgdG8gZWxpbWluYXRlIHRoZSBjb21tdW5pY2F0aW9uIGJldHdlZW4gTkFTIGFuZCBBQUEu
IEkgYWdyZWUgdGhpcyBpcyBhbiBvcHRpb24uIEhvd2V2ZXIsIEkgYmVsaWV2ZSBpdCBpcyBzdGls
bCB3b3J0aHdoaWxlIGZvciB1cyB0byBkaXNjdXNzIGhvdyB0byBzZWN1cmUgdGhlIGNvbW11bmlj
YXRpb24gYmV0d2VlbiBOQVMgYW5kIEFBQS4NCg0KDQoNCk5pdHM6DQoNCjEpICAgICAgIFNlY3Rp
b24gNC4xLjI6IEluIGtlZXBpbmcgd2l0aCB0aGUgZ2VuZXJhbCBydWxlIHN0YXRlZCBpbiBTZWN0
aW9uIDQgLT4gSW4ga2VlcGluZyB3aXRoIHRoZSBnZW5lcmFsIHJ1bGUgc3RhdGVkIGluIFNlY3Rp
b24gNC4xLjENCg0KVHlwb3M6DQoNClNlY3Rpb24gNC40OiAgICAgIGZpcnN0IGRpcmVjdGl2ZSB0
aGF0IGNhbiBub3QgLT4gZmlyc3QgZGlyZWN0aXZlIHRoYXQgY2Fubm90DQoNClNlY3Rpb24gNzog
ICAgICAgICAgICAgICAgICAgQW4gYXR0YWNrZXIgYWJsZSB0byB0byAtPiBBbiBhdHRhY2tlciBh
YmxlIHRvDQoNCkNoZWVycw0KDQpEYWNoZW5nDQo=

--_000_C72CBD9FE3CA604887B1B3F1D145D05E3B4292C2nkgeml507mbschi_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable











Hello=A3=BA<=
/p>

 


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



=
This draft specifies the extensions to the Access Node Control Protocol [RF=
C6320] required for support of the multicast use cases proposed in [RFC5851=
].


=
This huge document is well written. The authors must have spent much energy=
 on this work.



=
Follows are some questions and comments:


=
1)


=
In the introduction, there is a statement
=
=A1=B0Conditional access is described in Sectio=
n 3.4.1 and Section 3.4.2.3 of [RFC5851], with the latter section particula=
rly applicable to operation with white and black lists
 only=A1=B1


=
Section 3.4.2.3 of RFC5851 actually discusses how admission control may def=
eat the purpose of using a white and black list. So, I suggest re-writing t=
his text.



=
2)


=
It would make the document easier to understand if the key terms can be cle=
arly introduced. So, I suggest refining Section 2.



=
In details, terms such as
=
=A1=B0Conditional Access=A1=B1,
=
=A1=B0admission control=A1=B1, and "conditional access and admission control (CAC)"=
 are widely
 used in this draft. In addition, this document specifies that conditional =
access and admission control can consist of two parts: policy-based admissi=
on control and resource-based admission control. However, there is no clear=
 definition provided about those
 terms. 


=
According to RFC5851, conditional access can use white, back, and grey list=
s to manage the generation of multicast flows, while admission control is u=
sed in the cases where the bandwidth reservation
 for newly generated flows is required. 


=
So, it should be clarified whether there is any relationship between the ad=
mission control in RFC5851, and the policy-based admission control and reso=
urce-based admission control proposed
 in this document. Examples will help a lot. 


=
In addition, in RFC 5851, CAC is an abbreviation of Connection Admission Co=
ntrol. This may cause confusing.


=
 


3)


=
In section 4.1.1, there is a statement
=
=A1=B0The NAS SHOULD NOT include any list type =
(white, black, or grey) that is not supported by the set of multicast capab=
ilities negotiated between the NAS and the AN.=A1=B1
 In section 4.1.2, there is a corresponding statement =A1=B0In keeping with the general rule stated in Section 4, the AN MU=
ST ignore instances of the List-Action TLV referring
 to any list type (white, black, or grey) that is not supported by the set =
of multicast capabilities negotiated between the NAS and the AN.=A1=B1


=
So, I suggest using
=
=A1=B0MUST=A1=B1 to =
take place of
=
=A1=B0SHOULD=A1=B1=
 in the first statement unless we can find out a scenario where the NAS nee=
ds
 to send out a TLV which is not supported by the AN and will be eventually =
discarded.


 


4) 


=
Section 6.1.3 lists the protocol elements that MUST be implemented to suppo=
rt the conditional access with white and black lists multicast capability. =
I found White-List-CAC TLV is included
 in the list. However, the White-List-CAC TLV is used to indicate that the =
NAS wishes the AN to do admission control for white-listed flows, and this =
use case is discussed in Section 3.4.2.3 of RFC 5851
=
=A1=B0Multicast Admission Control and White Lis=
ts=A1=B1. So, I doubt whether this TLV needs to
 be supported is this case.


 


5)


 


Section 4.1.2, it is stated =A1=B0=
The buffering time specified in an instance of the Report-Buffering- Time T=
LV applies only to Committed Bandwidth Report messages initiated after the =
new buffering time is received at the AN,
 not to any message already in the process of accumulation .=A1=B1


 


This policy indicates an implement=
ation may have to maintain two or multiple accumulation processes when NAS =
frequently sends the Report-Buffering- Time TLVs to the AN and then changes=
 the buffering time. This may not result
 in serious security problem but will introduce more complexity in the syst=
em implementation. So, I suggest changing the text to =A1=B0The buffering t=
ime specified in an instance of the Report-Buffering- Time TLV will not be =
applied until the current accumulation
 process of Committed Bandwidth Report messages finishes.=A1=B1 =



 


6)


=
In the security consideration, the issues with the attacks on the communica=
tion channel between AAA and NAS is not sufficient. It is mentioned in this=
 section that it is possible to download
 per- device policy to the NAS directly so as to eliminate the communicatio=
n between NAS and AAA. I agree this is an option. However, I believe it is =
still worthwhile for us to discuss how to secure the communication between =
NAS and AAA.


=
 


=
Nits:



1=
)   &=
nbsp;  
Section 4.1.2: In keepi=
ng with the general rule stated in Section 4 -> In keeping with the gene=
ral rule stated in Section 4.1.1


=
Typos:


=
Section 4.4:      first directive that can not -&g=
t; first directive that cannot


=
Section 7:           =
;        An attacker able to to -> An=
 attacker able to


 


Cheers


 


Dacheng






--_000_C72CBD9FE3CA604887B1B3F1D145D05E3B4292C2nkgeml507mbschi_--

From vincent.roca@inria.fr  Tue Jan 21 23:52:01 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1534D1A0379; Tue, 21 Jan 2014 23:52:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.085
X-Spam-Level: 
X-Spam-Status: No, score=-7.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWyfCTynGbkN; Tue, 21 Jan 2014 23:51:58 -0800 (PST)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA7E1A0376; Tue, 21 Jan 2014 23:51:57 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.95,698,1384297200"; d="scan'208";a="45664414"
Received: from demeter.inrialpes.fr ([194.199.24.102]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 22 Jan 2014 08:51:57 +0100
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Vincent Roca 
In-Reply-To: <52DE8B8B.4030905@si6networks.com>
Date: Wed, 22 Jan 2014 08:51:56 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <643D6B3C-607D-416D-9D1F-A5CB0631BA52@inria.fr>
References: <9B3F20E5-7999-468D-8642-A9CAFA6C27DA@inria.fr> <52DE8B8B.4030905@si6networks.com>
To: Fernando Gont 
X-Mailer: Apple Mail (2.1085)
Cc: secdir@ietf.org, IESG , draft-ietf-6man-stable-privacy-addresses@tools.ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-6man-stable-privacy-addresses-16
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jan 2014 07:52:01 -0000

Hello Fernando,

> Thanks so muh for your review! Please find my comments inline...
>=20
>=20
> On 01/21/2014 11:42 AM, Vincent Roca wrote:
>>=20
>> The document discusses security and privacy aspects and there is =
little
>> to add.
>> I just have a couple of comments:
>>=20
>> - It is said:
>>      MD5 [RFC1321] and SHA-1 [FIPS-SHS] are two possible options for =
F().
>> Although there is probably no harm in using MD5 in this context, it =
is
>> probably not appropriate to explicitely mention it as an alternative
>> given the known collision risks. Removing any reference to MD5 is
>> probably wiser. Adding SHA-256 also...
>=20
> As you have correctly noted, MD5 is fine for this context. For =
instance,
> both RFC 6528 and RFC 6056 suggest the possible use of MD5 (and at the
> time we had this same exact discussion :-) ).
>=20
> Note that we do not require any specific hash function, since the =
choice
> always  represents a tradeoff.

I understand all of this. But there's a desire to get rid of MD5!
I've just been through IESG records, and non surprisingly Stephen
made the same comment.


>> - The first bullet of Section 9 says:
>>      They prevent trivial host-tracking, since when a host moves from
>>      one network to another [...] the resulting Interface Identifier
>> will also change.
>> There are many ways to track a device (or even a user across multiple
>> devices),
>> e.g. in the Mobile OS context (Android, iOS...) that is one of
>> the targets of this
>> document. So the above claim should be clarified a little bit
>> IMHO, highlighting > the "trivial" idea.
>=20
> Maybe tweak the text to "...trivial host-tracking based on the IPv6
> address"?

Agreed.


>> The benefits I see in having privacy preserving IPv6 addresses is =
that it
>> prevents an external attacker that analyzes flows captured in a =
backbone
>> from linking a given device traffic before/after moves (especially if
>> the flow is encrypted). But of course it won't prevent an advertising =
and analytics
>> company to track a device if some higher level ID is used.
>=20
> Clearly, this document aims to mitigate just host-tracking that is
> enabled by IPv6 addressing. But, as you correctly note, there might be
> other vectors (for instance, an attacker could have malware installed =
on
> the node he wants to track). Note, however, that tracking based on IP
> addresses wasn't really possible for IPv4.. and that the =
aforementioned
> tracking could be performed by just some guy that happens to run e.g. =
a
> web site you usually connect to.
>=20
> Thoughts?

Privacy preserving IPv6 addresses are important, clearly and I won't
question it. But there are so many tracking technics widely used
today (I don't know if you're familiar with smartphone tracking, but
you can have a look at: http://www.flurry.com/big-data.html
and this is only a subset of the visible part).
The difference I see is what I've mentioned: IPv6 address tracking
facilitates tracking within the core network, just by analyzing the =
outer
IP header, even if the content is encrypted. It's good to protect from
this attack.

BTW, I'm not suggesting that this discussion needs to be summarized
in the document.

Cheers,

   Vincent=

From tlyu@mit.edu  Wed Jan 22 19:15:47 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7851A00BF; Wed, 22 Jan 2014 19:15:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.136
X-Spam-Level: 
X-Spam-Status: No, score=-3.136 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sa3pFR57YUZU; Wed, 22 Jan 2014 19:15:46 -0800 (PST)
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 ED13E1A00CD; Wed, 22 Jan 2014 19:15:45 -0800 (PST)
X-AuditID: 12074422-f79526d000000c47-37-52e089612335
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id BF.4D.03143.16980E25; Wed, 22 Jan 2014 22:15:45 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s0N3FgMm023853; Wed, 22 Jan 2014 22:15:44 -0500
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.8/8.12.4) with ESMTP id s0N3Fek8026464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Jan 2014 22:15:41 -0500
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id s0N3FdEX016300; Wed, 22 Jan 2014 22:15:39 -0500 (EST)
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-abfab-arch.all@tools.ietf.org
From: Tom Yu 
Date: Wed, 22 Jan 2014 22:15:39 -0500
Message-ID: 
Lines: 28
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLIsWRmVeSWpSXmKPExsUixG6nrpvY+SDIYMc9Nou1a06xWMz4M5HZ 4sPChywOzB5Llvxk8vhy+TNbAFMUl01Kak5mWWqRvl0CV8akmT/ZCtq4K67sPMbawNjD2cXI ySEhYCLRfHMNO4QtJnHh3nq2LkYuDiGB2UwS5x9cgnI2Mkq8ObKLEcI5xyRxdcEaJpAWIYEu Romze1RAbBEBH4mNk+aCxYUFjCReL/sK1MDBwSYgLXF0cRlImEVAVeLxwQeMIDavgIXE3xPP wWweAU6J48umsUPEBSVOznzCAmIzC2hJ3Pj3kmkCI98sJKlZSFILGJlWMcqm5Fbp5iZm5hSn JusWJyfm5aUW6Zrq5WaW6KWmlG5iBIeai9IOxp8HlQ4xCnAwKvHwJny5HyTEmlhWXJl7iFGS g0lJlHdy+4MgIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8J5OAcrwpiZVVqUX5MClpDhYlcd5b HPZBQgLpiSWp2ampBalFMFkZDg4lCV6hDqBGwaLU9NSKtMycEoQ0EwcnyHAeoOFfQRbzFhck 5hZnpkPkTzEqSonz+oAkBEASGaV5cL2wVPCKURzoFWHePyBVPMA0Atf9CmgwE9Dg6C33QAaX JCKkpBoY1bL3GdYytNxvW3bsu9D+fUqX+d5XFyyrdz/J4/QtRFrfsj6m80l4oHXD8urTe65/ 2O0e/ubQojCeJesf7zacr1jr8+KBrcf9i9wbpgX73ynb8/fI7CkHCs/ZOt/r3HR1gZzevfKy OR66n+Z9fyDY+mvqQUFxi2fBW3lZckXq/lVHL0gyE6iXV2Ipzkg01GIuKk4EAJXOmIXgAgAA
Subject: [secdir] secdir review of draft-ietf-abfab-arch-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Jan 2014 03:15:48 -0000

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

Summary: ready with issues

The Security Considerations (section 5) appears incomplete.  The
next-to-last paragraph of the Security Considerations text is:

   Partial list of issues to be addressed in this section: Privacy,
   SAML, Trust Anchors, EAP Algorithm Selection, Diameter/RADIUS/AAA
   Issues, Naming of Entities, Protection of passwords, Channel Binding,
   End-point-connections (TLS), Proxy problems

The bulk of the Security Considerations adequately describes the
security properties of the different communication channels.  Section
4 is Privacy Considerations, so maybe just make a cross-reference to
it in Security Considerations?  If the other listed "to be addressed"
security considerations are already described elsewhere in the
document, possibly summarize them in section 5 and provide
cross-references?

The final paragraph of section 5 describes privacy considerations
related to reverse engineering of pseudonyms, but this text seems to
be logically disconnected from the rest of the section.  Maybe it
belongs in section 4?

From mohamed.boucadair@orange.com  Thu Jan 23 07:00:10 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 225A71A0439; Thu, 23 Jan 2014 07:00:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.549
X-Spam-Level: 
X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2h3wVfIpSi8; Thu, 23 Jan 2014 07:00:07 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 120211A0114; Thu, 23 Jan 2014 07:00:06 -0800 (PST)
Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 6B3552ACB20; Thu, 23 Jan 2014 16:00:05 +0100 (CET)
Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 439BD180051; Thu, 23 Jan 2014 16:00:05 +0100 (CET)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Thu, 23 Jan 2014 16:00:04 +0100
From: 
To: Stephen Hanna , "secdir@ietf.org" , The IESG , "draft-ietf-pcp-nat64-prefix64.all@tools.ietf.org" 
Date: Thu, 23 Jan 2014 16:00:04 +0100
Thread-Topic: secdir Review of draft-ietf-pcp-nat64-prefix64-04
Thread-Index: Ac8XAvhsFQvpZlpNT8uP4E8QAIyyLQBPUUuA
Message-ID: <94C682931C08B048B7A8645303FDC9F36F4736024C@PUEXCB1B.nanterre.francetelecom.fr>
References: <1f794d77ca95458d9d7cf06e20950090@BLUPR05MB737.namprd05.prod.outlook.com>
In-Reply-To: <1f794d77ca95458d9d7cf06e20950090@BLUPR05MB737.namprd05.prod.outlook.com>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.23.72115
Subject: Re: [secdir] secdir Review of draft-ietf-pcp-nat64-prefix64-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Jan 2014 15:00:10 -0000

Dear Stephen,

Thank you for the review.=20

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De=A0: Stephen Hanna [mailto:shanna@juniper.net]
>Envoy=E9=A0: mercredi 22 janvier 2014 00:46
>=C0=A0: secdir@ietf.org; The IESG; draft-ietf-pcp-nat64-
>prefix64.all@tools.ietf.org
>Objet=A0: secdir Review of draft-ietf-pcp-nat64-prefix64-04
>
>I have reviewed this document as part of the security directorate's
>ongoing effort to review all IETF documents being processed by the IESG.
>These comments were written primarily for the benefit of the security
>area directors. Document editors and WG chairs should treat these
>comments just like any other last call comments.
>
>This document defines a new PCP (Port Control Protocol) option
>to learn the IPv6 prefix(es) used by a PCP-controlled NAT64
>device to build IPv4-converted IPv6 addresses (known as
>"Pref64::/n").
>
>The Security Considerations for this draft are a good start
>but they are missing some key information.
>
>1) The second paragraph of the Security Considerations section
>   points out that if an attacker can fool a host into using
>   the wrong value for Pref64::/n, the traffic generated using
>   that value will be delivered to the wrong location. That's
>   right but not all the implications are mentioned. A MITM
>   (Man In The Middle) attack can be performed in this manner,
>   permitting alterations to the traffic (not just eavesdropping).
>   This should be mentioned.
[Med] I updated the text as follows:

OLD:

   As discussed in [RFC6147], if an attacker can manage to change the
   Pref64::/n used by the DNS64 function, the traffic generated by the
   host that receives the synthetic reply will be delivered to the
   altered Pref64.  This can result in either a denial-of-service (DoS)
   attack, a flooding attack, or an eavesdropping attack.  This attack
   could be achieved either by altering PCP messages issued by a
   legitimate PCP server or by using a fake PCP server.

NEW:

   As discussed in [RFC6147], if an attacker can manage to change the
   Pref64::/n used by the DNS64 function, the traffic generated by the
   host that receives the synthetic reply will be delivered to the
   altered Pref64.  This can result in either a denial-of-service (DoS)
   attack, a flooding attack, or a MIM (Man In The Middle) attack.  This at=
tack
   could be achieved either by altering PCP messages issued by a
   legitimate PCP server or by using a fake PCP server.

Better?

>
>2) The next paragraph of the Security Considerations section
>   suggests defenses to prevent the attacker from substituting
>   the wrong value for Pref64::/n. However, the defense that
>   is suggested (IP-based ACLs on the PCP server, client, or
>   network) won't help much. Attackers can just place the
>   PCP server's IP address in the source address of the fake
>   PCP response packet sent by the attack.=20

[Med] anti-spoofing filters can be used to prevent such attack. Ingress fil=
ters can be also enforced at boundaries of a domain to prevent such attack.=
 I do think the text is still correct.

The nonce in the
>   MAP or PEER response means that the attacker must capture
>   or predict this value but no nonce is present in the ANNOUNCE
>   response so that would probably be the preferred attack
>   method, especially since ANNOUNCE responses can be sent
>   out via multicast at any time. I suggest that the spec
>   prohibit sending the PREFIX64 option in a multicast
>   ANNOUNCE response, unless effective countermeasures for
>   this attack are found.
[Med] Isn't this covered by this text:

"   Means to defend against attackers who can modify packets between the
   PCP server and the PCP client, or who can inject spoofed packets that
   appear to come from a legitimate PCP server SHOULD be enabled."

>
>In addition to these security issues, I found some other issues
>that are not related to security:
>
>1) You should explain that RFC 6146 defines Pref64::/n.
>   Otherwise, that term is quite cryptic.
[Med] I added this new sentence:=20

   According to [RFC6146], NAT64 uses Pref64::/n to construct
   IPv4-Converted IPv6 addresses as defined in [RFC6052].

Better?

>
>2) Several places in the document, you say that PREFIX64 is
>   a PCP "extension". The PCP spec doesn't define what a PCP
>   extension is. Say "PCP option" instead.
[Med] Fixed.

>
>3) In section 3.2.1, say "synthesize" not "synthesizes".
[Med] Thanks for catching it. Fixed.

>
>4) In section 4.1 and several other places, the field Pref64
>   is also called Prefix64. Come up with one name for the
>   field and stick with it.
[Med] Fixed.=20

>
>5) Split section 4.2 into Client Behavior and Server Behavior.
>   The current text is too confusing. For example, the text at
>   the bottom of page 7 is a confusing mishmash of server and
>   client handling of multiple PREFIX64 options.
[Med] Will consider this suggestion.=20

>
>6) Text near the top of page 8 says "The PCP server can be
>   configured with a customized IPv6 prefix list" but that
>   won't work when PREFIX64 is added to a multicast ANNOUNCE
>   response. That's another reason not to permit this, in
>   addition to security issue 2) above.
[Med] I added this sentence:=20

" Note, it is NOT
      RECOMMENDED to include PREFIX64 options in ANNOUNCE messages if a
      customized IPv6 prefix list is configured to the PCP server. "

Better?

>
>7) When IPv4 prefix lists are configured and multiple IPv6
>   prefix lists are also configured, the first PREFIX64
>   option includes the IPv4 prefix lists. Can the later
>   PREFIX64 options also include their own IPv4 prefix
>   lists? If one or more of those later PREFIX64 options
>   does NOT have its own IPv4 prefix list, what does that
>   mean? Does it inherit the IPv4 prefix list of the
>   previous PREFIX64 option? The current text is not clear.
[Med] Only the first occurrence can carry the IPv4 prefix because other occ=
urrences are not used by building IPv4-converted addresses, but only to dis=
tinguish these addresses if received in referrals. I can add a sentence to =
indicate this explicitly in the text.


>
>8) The example in section 5.1 says that it "depicts a
>   typical usage of the PREFIX64 option when a DNS64
>   capability is embedded in the host." Did you mean
>   "is not embedded"? I don't see how DNS64 is being
>   used in this example.

[Med] The text is correct. DNS64 is used to form locally an IPv4-converted =
IPv6 address. The example assumes the address of the IPv4 server is retriev=
ed using A records. DNS exchanges are not mentioned in the figure to avoid =
overloading it.

>
>9) Is this document still relevant? RFC 7051 says:
>
>   Our conclusion is to recommend publishing the Well-Known DNS Name
>   heuristic discovery-based method as a Standards Track IETF document
>   for applications and host implementors to implement as-is.
>
>   With that, is there still a need for this document?
[Med] Yes, this is explicitly mentioned in the shepherded text of RFC7050. =
Please refer to https://datatracker.ietf.org/doc/rfc7050/history/=20

"    The document specifies a heuristic that is not perfect and so some
    points were rough, but the constraint for this document was to operate
    without changes to code (only configuration) in existing networks.
    Given that constraint, there was strong consensus.  Relaxing the
    constraint would allow one to do better, and that is the focus of a
    draft recently submitted to the PCP WG."

>
>I hope that you find these comments useful.
[Med] Thanks for the review. Much appreciated.=20

>
>Thanks,
>
>Steve
>


From shanna@juniper.net  Thu Jan 23 07:20:38 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A951A000F; Thu, 23 Jan 2014 07:20:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYT_1rO5OF7h; Thu, 23 Jan 2014 07:20:35 -0800 (PST)
Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA461A0004; Thu, 23 Jan 2014 07:20:34 -0800 (PST)
Received: from mail47-co1-R.bigfish.com (10.243.78.246) by CO1EHSOBE039.bigfish.com (10.243.66.104) with Microsoft SMTP Server id 14.1.225.22; Thu, 23 Jan 2014 15:20:34 +0000
Received: from mail47-co1 (localhost [127.0.0.1])	by mail47-co1-R.bigfish.com (Postfix) with ESMTP id E05FAD201FC; Thu, 23 Jan 2014 15:20:33 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -21
X-BigFish: VPS-21(zz98dI1432I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1033IL8275dh1de097h186068hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h24d7h9a9j1155h)
Received-SPF: pass (mail47-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=shanna@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; 
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(199002)(51704005)(189002)(164054003)(24454002)(76786001)(54316002)(93136001)(76796001)(92566001)(47736001)(46102001)(33646001)(49866001)(81816001)(93516002)(76482001)(94316002)(86362001)(65816001)(77982001)(53806001)(76576001)(56776001)(50986001)(80976001)(83322001)(74876001)(79102001)(31966008)(87266001)(85306002)(80022001)(87936001)(81342001)(74366001)(4396001)(47446002)(66066001)(59766001)(54356001)(2656002)(69226001)(47976001)(63696002)(19580395003)(74316001)(74502001)(85852003)(90146001)(74706001)(51856001)(83072002)(81686001)(81542001)(15975445006)(56816005)(74662001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB737; H:BLUPR05MB737.namprd05.prod.outlook.com; CLIP:66.129.239.13; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; 
Received: from mail47-co1 (localhost.localdomain [127.0.0.1]) by mail47-co1 (MessageSwitch) id 1390490431886174_13601; Thu, 23 Jan 2014 15:20:31 +0000 (UTC)
Received: from CO1EHSMHS028.bigfish.com (unknown [10.243.78.251])	by mail47-co1.bigfish.com (Postfix) with ESMTP id C9F0CD00055;	Thu, 23 Jan 2014 15:20:31 +0000 (UTC)
Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS028.bigfish.com (10.243.66.38) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 23 Jan 2014 15:20:31 +0000
Received: from BLUPR05MB737.namprd05.prod.outlook.com (10.141.208.17) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.395.1; Thu, 23 Jan 2014 15:20:28 +0000
Received: from BLUPR05MB737.namprd05.prod.outlook.com (10.141.208.17) by BLUPR05MB737.namprd05.prod.outlook.com (10.141.208.17) with Microsoft SMTP Server (TLS) id 15.0.851.11; Thu, 23 Jan 2014 15:20:26 +0000
Received: from BLUPR05MB737.namprd05.prod.outlook.com ([10.141.208.17]) by BLUPR05MB737.namprd05.prod.outlook.com ([10.141.208.17]) with mapi id 15.00.0851.011; Thu, 23 Jan 2014 15:20:26 +0000
From: Stephen Hanna 
To: "mohamed.boucadair@orange.com" , "secdir@ietf.org" , The IESG , "draft-ietf-pcp-nat64-prefix64.all@tools.ietf.org" 
Thread-Topic: secdir Review of draft-ietf-pcp-nat64-prefix64-04
Thread-Index: Ac8XAvhsFQvpZlpNT8uP4E8QAIyyLQBPUUuAAAMzYfA=
Date: Thu, 23 Jan 2014 15:20:25 +0000
Message-ID: <638ccecdeecb4b458718b1c33821c092@BLUPR05MB737.namprd05.prod.outlook.com>
References: <1f794d77ca95458d9d7cf06e20950090@BLUPR05MB737.namprd05.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36F4736024C@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F4736024C@PUEXCB1B.nanterre.francetelecom.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.239.13]
x-forefront-prvs: 0100732B76
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Subject: Re: [secdir] secdir Review of draft-ietf-pcp-nat64-prefix64-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Jan 2014 15:20:38 -0000

Med,

Thanks for your response. Coming along nicely!

A few comments on your changes below, marked with [SRH].

Thanks,

Steve

Med wrote:
> Steve wrote:
> >1) The second paragraph of the Security Considerations section
> >   points out that if an attacker can fool a host into using
> >   the wrong value for Pref64::/n, the traffic generated using
> >   that value will be delivered to the wrong location. That's
> >   right but not all the implications are mentioned. A MITM
> >   (Man In The Middle) attack can be performed in this manner,
> >   permitting alterations to the traffic (not just eavesdropping).
> >   This should be mentioned.
> [Med] I updated the text as follows:
>=20
> OLD:
>=20
>    As discussed in [RFC6147], if an attacker can manage to change the
>    Pref64::/n used by the DNS64 function, the traffic generated by the
>    host that receives the synthetic reply will be delivered to the
>    altered Pref64.  This can result in either a denial-of-service (DoS)
>    attack, a flooding attack, or an eavesdropping attack.  This attack
>    could be achieved either by altering PCP messages issued by a
>    legitimate PCP server or by using a fake PCP server.
>=20
> NEW:
>=20
>    As discussed in [RFC6147], if an attacker can manage to change the
>    Pref64::/n used by the DNS64 function, the traffic generated by the
>    host that receives the synthetic reply will be delivered to the
>    altered Pref64.  This can result in either a denial-of-service (DoS)
>    attack, a flooding attack, or a MIM (Man In The Middle) attack.
> This attack
>    could be achieved either by altering PCP messages issued by a
>    legitimate PCP server or by using a fake PCP server.
>=20
> Better?

[SRH] Yes, but the conventional abbreviation for
Man In The Middle is MITM not MIM. Who knows why?!

> >2) The next paragraph of the Security Considerations section
> >   suggests defenses to prevent the attacker from substituting
> >   the wrong value for Pref64::/n. However, the defense that
> >   is suggested (IP-based ACLs on the PCP server, client, or
> >   network) won't help much. Attackers can just place the
> >   PCP server's IP address in the source address of the fake
> >   PCP response packet sent by the attack.
>=20
> [Med] anti-spoofing filters can be used to prevent such attack. Ingress
> filters can be also enforced at boundaries of a domain to prevent such
> attack. I do think the text is still correct.

[SRH] These countermeasures provide no defense against an attacker
who is on the path from the PCP server to the client. This is
not a theoretical attack, as described in certain news reports
recently (Der Spiegel).

> > The nonce in the
> >   MAP or PEER response means that the attacker must capture
> >   or predict this value but no nonce is present in the ANNOUNCE
> >   response so that would probably be the preferred attack
> >   method, especially since ANNOUNCE responses can be sent
> >   out via multicast at any time. I suggest that the spec
> >   prohibit sending the PREFIX64 option in a multicast
> >   ANNOUNCE response, unless effective countermeasures for
> >   this attack are found.
> [Med] Isn't this covered by this text:
>=20
> "   Means to defend against attackers who can modify packets between
> the
>    PCP server and the PCP client, or who can inject spoofed packets
> that
>    appear to come from a legitimate PCP server SHOULD be enabled."

[SRH] That would be a reasonable countermeasure if such means
actually existed. Could you describe what those means
would be? As I mentioned above, ingress filters and
anti-spoofing filters are ineffective against on-path
attackers.

> >In addition to these security issues, I found some other issues
> >that are not related to security:
> >
> >1) You should explain that RFC 6146 defines Pref64::/n.
> >   Otherwise, that term is quite cryptic.
> [Med] I added this new sentence:
>=20
>    According to [RFC6146], NAT64 uses Pref64::/n to construct
>    IPv4-Converted IPv6 addresses as defined in [RFC6052].
>=20
> Better?

[SRH] Great!

[SRH] Deleted several more comments that you have addressed.

> >6) Text near the top of page 8 says "The PCP server can be
> >   configured with a customized IPv6 prefix list" but that
> >   won't work when PREFIX64 is added to a multicast ANNOUNCE
> >   response. That's another reason not to permit this, in
> >   addition to security issue 2) above.
> [Med] I added this sentence:
>=20
> " Note, it is NOT
>       RECOMMENDED to include PREFIX64 options in ANNOUNCE messages if a
>       customized IPv6 prefix list is configured to the PCP server. "
>=20
> Better?

[SRH] Maybe. Is there some way that including PREFIX64 options in
ANNOUNCE messages will work if a customized IPv6 prefix list
is configured to the PCP server? If not, this should be a
MUST NOT instead of a NOT RECOMMENDED.

> >7) When IPv4 prefix lists are configured and multiple IPv6
> >   prefix lists are also configured, the first PREFIX64
> >   option includes the IPv4 prefix lists. Can the later
> >   PREFIX64 options also include their own IPv4 prefix
> >   lists? If one or more of those later PREFIX64 options
> >   does NOT have its own IPv4 prefix list, what does that
> >   mean? Does it inherit the IPv4 prefix list of the
> >   previous PREFIX64 option? The current text is not clear.
> [Med] Only the first occurrence can carry the IPv4 prefix because other
> occurrences are not used by building IPv4-converted addresses, but only
> to distinguish these addresses if received in referrals. I can add a
> sentence to indicate this explicitly in the text.

[SRH] Thanks. Please do.

> >8) The example in section 5.1 says that it "depicts a
> >   typical usage of the PREFIX64 option when a DNS64
> >   capability is embedded in the host." Did you mean
> >   "is not embedded"? I don't see how DNS64 is being
> >   used in this example.
>=20
> [Med] The text is correct. DNS64 is used to form locally an IPv4-
> converted IPv6 address. The example assumes the address of the IPv4
> server is retrieved using A records. DNS exchanges are not mentioned in
> the figure to avoid overloading it.

[SRH] OK. You may want to explain this a bit more.

> >9) Is this document still relevant? RFC 7051 says:
> >
> >   Our conclusion is to recommend publishing the Well-Known DNS Name
> >   heuristic discovery-based method as a Standards Track IETF document
> >   for applications and host implementors to implement as-is.
> >
> >   With that, is there still a need for this document?
> [Med] Yes, this is explicitly mentioned in the shepherded text of
> RFC7050. Please refer to
> https://datatracker.ietf.org/doc/rfc7050/history/
>=20
> "    The document specifies a heuristic that is not perfect and so some
>     points were rough, but the constraint for this document was to
> operate
>     without changes to code (only configuration) in existing networks.
>     Given that constraint, there was strong consensus.  Relaxing the
>     constraint would allow one to do better, and that is the focus of a
>     draft recently submitted to the PCP WG."

[SRH] OK, fine. You might want to mention that in your draft.
Otherwise, other readers may have the same confusion. They're
not likely to read the shepherd text for RFC 7050!



From kivinen@iki.fi  Thu Jan 23 08:15:26 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEB11A0047; Thu, 23 Jan 2014 08:15:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7i68y1acQhZ; Thu, 23 Jan 2014 08:15:15 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7D61A001B; Thu, 23 Jan 2014 08:15:15 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s0NGFCNj005487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 23 Jan 2014 18:15:12 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s0NGFBjE002885; Thu, 23 Jan 2014 18:15:11 +0200 (EET)
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: <21217.16399.623639.865298@fireball.kivinen.iki.fi>
Date: Thu, 23 Jan 2014 18:15:11 +0200
From: Tero Kivinen 
To: "John Lindsay" 
In-Reply-To: <8C4E0C2409735E4FBC22D754A238F94D0303D9C4@APTSBS.apt.local>
References: <21152.30161.542379.749064@fireball.kivinen.iki.fi> <8C4E0C2409735E4FBC22D754A238F94D0303D9C4@APTSBS.apt.local>
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 2 min
X-Total-Time: 1 min
Cc: iesg@ietf.org, draft-ietf-payload-rtp-aptx.all@tools.ietf.org, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-payload-rtp-aptx-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Jan 2014 16:15:29 -0000

John Lindsay writes:
> Firstly apologies for the delay in replying, this is the first RFC draft
> I have been involved with and I was not sure of the process.
> You are correct the coded is a constant bit rate encoder and hence not
> vulnerable to the methods described in in the
> draft-ietf-avtcore-srtp-vbr-audio document.
> 
> If its felt necessary a note to this affect can be added to the security
> considerations section.

Either way is good for me. 

> -----Original Message-----
> From: Tero Kivinen [mailto:kivinen@iki.fi] 
> Sent: 05 December 2013 12:47
> To: iesg@ietf.org; secdir@ietf.org;
> draft-ietf-payload-rtp-aptx.all@tools.ietf.org
> Subject: Secdir review of draft-ietf-payload-rtp-aptx-04
> 
> 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 to transmit proprietary audio codec
> algorithms standard apt-X and enchanced apt-X in the RTP. The document
> has security considerations section which seems to be OK.
> 
> If I have understood correctly the codec is constant bit rate codec,
> thus it is not vulnerable to the traffic analysis attacks described for
> example in the draft-ietf-avtcore-srtp-vbr-audio document. Perhaps the
> security considerations section could note that these codecs are not
> vulnerable to those attacks (if that is in deed true).
> --
> kivinen@iki.fi

-- 
kivinen@iki.fi

From kivinen@iki.fi  Thu Jan 23 08:47:39 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEAA1A0055 for ; Thu, 23 Jan 2014 08:47:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xTHDYfjuj_b for ; Thu, 23 Jan 2014 08:47:37 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id DD6491A0006 for ; Thu, 23 Jan 2014 08:47:36 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s0NGlWsu011698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 23 Jan 2014 18:47:32 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s0NGlVU7017264; Thu, 23 Jan 2014 18:47:31 +0200 (EET)
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: <21217.18339.633518.862434@fireball.kivinen.iki.fi>
Date: Thu, 23 Jan 2014 18:47:31 +0200
From: Tero Kivinen 
To: secdir@ietf.org
X-Edit-Time: 1 min
X-Total-Time: 0 min
Subject: [secdir] Assignments
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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, 23 Jan 2014 16:47:39 -0000

Review instructions and related resources are at:
http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

Scott Kelly is next in the rotation.

For telechat 2014-01-23

Reviewer                 LC end     Draft
Rob Austein            T 2014-01-16 draft-ietf-mpls-tp-p2mp-framework-06
Alan DeKok             T 2014-01-17 draft-ietf-mpls-multipath-use-03
Donald Eastlake        T 2014-01-22 draft-ietf-netmod-system-mgmt-11
Hilarie Orman          TR2013-11-18 draft-shore-icmp-aup-09
Tina TSOU              TR2013-11-27 draft-ietf-l2vpn-evpn-req-06
Carl Wallace           T 2014-01-06 draft-ietf-opsawg-lsn-deployment-05
David Waltermire       T 2014-01-16 draft-ietf-pwe3-mpls-tp-cv-adv-05
Glen Zorn              T 2014-01-17 draft-ietf-mpls-moving-iana-registries-03


For telechat 2014-02-06

Dan Harkins            T 2014-02-04 draft-ietf-alto-protocol-25
Julien Laganier        T 2013-12-11 draft-ietf-stox-core-09
Ben Laurie             T 2013-12-11 draft-ietf-stox-presence-07
Brian Weis             TR2013-09-30 draft-ietf-p2psip-drr-11
Klaas Wierenga         TR2013-09-30 draft-ietf-p2psip-rpr-11


For telechat 2014-02-20

Dorothy Gellert        T 2014-02-11 draft-housley-pkix-test-oids-00

Last calls and special requests:

Dave Cridland          E 2013-11-21 draft-dunbar-armd-arp-nd-scaling-practices-07
Tobias Gondrom           2014-01-23 draft-ietf-dane-registry-acronyms-03
Phillip Hallam-Baker     2014-01-27 draft-ietf-qresync-rfc5162bis-09
Steve Hanna              2014-01-28 draft-ietf-v6ops-nat64-experience-09
David Harrington         2014-02-04 draft-ietf-avtext-rtp-duplication-04
Sam Hartman              2014-02-04 draft-ietf-manet-olsrv2-rmpr-optimization-00
Paul Hoffman             2014-02-04 draft-ietf-radext-ieee802ext-10
Jeffrey Hutzelman      E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-05
Jeffrey Hutzelman        2014-02-04 draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01
Leif Johansson           2014-02-04 draft-ietf-xrblock-rtcp-xr-synchronization-07
Charlie Kaufman          2014-02-18 draft-yourtchenko-cisco-ies-09
Julien Laganier        E 2013-11-21 draft-ietf-websec-key-pinning-09
Sandy Murphy             2013-12-17 draft-ietf-netmod-iana-timezones-03
Ondrej Sury              2013-12-27 draft-ietf-tls-applayerprotoneg-03
Brian Weis             E 2014-01-16 draft-ietf-radext-dynamic-discovery-09
Glen Zorn                2013-08-30 draft-kaplan-insipid-session-id-03
-- 
kivinen@iki.fi

From mohamed.boucadair@orange.com  Fri Jan 24 00:55:41 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55D9C1A01DD; Fri, 24 Jan 2014 00:55:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.549
X-Spam-Level: 
X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gujUqcjm8yh; Fri, 24 Jan 2014 00:55:38 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 5E24E1A01C6; Fri, 24 Jan 2014 00:55:38 -0800 (PST)
Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 8F3432AC478; Fri, 24 Jan 2014 09:55:36 +0100 (CET)
Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 69D7715803A; Fri, 24 Jan 2014 09:55:36 +0100 (CET)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Fri, 24 Jan 2014 09:55:35 +0100
From: 
To: Stephen Hanna , "secdir@ietf.org" , The IESG , "draft-ietf-pcp-nat64-prefix64.all@tools.ietf.org" 
Date: Fri, 24 Jan 2014 09:55:34 +0100
Thread-Topic: secdir Review of draft-ietf-pcp-nat64-prefix64-04
Thread-Index: Ac8XAvhsFQvpZlpNT8uP4E8QAIyyLQBPUUuAAAMzYfAAIo4UkA==
Message-ID: <94C682931C08B048B7A8645303FDC9F36F473603EB@PUEXCB1B.nanterre.francetelecom.fr>
References: <1f794d77ca95458d9d7cf06e20950090@BLUPR05MB737.namprd05.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36F4736024C@PUEXCB1B.nanterre.francetelecom.fr> <638ccecdeecb4b458718b1c33821c092@BLUPR05MB737.namprd05.prod.outlook.com>
In-Reply-To: <638ccecdeecb4b458718b1c33821c092@BLUPR05MB737.namprd05.prod.outlook.com>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.24.52114
Subject: Re: [secdir] secdir Review of draft-ietf-pcp-nat64-prefix64-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jan 2014 08:55:41 -0000

Dear Stephen,

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De=A0: Stephen Hanna [mailto:shanna@juniper.net]
>Envoy=E9=A0: jeudi 23 janvier 2014 16:20
>=C0=A0: BOUCADAIR Mohamed IMT/OLN; secdir@ietf.org; The IESG; draft-ietf-p=
cp-
>nat64-prefix64.all@tools.ietf.org
>Objet=A0: RE: secdir Review of draft-ietf-pcp-nat64-prefix64-04
>
>Med,
>
>Thanks for your response. Coming along nicely!
>
>A few comments on your changes below, marked with [SRH].
>
>Thanks,
>
>Steve
>
>Med wrote:
>> Steve wrote:
>> >1) The second paragraph of the Security Considerations section
>> >   points out that if an attacker can fool a host into using
>> >   the wrong value for Pref64::/n, the traffic generated using
>> >   that value will be delivered to the wrong location. That's
>> >   right but not all the implications are mentioned. A MITM
>> >   (Man In The Middle) attack can be performed in this manner,
>> >   permitting alterations to the traffic (not just eavesdropping).
>> >   This should be mentioned.
>> [Med] I updated the text as follows:
>>
>> OLD:
>>
>>    As discussed in [RFC6147], if an attacker can manage to change the
>>    Pref64::/n used by the DNS64 function, the traffic generated by the
>>    host that receives the synthetic reply will be delivered to the
>>    altered Pref64.  This can result in either a denial-of-service (DoS)
>>    attack, a flooding attack, or an eavesdropping attack.  This attack
>>    could be achieved either by altering PCP messages issued by a
>>    legitimate PCP server or by using a fake PCP server.
>>
>> NEW:
>>
>>    As discussed in [RFC6147], if an attacker can manage to change the
>>    Pref64::/n used by the DNS64 function, the traffic generated by the
>>    host that receives the synthetic reply will be delivered to the
>>    altered Pref64.  This can result in either a denial-of-service (DoS)
>>    attack, a flooding attack, or a MIM (Man In The Middle) attack.
>> This attack
>>    could be achieved either by altering PCP messages issued by a
>>    legitimate PCP server or by using a fake PCP server.
>>
>> Better?
>
>[SRH] Yes, but the conventional abbreviation for
>Man In The Middle is MITM not MIM. Who knows why?!
[Med] Fixed.

>
>> >2) The next paragraph of the Security Considerations section
>> >   suggests defenses to prevent the attacker from substituting
>> >   the wrong value for Pref64::/n. However, the defense that
>> >   is suggested (IP-based ACLs on the PCP server, client, or
>> >   network) won't help much. Attackers can just place the
>> >   PCP server's IP address in the source address of the fake
>> >   PCP response packet sent by the attack.
>>
>> [Med] anti-spoofing filters can be used to prevent such attack. Ingress
>> filters can be also enforced at boundaries of a domain to prevent such
>> attack. I do think the text is still correct.
>
>[SRH] These countermeasures provide no defense against an attacker
>who is on the path from the PCP server to the client. This is
>not a theoretical attack, as described in certain news reports
>recently (Der Spiegel).
[Med] The deployment I have in mind is a pcp service offered by a service p=
rovider while pcp clients are hosted in a CPE or in connected devices (eith=
er behind the CPE or directly to the service provider network). To achieve =
the attack vector you described, the mis-behaving node should be in the ser=
vice provider network or connected to that network. If that service provide=
r enforced anti-spoofing filters, then a mis-behaving node cannot act as a =
fake pcp server.=20

I understand this is a deployment case among others. So to be accurate, I c=
hanged the text as follows:

OLD:
   For example, access control lists (ACLs) can be installed on the PCP
   client, PCP server, and the network between them, so those ACLs allow
   only communications from a trusted PCP server to the PCP client.

NEW:
   In some deployments, access control lists (ACLs) can be installed on
   the PCP client, PCP server, and the network between them, so those
   ACLs allow only communications from a trusted PCP server to the PCP
   client.
=20

>
>> > The nonce in the
>> >   MAP or PEER response means that the attacker must capture
>> >   or predict this value but no nonce is present in the ANNOUNCE
>> >   response so that would probably be the preferred attack
>> >   method, especially since ANNOUNCE responses can be sent
>> >   out via multicast at any time. I suggest that the spec
>> >   prohibit sending the PREFIX64 option in a multicast
>> >   ANNOUNCE response, unless effective countermeasures for
>> >   this attack are found.
>> [Med] Isn't this covered by this text:
>>
>> "   Means to defend against attackers who can modify packets between
>> the
>>    PCP server and the PCP client, or who can inject spoofed packets
>> that
>>    appear to come from a legitimate PCP server SHOULD be enabled."
>
>[SRH] That would be a reasonable countermeasure if such means
>actually existed. Could you describe what those means
>would be? As I mentioned above, ingress filters and
>anti-spoofing filters are ineffective against on-path
>attackers.
[Med] As mentioned above, ACLs are sufficient in some deployment contexts.=
=20


>
>> >In addition to these security issues, I found some other issues
>> >that are not related to security:
>> >
>> >1) You should explain that RFC 6146 defines Pref64::/n.
>> >   Otherwise, that term is quite cryptic.
>> [Med] I added this new sentence:
>>
>>    According to [RFC6146], NAT64 uses Pref64::/n to construct
>>    IPv4-Converted IPv6 addresses as defined in [RFC6052].
>>
>> Better?
>
>[SRH] Great!
>
>[SRH] Deleted several more comments that you have addressed.
>
>> >6) Text near the top of page 8 says "The PCP server can be
>> >   configured with a customized IPv6 prefix list" but that
>> >   won't work when PREFIX64 is added to a multicast ANNOUNCE
>> >   response. That's another reason not to permit this, in
>> >   addition to security issue 2) above.
>> [Med] I added this sentence:
>>
>> " Note, it is NOT
>>       RECOMMENDED to include PREFIX64 options in ANNOUNCE messages if a
>>       customized IPv6 prefix list is configured to the PCP server. "
>>
>> Better?
>
>[SRH] Maybe. Is there some way that including PREFIX64 options in
>ANNOUNCE messages will work if a customized IPv6 prefix list
>is configured to the PCP server? If not, this should be a
>MUST NOT instead of a NOT RECOMMENDED.

[Med] An example is the use of separate zones (see for instance http://tool=
s.ietf.org/search/draft-penno-pcp-zones-01) or if several logical topologie=
s are configured.=20

>
>> >7) When IPv4 prefix lists are configured and multiple IPv6
>> >   prefix lists are also configured, the first PREFIX64
>> >   option includes the IPv4 prefix lists. Can the later
>> >   PREFIX64 options also include their own IPv4 prefix
>> >   lists? If one or more of those later PREFIX64 options
>> >   does NOT have its own IPv4 prefix list, what does that
>> >   mean? Does it inherit the IPv4 prefix list of the
>> >   previous PREFIX64 option? The current text is not clear.
>> [Med] Only the first occurrence can carry the IPv4 prefix because other
>> occurrences are not used by building IPv4-converted addresses, but only
>> to distinguish these addresses if received in referrals. I can add a
>> sentence to indicate this explicitly in the text.
>
>[SRH] Thanks. Please do.
[Med] I added this sentence to Section 4.1:

" When multiple PREFIX64 options are included in the same PCP message, only=
 the first PREFIX64 option occurrence may include the IPv4 Prefix List fiel=
d."


>
>> >8) The example in section 5.1 says that it "depicts a
>> >   typical usage of the PREFIX64 option when a DNS64
>> >   capability is embedded in the host." Did you mean
>> >   "is not embedded"? I don't see how DNS64 is being
>> >   used in this example.
>>
>> [Med] The text is correct. DNS64 is used to form locally an IPv4-
>> converted IPv6 address. The example assumes the address of the IPv4
>> server is retrieved using A records. DNS exchanges are not mentioned in
>> the figure to avoid overloading it.
>
>[SRH] OK. You may want to explain this a bit more.
[Med] I made this change:=20

OLD:
"once the IPv6-only client discovers the IPv4 address of the remote IPv4-on=
ly server"

NEW:
" once the IPv6-only client discovers the IPv4 address of the remote IPv4-o=
nly server (e.g., using DNS)"

and added this sentence:

" Note: DNS exchange to retrieve the IPv4 address of=20
      the IPv4-only Server is not shown in the figure. "

>
>> >9) Is this document still relevant? RFC 7051 says:
>> >
>> >   Our conclusion is to recommend publishing the Well-Known DNS Name
>> >   heuristic discovery-based method as a Standards Track IETF document
>> >   for applications and host implementors to implement as-is.
>> >
>> >   With that, is there still a need for this document?
>> [Med] Yes, this is explicitly mentioned in the shepherded text of
>> RFC7050. Please refer to
>> https://datatracker.ietf.org/doc/rfc7050/history/
>>
>> "    The document specifies a heuristic that is not perfect and so some
>>     points were rough, but the constraint for this document was to
>> operate
>>     without changes to code (only configuration) in existing networks.
>>     Given that constraint, there was strong consensus.  Relaxing the
>>     constraint would allow one to do better, and that is the focus of a
>>     draft recently submitted to the PCP WG."
>
>[SRH] OK, fine. You might want to mention that in your draft.
>Otherwise, other readers may have the same confusion. They're
>not likely to read the shepherd text for RFC 7050!
>


From alan.b.johnston@gmail.com  Thu Jan 23 11:44:35 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A86851A001D for ; Thu, 23 Jan 2014 11:44:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Q5_dTatLNck for ; Thu, 23 Jan 2014 11:44:33 -0800 (PST)
Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 786F41A00A4 for ; Thu, 23 Jan 2014 11:44:32 -0800 (PST)
Received: by mail-pa0-f54.google.com with SMTP id fa1so2264469pad.41 for ; Thu, 23 Jan 2014 11:44:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BJRwI+yWM7AVIbXTZRNhFovr4MO+ATF1dPW7SDsJZwY=; b=W58lwSU2Ap8gDBBssDWJUrnXI8NvySmrEAIoXf5GIlSWCD/t8z8Z7NN8qQLV2cOiCv Sz+Fou46QWWkofu/rmTp+SIG8IfF5oEctjs0u8Bwbon6wKbiELy6q02v1rJx3gGzkliB kTOQ4HRWhkiReaDP00XX1gdHil8fi8W0aQWIJJxxLL4UGlw3at/S5TGpGkB5w0N1/uQa tyYYbkBo33AvtYUDyf5qHRBOf5PZgdC2036vhGJ9mWNQG48PKBESf52DiybrWRRSsExK jOXt9yjC8snfryXcKy23hFL0oshHD5Ks+XQC2pvgxHmdCKccKWdgOsxx7fMblhyFp/YM iSiA==
MIME-Version: 1.0
X-Received: by 10.66.141.231 with SMTP id rr7mr9475618pab.41.1390506271374; Thu, 23 Jan 2014 11:44:31 -0800 (PST)
Received: by 10.68.168.132 with HTTP; Thu, 23 Jan 2014 11:44:31 -0800 (PST)
In-Reply-To: <1369961279.70598635@apps.rackspace.com>
References: <1369961279.70598635@apps.rackspace.com>
Date: Thu, 23 Jan 2014 13:44:31 -0600
Message-ID: 
From: Alan Johnston 
To: "Scott G. Kelly" 
Content-Type: multipart/alternative; boundary=001a113312985d012504f0a87836
X-Mailman-Approved-At: Fri, 24 Jan 2014 00:57:04 -0800
Cc: draft-ietf-cuss-sip-uui.all@tools.ietf.org, "secdir@ietf.org" 
Subject: Re: [secdir] secdir review of draft-ietf-cuss-sip-uui-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Jan 2014 19:44:35 -0000

--001a113312985d012504f0a87836
Content-Type: text/plain; charset=ISO-8859-1

Scott,

Thanks for your review of the draft.  We made some edits based on your
comments a while back, so I'm pinging you to make sure they address your
concerns.

     http://tools.ietf.org/html/draft-ietf-cuss-sip-uui

Thanks!
- Alan -


On Thu, May 30, 2013 at 7:47 PM, Scott G. Kelly 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.
>
> I have no expertise in SIP, and am providing this review as a first-level
> filter for our over-worked security ADs. So, please take my comments
> accordingly. Also, this review is a day late -- I hope it is still useful.
>
> This document defines a method for exchanging a blob of information
> between user agents during SIP session establishment (User to User
> Information, or UUI data) by adding a new SIP header. The data is intended
> to be opaque to SIP.
>
> There is a related problem statement RFC (6567) that briefly describes 3
> different approaches to security, but neither document describes likely
> threats. They are implicit in the 3 models described in 6567 (e.g. treat
> the sip layer as "untrusted", treat the sip layer as "trusted", treat the
> transport domain as "trusted"), but I found myself wishing I had more info
> about real-world threats and countermeasures.
>
> Given that I am not a SIP expert (and don't have time to become one as
> part of this review), I don't know if this is an issue or not, but this is
> an impression I think worth mentioning.
>
> A second question relates to the binding of the UUI to its originator. The
> security considerations section suggests that the UUI might carry sensitive
> info requiring privacy or integrity protection, but does not mention origin
> authentication. There is a hint in the next paragraph (it says
> "History-Info can be used to determine the identity of the inserter"), but
> the relative security of this mechanism is not clear to me. Could an
> attacker forge History-Info? I don't know. What are the consequences of
> such behavior? I don't know. Seems like a well-written security
> considerations section would lay these questions to rest.
>
> Again, I have almost zero knowledge of SIP, so maybe answers are obvious
> to someone steeped in SIP lore, and I apologize if this is the case. But,
> these are my impressions.
>
> --Scott
>
>
>

--001a113312985d012504f0a87836
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Scott,

Thanks for your review of the dr=
aft. =A0We made some edits based on your comments a while back, so I'm =
pinging you to make sure they address your concerns.


=A0 =A0 =A0h=
ttp://tools.ietf.org/html/draft-ietf-cuss-sip-uui

<=
div>Thanks!
- Alan -



On Thu, May 30, 2013 at 7:47 PM, Scott G. Kelly <scott@hyperthought.c=
om> wrote:

I have reviewed this document as part of the security directorate's ong=
oing effort to review all IETF documents being processed by the IESG. =A0Th=
ese comments were written primarily for the benefit of the security area di=
rectors. =A0Document editors and WG chairs should treat these comments just=
 like any other last call comments.




I have no expertise in SIP, and am providing this review as a first-level f=
ilter for our over-worked security ADs. So, please take my comments accordi=
ngly. Also, this review is a day late -- I hope it is still useful.




This document defines a method for exchanging a blob of information between=
 user agents during SIP session establishment (User to User Information, or=
 UUI data) by adding a new SIP header. The data is intended to be opaque to=
 SIP.




There is a related problem statement RFC (6567) that briefly describes 3 di=
fferent approaches to security, but neither document describes likely threa=
ts. They are implicit in the 3 models described in 6567 (e.g. treat the sip=
 layer as "untrusted", treat the sip layer as "trusted"=
, treat the transport domain as "trusted"), but I found myself wi=
shing I had more info about real-world threats and countermeasures.




Given that I am not a SIP expert (and don't have time to become one as =
part of this review), I don't know if this is an issue or not, but this=
 is an impression I think worth mentioning.



A second question relates to the binding of the UUI to its originator. The =
security considerations section suggests that the UUI might carry sensitive=
 info requiring privacy or integrity protection, but does not mention origi=
n authentication. There is a hint in the next paragraph (it says "Hist=
ory-Info can be used to determine the identity of the inserter"), but =
the relative security of this mechanism is not clear to me. Could an attack=
er forge History-Info? I don't know. What are the consequences of such =
behavior? I don't know. Seems like a well-written security consideratio=
ns section would lay these questions to rest.




Again, I have almost zero knowledge of SIP, so maybe answers are obvious to=
 someone steeped in SIP lore, and I apologize if this is the case. But, the=
se are my impressions.



--Scott









--001a113312985d012504f0a87836--

From tom.taylor.stds@gmail.com  Thu Jan 23 16:19:10 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A601A01D3; Thu, 23 Jan 2014 16:19:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9Bieuv1nkHh; Thu, 23 Jan 2014 16:19:08 -0800 (PST)
Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1841A00AA; Thu, 23 Jan 2014 16:19:08 -0800 (PST)
Received: by mail-ie0-f169.google.com with SMTP id tq11so2109791ieb.14 for ; Thu, 23 Jan 2014 16:19:07 -0800 (PST)
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:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=bsvSoZQaLq7WVnQeSFUJgKNu/RdxgjdYt7TPr0uS18Y=; b=t9S2iq3lbA2mMdmHjOxSIPyHExjp4Twz3enNv0pSIoW3d9ug4NWk7wP/PWN7n42v8O WrPShHCjjMRgMTuSOo4y7PtBCW+zKlayvvh7MGdz6Rlmr98vTUXFvJ/XhVbxvIgkXUR/ xRmNjxIjFjCkL5m0B5cBGJs5f0/SKyT9b8xWg6C7kaw3m7uEh3dWlOPi6OgSoUBtc/PB uqEgyOMOjctTGnoH/EtvhwFiuSyP6nFpnZUQigg757DlMv2G4lBudIp4WuujAqsAtcWk GDpXvCThAwo+TmKVfVxBftNbW4fbExS1NQmkfv9nozItkZ9xCV3JGAtk/k+8keaSSMel 5gog==
X-Received: by 10.50.43.134 with SMTP id w6mr2053857igl.20.1390522747083; Thu, 23 Jan 2014 16:19:07 -0800 (PST)
Received: from [192.168.1.69] ([64.56.225.169]) by mx.google.com with ESMTPSA id x6sm3915112igb.3.2014.01.23.16.19.05 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Jan 2014 16:19:06 -0800 (PST)
Message-ID: <52E1B176.9070209@gmail.com>
Date: Thu, 23 Jan 2014 19:19:02 -0500
From: Tom Taylor 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "Zhangdacheng (Dacheng)" ,  "iesg@ietf.org" , "secdir@ietf.org" ,  "draft-ietf-ancp-mc-extensions.all@tools.ietf.org" 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Fri, 24 Jan 2014 00:57:05 -0800
Subject: Re: [secdir] [spam] secdir review of draft-ietf-ancp-mc-extensions-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jan 2014 00:19:11 -0000

Again, thank you for the work you out into this review. Responses marked
with [PTT].

On 22/01/2014 1:47 AM, Zhangdacheng (Dacheng) wrote:
> 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.
> 
> This draft specifies the extensions to the Access Node Control
> Protocol [RFC6320] required for support of the multicast use cases
> proposed in [RFC5851].
> 
> This huge document is well written. The authors must have spent much
> energy on this work.
> 
> Follows are some questions and comments:
> 
> 1)
> 
> In the introduction, there is a statement ¡°Conditional access is
> described in Section 3.4.1 and Section 3.4.2.3 of [RFC5851], with the
> latter section particularly applicable to operation with white and
> black lists only¡±
> 
> Section 3.4.2.3 of RFC5851 actually discusses how admission control
> may defeat the purpose of using a white and black list. So, I suggest
> re-writing this text.

[PTT] Proposed to rephrase as follows:

"Conditional access is described in Section 3.4.1 of [RFC5851]. Section
3.4.2.2 mentions a way in which conditional access can be combined with
admission control to allow best effort multicast flows. Section 3.4.2.3
points out the necessary conditions for using both conditional access
and admission control."
> 
> 2)
> 
> It would make the document easier to understand if the key terms can
> be clearly introduced. So, I suggest refining Section 2.
> 
> In details, terms such as ¡°Conditional Access¡±, ¡°admission control¡±,
> and "conditional access and admission control (CAC)" are widely used
> in this draft. In addition, this document specifies that conditional
> access and admission control can consist of two parts: policy-based
> admission control and resource-based admission control. However,
> there is no clear definition provided about those terms.
> 
> According to RFC5851, conditional access can use white, back, and
> grey lists to manage the generation of multicast flows, while
> admission control is used in the cases where the bandwidth
> reservation for newly generated flows is required.
> 
> So, it should be clarified whether there is any relationship between
> the admission control in RFC5851, and the policy-based admission
> control and resource-based admission control proposed in this
> document. Examples will help a lot.
> 
> In addition, in RFC 5851, CAC is an abbreviation of Connection
> Admission Control. This may cause confusing.
> 
[PTT] Proposed to rely specifically on RFC 5851 terminology.
Co-authors, please verify that I have this correctly:

 1) The terms "admission control" and "Connection Admission Control
(CAC)" mean the same thing and have to do with bandwidth allocation.

 2) "Conditional access" refers specifically to the use of white, black,
and grey lists.

 3) I don't need any other terms to describe the service control
capabilities specified in this document.

Assuming this is correct, I'll make sure those terms are called out in
Section 2, drop any other text on the topic, and propagate the necessary
changes throughout the rest of the document.

Apologies for being so slow to understand the correct terminology.
> 
> 
> 3)
> 
> In section 4.1.1, there is a statement ¡°The NAS SHOULD NOT include
> any list type (white, black, or grey) that is not supported by the
> set of multicast capabilities negotiated between the NAS and the AN.¡±
> In section 4.1.2, there is a corresponding statement ¡°In keeping with
> the general rule stated in Section 4, the AN MUST ignore instances of
> the List-Action TLV referring to any list type (white, black, or
> grey) that is not supported by the set of multicast capabilities
> negotiated between the NAS and the AN.¡±
> 
> So, I suggest using ¡°MUST¡± to take place of ¡°SHOULD¡± in the first
> statement unless we can find out a scenario where the NAS needs to
> send out a TLV which is not supported by the AN and will be
> eventually discarded.
> 
> 
[PTT] This is an example of "be conservative in what you send and
liberal (i.e, survive gracefully) with what you receive". I had in mind
that the NAS might have a template based on support of grey lists as
well as white and black, and fill it out leaving the grey list empty.
Strictly an implementation shortcut, obviously not the required protocol
behaviour. I don't feel strongly about SHOULD, so I'll replace it with
unless anyone else has a comment.
> 
> 4)
> 
> Section 6.1.3 lists the protocol elements that MUST be implemented to
> support the conditional access with white and black lists multicast
> capability. I found White-List-CAC TLV is included in the list.
> However, the White-List-CAC TLV is used to indicate that the NAS
> wishes the AN to do admission control for white-listed flows, and
> this use case is discussed in Section 3.4.2.3 of RFC 5851 ¡°Multicast
> Admission Control and White Lists¡±. So, I doubt whether this TLV
> needs to be supported is this case.
> 
[PTT] Doesn't Section 3.4.2.3 describe a case where the AN does both
admission control and white listing, and sets the conditions for doing that?

  "IPTV is an example of a service that will not be offered as best
   effort, but requires some level of guaranteed quality of service.
   This requires the use of Multicast Admission Control.  Hence, if the
   Access Node wants to autonomously perform the admission process, it
   must be aware of the bandwidth characteristics of multicast flows.
   Otherwise, the Access Node would have to query the NAS for Multicast
   Admission Control (per the grey list behavior); this would defeat the
   purpose of using a white and black list."

> 5)
> 
> Section 4.1.2, it is stated ¡°The buffering time specified in an
> instance of the Report-Buffering- Time TLV applies only to Committed
> Bandwidth Report messages initiated after the new buffering time is
> received at the AN, not to any message already in the process of
> accumulation .¡±
> 
> This policy indicates an implementation may have to maintain two or
> multiple accumulation processes when NAS frequently sends the
> Report-Buffering- Time TLVs to the AN and then changes the buffering
> time. This may not result in serious security problem but will
> introduce more complexity in the system implementation. So, I suggest
> changing the text to ¡°The buffering time specified in an instance of
> the Report-Buffering- Time TLV will not be applied until the current
> accumulation process of Committed Bandwidth Report messages
> finishes.¡±

[PTT] Accepted.
> 
> 6)
> 
> In the security consideration, the issues with the attacks on the
> communication channel between AAA and NAS is not sufficient. It is
> mentioned in this section that it is possible to download per- device
> policy to the NAS directly so as to eliminate the communication
> between NAS and AAA. I agree this is an option. However, I believe it
> is still worthwhile for us to discuss how to secure the communication
> between NAS and AAA.
> 
[PTT] I can add references to Diameter security (with which I am
familiar) and RADIUS security (which I gather is being worked on)?
Roberta, can you help with the latter?
> 
> 
> Nits:
> 
> 1)       Section 4.1.2: In keeping with the general rule stated in
> Section 4 -> In keeping with the general rule stated in Section
> 4.1.1

[PTT] The general rule is in Section 4:

  "Unless stated otherwise, receivers MUST ignore message contents that
   are not supported by the set of capabilities negotiated between the
   NAS and the Access Node."

> 
> Typos:
> 
> Section 4.4:      first directive that can not -> first directive
> that cannot

[PTT] OK
> 
> Section 7:                   An attacker able to to -> An attacker
> able to

[PTT] OK
> 
> Cheers
> 
> Dacheng
> 

From robmgl@cisco.com  Thu Jan 23 16:43:23 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A36C1A0491; Thu, 23 Jan 2014 16:43:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.036
X-Spam-Level: 
X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNoJSOBWuq6T; Thu, 23 Jan 2014 16:43:21 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4381A04C1; Thu, 23 Jan 2014 16:43:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9693; q=dns/txt; s=iport; t=1390524200; x=1391733800; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=FAkKPU5TKMdYzx38U04e5QC3ZYCJYm633tEm8YdIMIU=; b=m7zDLyPq19dLEhRZNTO/+iGcwnLSGGw1465+Cn7xbzm6Mu7YwF4Q1ZdK 5GeyPTBBuNvYFtPhzzdD0s0yf4UbiokY2c/FUfrxS6QcDvEojNL5Fb8Ig FyYamq+XYlhc9wfPK9h6mkdidkDfOj9QJX8cjzfcyeMobDnJG9YsM4Fay k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhkFAFK24VKtJV2b/2dsb2JhbABagwyBDoJ+uTWBEBZ0giUBAQEDASEBBUsHBQcGAQgRBAEBAQEDBgUYAgMjERQJCQEEAQ0FCIdpAwkIjmybbAGWXQ2FVheBJotGgWMxDYJmOIEUAQOUPYF6jkmFO4Mtgio
X-IronPort-AV: E=Sophos;i="4.95,709,1384300800"; d="scan'208";a="299323912"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 24 Jan 2014 00:43:19 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0O0hJNs015554 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Jan 2014 00:43:19 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.207]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Thu, 23 Jan 2014 18:43:19 -0600
From: "Roberta Maglione (robmgl)" 
To: Tom Taylor , "Zhangdacheng (Dacheng)" , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-ancp-mc-extensions.all@tools.ietf.org" 
Thread-Topic: [secdir] secdir review of draft-ietf-ancp-mc-extensions-14
Thread-Index: Ac8YnUN+U69/7J8+QKGUVU/X/G6UAA==
Date: Fri, 24 Jan 2014 00:43:18 +0000
Message-ID: <57C3345230A4F94C9B2F5CFA05D7F2BD1D570589@xmb-rcd-x01.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.99.169]
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 24 Jan 2014 00:57:04 -0800
Subject: Re: [secdir] secdir review of draft-ietf-ancp-mc-extensions-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jan 2014 00:43:23 -0000

Tom,

Regarding this point:
>[PTT] I can add references to Diameter security (with which I am
>familiar) and RADIUS security (which I gather is being worked on)?
>Roberta, can you help with the latter?

I'm not very familiar with security, but as far as I know RADIUS security i=
s based on the MD5 algorithm, which has been proven to be  insecure. In ord=
er to overcome this issue " Transport Layer Security (TLS) Encryption for R=
ADIUS" has been specified in RFC 6614, I think we should add a reference to=
 this RFC.
I'm cc-ing Klaas who is one of the author of this RFC in order to get his f=
eedback too.

Thanks
Regards
Roberta

-----Original Message-----
From: Tom Taylor [mailto:tom.taylor.stds@gmail.com]=20
Sent: Thursday, January 23, 2014 7:19 PM
To: Zhangdacheng (Dacheng); iesg@ietf.org; secdir@ietf.org; draft-ietf-ancp=
-mc-extensions.all@tools.ietf.org
Subject: Re: [spam] [secdir] secdir review of draft-ietf-ancp-mc-extensions=
-14

Again, thank you for the work you out into this review. Responses marked wi=
th [PTT].

On 22/01/2014 1:47 AM, Zhangdacheng (Dacheng) wrote:
> Hello=1B$B!'=1B(B
>=20
>=20
> 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.
>=20
> This draft specifies the extensions to the Access Node Control=20
> Protocol [RFC6320] required for support of the multicast use cases=20
> proposed in [RFC5851].
>=20
> This huge document is well written. The authors must have spent much=20
> energy on this work.
>=20
> Follows are some questions and comments:
>=20
> 1)
>=20
> In the introduction, there is a statement =1B$B!H=1B(BConditional access =
is=20
> described in Section 3.4.1 and Section 3.4.2.3 of [RFC5851], with the=20
> latter section particularly applicable to operation with white and=20
> black lists only=1B$B!I=1B(B
>=20
> Section 3.4.2.3 of RFC5851 actually discusses how admission control=20
> may defeat the purpose of using a white and black list. So, I suggest=20
> re-writing this text.

[PTT] Proposed to rephrase as follows:

"Conditional access is described in Section 3.4.1 of [RFC5851]. Section
3.4.2.2 mentions a way in which conditional access can be combined with adm=
ission control to allow best effort multicast flows. Section 3.4.2.3 points=
 out the necessary conditions for using both conditional access and admissi=
on control."
>=20
> 2)
>=20
> It would make the document easier to understand if the key terms can=20
> be clearly introduced. So, I suggest refining Section 2.
>=20
> In details, terms such as =1B$B!H=1B(BConditional Access=1B$B!I=1B(B, =1B=
$B!H=1B(Badmission control=1B$B!I=1B(B,=20
> and "conditional access and admission control (CAC)" are widely used=20
> in this draft. In addition, this document specifies that conditional=20
> access and admission control can consist of two parts: policy-based=20
> admission control and resource-based admission control. However, there=20
> is no clear definition provided about those terms.
>=20
> According to RFC5851, conditional access can use white, back, and grey=20
> lists to manage the generation of multicast flows, while admission=20
> control is used in the cases where the bandwidth reservation for newly=20
> generated flows is required.
>=20
> So, it should be clarified whether there is any relationship between=20
> the admission control in RFC5851, and the policy-based admission=20
> control and resource-based admission control proposed in this=20
> document. Examples will help a lot.
>=20
> In addition, in RFC 5851, CAC is an abbreviation of Connection=20
> Admission Control. This may cause confusing.
>=20
[PTT] Proposed to rely specifically on RFC 5851 terminology.
Co-authors, please verify that I have this correctly:

 1) The terms "admission control" and "Connection Admission Control (CAC)" =
mean the same thing and have to do with bandwidth allocation.

 2) "Conditional access" refers specifically to the use of white, black, an=
d grey lists.

 3) I don't need any other terms to describe the service control capabiliti=
es specified in this document.

Assuming this is correct, I'll make sure those terms are called out in Sect=
ion 2, drop any other text on the topic, and propagate the necessary change=
s throughout the rest of the document.

Apologies for being so slow to understand the correct terminology.
>=20
>=20
> 3)
>=20
> In section 4.1.1, there is a statement =1B$B!H=1B(BThe NAS SHOULD NOT inc=
lude any=20
> list type (white, black, or grey) that is not supported by the set of=20
> multicast capabilities negotiated between the NAS and the AN.=1B$B!I=1B(B
> In section 4.1.2, there is a corresponding statement =1B$B!H=1B(BIn keepi=
ng with=20
> the general rule stated in Section 4, the AN MUST ignore instances of=20
> the List-Action TLV referring to any list type (white, black, or
> grey) that is not supported by the set of multicast capabilities=20
> negotiated between the NAS and the AN.=1B$B!I=1B(B
>=20
> So, I suggest using =1B$B!H=1B(BMUST=1B$B!I=1B(B to take place of =1B$B!H=
=1B(BSHOULD=1B$B!I=1B(B in the first=20
> statement unless we can find out a scenario where the NAS needs to=20
> send out a TLV which is not supported by the AN and will be eventually=20
> discarded.
>=20
>=20
[PTT] This is an example of "be conservative in what you send and liberal (=
i.e, survive gracefully) with what you receive". I had in mind that the NAS=
 might have a template based on support of grey lists as well as white and =
black, and fill it out leaving the grey list empty.
Strictly an implementation shortcut, obviously not the required protocol be=
haviour. I don't feel strongly about SHOULD, so I'll replace it with unless=
 anyone else has a comment.
>=20
> 4)
>=20
> Section 6.1.3 lists the protocol elements that MUST be implemented to=20
> support the conditional access with white and black lists multicast=20
> capability. I found White-List-CAC TLV is included in the list.
> However, the White-List-CAC TLV is used to indicate that the NAS=20
> wishes the AN to do admission control for white-listed flows, and this=20
> use case is discussed in Section 3.4.2.3 of RFC 5851 =1B$B!H=1B(BMulticas=
t=20
> Admission Control and White Lists=1B$B!I=1B(B. So, I doubt whether this T=
LV needs=20
> to be supported is this case.
>=20
[PTT] Doesn't Section 3.4.2.3 describe a case where the AN does both admiss=
ion control and white listing, and sets the conditions for doing that?

  "IPTV is an example of a service that will not be offered as best
   effort, but requires some level of guaranteed quality of service.
   This requires the use of Multicast Admission Control.  Hence, if the
   Access Node wants to autonomously perform the admission process, it
   must be aware of the bandwidth characteristics of multicast flows.
   Otherwise, the Access Node would have to query the NAS for Multicast
   Admission Control (per the grey list behavior); this would defeat the
   purpose of using a white and black list."

> 5)
>=20
> Section 4.1.2, it is stated =1B$B!H=1B(BThe buffering time specified in a=
n=20
> instance of the Report-Buffering- Time TLV applies only to Committed=20
> Bandwidth Report messages initiated after the new buffering time is=20
> received at the AN, not to any message already in the process of=20
> accumulation .=1B$B!I=1B(B
>=20
> This policy indicates an implementation may have to maintain two or=20
> multiple accumulation processes when NAS frequently sends the
> Report-Buffering- Time TLVs to the AN and then changes the buffering=20
> time. This may not result in serious security problem but will=20
> introduce more complexity in the system implementation. So, I suggest=20
> changing the text to =1B$B!H=1B(BThe buffering time specified in an insta=
nce of=20
> the Report-Buffering- Time TLV will not be applied until the current=20
> accumulation process of Committed Bandwidth Report messages finishes.=1B$=
B!I=1B(B

[PTT] Accepted.
>=20
> 6)
>=20
> In the security consideration, the issues with the attacks on the=20
> communication channel between AAA and NAS is not sufficient. It is=20
> mentioned in this section that it is possible to download per- device=20
> policy to the NAS directly so as to eliminate the communication=20
> between NAS and AAA. I agree this is an option. However, I believe it=20
> is still worthwhile for us to discuss how to secure the communication=20
> between NAS and AAA.
>=20
[PTT] I can add references to Diameter security (with which I am
familiar) and RADIUS security (which I gather is being worked on)?
Roberta, can you help with the latter?
>=20
>=20
> Nits:
>=20
> 1)       Section 4.1.2: In keeping with the general rule stated in
> Section 4 -> In keeping with the general rule stated in Section
> 4.1.1

[PTT] The general rule is in Section 4:

  "Unless stated otherwise, receivers MUST ignore message contents that
   are not supported by the set of capabilities negotiated between the
   NAS and the Access Node."

>=20
> Typos:
>=20
> Section 4.4:      first directive that can not -> first directive
> that cannot

[PTT] OK
>=20
> Section 7:                   An attacker able to to -> An attacker
> able to

[PTT] OK
>=20
> Cheers
>=20
> Dacheng
>=20

From shanna@juniper.net  Fri Jan 24 02:54:22 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35BA61A0283; Fri, 24 Jan 2014 02:54:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 784Vyd78YoPx; Fri, 24 Jan 2014 02:54:19 -0800 (PST)
Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7576C1A0226; Fri, 24 Jan 2014 02:54:19 -0800 (PST)
Received: from mail26-co9-R.bigfish.com (10.236.132.228) by CO9EHSOBE028.bigfish.com (10.236.130.91) with Microsoft SMTP Server id 14.1.225.22; Fri, 24 Jan 2014 10:54:18 +0000
Received: from mail26-co9 (localhost [127.0.0.1])	by mail26-co9-R.bigfish.com (Postfix) with ESMTP id E574A1202BD; Fri, 24 Jan 2014 10:54:17 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -74
X-BigFish: VPS-74(zz98dI9371Ic89bh148cI542I1432I15caKJ4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL17326ah8275bh8275dh1de097h186068hz2fh109h2a8h839h947hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h24ach24d7h9a9j1155h)
Received-SPF: pass (mail26-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=shanna@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; 
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(52604005)(189002)(199002)(51704005)(13464003)(377454003)(164054003)(24454002)(55784002)(76786001)(93516002)(92566001)(54316002)(93136001)(76796001)(81816001)(33646001)(49866001)(76576001)(46102001)(76482001)(86362001)(94316002)(65816001)(77982001)(53806001)(50986001)(80976001)(56776001)(83322001)(47736001)(87266001)(79102001)(31966008)(85306002)(80022001)(87936001)(81342001)(74366001)(4396001)(47446002)(66066001)(59766001)(19580395003)(47976001)(15202345003)(19580405001)(54356001)(2656002)(74876001)(69226001)(63696002)(56816005)(74316001)(85852003)(90146001)(74502001)(81686001)(81542001)(51856001)(83072002)(74706001)(15975445006)(74662001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB737; H:BLUPR05MB737.namprd05.prod.outlook.com; CLIP:66.129.239.13; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; 
Received: from mail26-co9 (localhost.localdomain [127.0.0.1]) by mail26-co9 (MessageSwitch) id 1390560854407500_32635; Fri, 24 Jan 2014 10:54:14 +0000 (UTC)
Received: from CO9EHSMHS010.bigfish.com (unknown [10.236.132.229])	by mail26-co9.bigfish.com (Postfix) with ESMTP id 5E7DA10004B;	Fri, 24 Jan 2014 10:54:14 +0000 (UTC)
Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS010.bigfish.com (10.236.130.20) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 24 Jan 2014 10:54:13 +0000
Received: from BLUPR05MB737.namprd05.prod.outlook.com (10.141.208.17) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.395.1; Fri, 24 Jan 2014 10:54:12 +0000
Received: from BLUPR05MB737.namprd05.prod.outlook.com (10.141.208.17) by BLUPR05MB737.namprd05.prod.outlook.com (10.141.208.17) with Microsoft SMTP Server (TLS) id 15.0.851.11; Fri, 24 Jan 2014 10:54:10 +0000
Received: from BLUPR05MB737.namprd05.prod.outlook.com ([10.141.208.17]) by BLUPR05MB737.namprd05.prod.outlook.com ([10.141.208.17]) with mapi id 15.00.0851.011; Fri, 24 Jan 2014 10:54:10 +0000
From: Stephen Hanna 
To: "mohamed.boucadair@orange.com" , "secdir@ietf.org" , The IESG , "draft-ietf-pcp-nat64-prefix64.all@tools.ietf.org" 
Thread-Topic: secdir Review of draft-ietf-pcp-nat64-prefix64-04
Thread-Index: Ac8XAvhsFQvpZlpNT8uP4E8QAIyyLQBPUUuAAAMzYfAAIo4UkAAGxHpw
Date: Fri, 24 Jan 2014 10:54:09 +0000
Message-ID: <9e76a90f04f24e3aa156abcc1cca7f5e@BLUPR05MB737.namprd05.prod.outlook.com>
References: <1f794d77ca95458d9d7cf06e20950090@BLUPR05MB737.namprd05.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36F4736024C@PUEXCB1B.nanterre.francetelecom.fr> <638ccecdeecb4b458718b1c33821c092@BLUPR05MB737.namprd05.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36F473603EB@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F473603EB@PUEXCB1B.nanterre.francetelecom.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.239.13]
x-forefront-prvs: 01018CB5B3
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Subject: Re: [secdir] secdir Review of draft-ietf-pcp-nat64-prefix64-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jan 2014 10:54:22 -0000

Med,

Thanks for addressing so many of my concerns. I'm happy with
the changes that you have made.

I didn't see a response to issue 9) below (about RFC 7050).
Do you have any plans to address that?

Thanks,

Steve

> -----Original Message-----
> From: mohamed.boucadair@orange.com
> [mailto:mohamed.boucadair@orange.com]
> Sent: Friday, January 24, 2014 3:56 AM
> To: Stephen Hanna; secdir@ietf.org; The IESG; draft-ietf-pcp-nat64-
> prefix64.all@tools.ietf.org
> Subject: RE: secdir Review of draft-ietf-pcp-nat64-prefix64-04
>=20
> Dear Stephen,
>=20
> Please see inline.
>=20
> Cheers,
> Med
>=20
> >-----Message d'origine-----
> >De=A0: Stephen Hanna [mailto:shanna@juniper.net]
> >Envoy=E9=A0: jeudi 23 janvier 2014 16:20
> >=C0=A0: BOUCADAIR Mohamed IMT/OLN; secdir@ietf.org; The IESG; draft-ietf=
-
> pcp-
> >nat64-prefix64.all@tools.ietf.org
> >Objet=A0: RE: secdir Review of draft-ietf-pcp-nat64-prefix64-04
> >
> >Med,
> >
> >Thanks for your response. Coming along nicely!
> >
> >A few comments on your changes below, marked with [SRH].
> >
> >Thanks,
> >
> >Steve
> >
> >Med wrote:
> >> Steve wrote:
> >> >1) The second paragraph of the Security Considerations section
> >> >   points out that if an attacker can fool a host into using
> >> >   the wrong value for Pref64::/n, the traffic generated using
> >> >   that value will be delivered to the wrong location. That's
> >> >   right but not all the implications are mentioned. A MITM
> >> >   (Man In The Middle) attack can be performed in this manner,
> >> >   permitting alterations to the traffic (not just eavesdropping).
> >> >   This should be mentioned.
> >> [Med] I updated the text as follows:
> >>
> >> OLD:
> >>
> >>    As discussed in [RFC6147], if an attacker can manage to change
> the
> >>    Pref64::/n used by the DNS64 function, the traffic generated by
> the
> >>    host that receives the synthetic reply will be delivered to the
> >>    altered Pref64.  This can result in either a denial-of-service
> (DoS)
> >>    attack, a flooding attack, or an eavesdropping attack.  This
> attack
> >>    could be achieved either by altering PCP messages issued by a
> >>    legitimate PCP server or by using a fake PCP server.
> >>
> >> NEW:
> >>
> >>    As discussed in [RFC6147], if an attacker can manage to change
> the
> >>    Pref64::/n used by the DNS64 function, the traffic generated by
> the
> >>    host that receives the synthetic reply will be delivered to the
> >>    altered Pref64.  This can result in either a denial-of-service
> (DoS)
> >>    attack, a flooding attack, or a MIM (Man In The Middle) attack.
> >> This attack
> >>    could be achieved either by altering PCP messages issued by a
> >>    legitimate PCP server or by using a fake PCP server.
> >>
> >> Better?
> >
> >[SRH] Yes, but the conventional abbreviation for
> >Man In The Middle is MITM not MIM. Who knows why?!
> [Med] Fixed.
>=20
> >
> >> >2) The next paragraph of the Security Considerations section
> >> >   suggests defenses to prevent the attacker from substituting
> >> >   the wrong value for Pref64::/n. However, the defense that
> >> >   is suggested (IP-based ACLs on the PCP server, client, or
> >> >   network) won't help much. Attackers can just place the
> >> >   PCP server's IP address in the source address of the fake
> >> >   PCP response packet sent by the attack.
> >>
> >> [Med] anti-spoofing filters can be used to prevent such attack.
> Ingress
> >> filters can be also enforced at boundaries of a domain to prevent
> such
> >> attack. I do think the text is still correct.
> >
> >[SRH] These countermeasures provide no defense against an attacker
> >who is on the path from the PCP server to the client. This is
> >not a theoretical attack, as described in certain news reports
> >recently (Der Spiegel).
> [Med] The deployment I have in mind is a pcp service offered by a
> service provider while pcp clients are hosted in a CPE or in connected
> devices (either behind the CPE or directly to the service provider
> network). To achieve the attack vector you described, the mis-behaving
> node should be in the service provider network or connected to that
> network. If that service provider enforced anti-spoofing filters, then
> a mis-behaving node cannot act as a fake pcp server.
>=20
> I understand this is a deployment case among others. So to be accurate,
> I changed the text as follows:
>=20
> OLD:
>    For example, access control lists (ACLs) can be installed on the PCP
>    client, PCP server, and the network between them, so those ACLs
> allow
>    only communications from a trusted PCP server to the PCP client.
>=20
> NEW:
>    In some deployments, access control lists (ACLs) can be installed on
>    the PCP client, PCP server, and the network between them, so those
>    ACLs allow only communications from a trusted PCP server to the PCP
>    client.
>=20
>=20
> >
> >> > The nonce in the
> >> >   MAP or PEER response means that the attacker must capture
> >> >   or predict this value but no nonce is present in the ANNOUNCE
> >> >   response so that would probably be the preferred attack
> >> >   method, especially since ANNOUNCE responses can be sent
> >> >   out via multicast at any time. I suggest that the spec
> >> >   prohibit sending the PREFIX64 option in a multicast
> >> >   ANNOUNCE response, unless effective countermeasures for
> >> >   this attack are found.
> >> [Med] Isn't this covered by this text:
> >>
> >> "   Means to defend against attackers who can modify packets between
> >> the
> >>    PCP server and the PCP client, or who can inject spoofed packets
> >> that
> >>    appear to come from a legitimate PCP server SHOULD be enabled."
> >
> >[SRH] That would be a reasonable countermeasure if such means
> >actually existed. Could you describe what those means
> >would be? As I mentioned above, ingress filters and
> >anti-spoofing filters are ineffective against on-path
> >attackers.
> [Med] As mentioned above, ACLs are sufficient in some deployment
> contexts.
>=20
>=20
> >
> >> >In addition to these security issues, I found some other issues
> >> >that are not related to security:
> >> >
> >> >1) You should explain that RFC 6146 defines Pref64::/n.
> >> >   Otherwise, that term is quite cryptic.
> >> [Med] I added this new sentence:
> >>
> >>    According to [RFC6146], NAT64 uses Pref64::/n to construct
> >>    IPv4-Converted IPv6 addresses as defined in [RFC6052].
> >>
> >> Better?
> >
> >[SRH] Great!
> >
> >[SRH] Deleted several more comments that you have addressed.
> >
> >> >6) Text near the top of page 8 says "The PCP server can be
> >> >   configured with a customized IPv6 prefix list" but that
> >> >   won't work when PREFIX64 is added to a multicast ANNOUNCE
> >> >   response. That's another reason not to permit this, in
> >> >   addition to security issue 2) above.
> >> [Med] I added this sentence:
> >>
> >> " Note, it is NOT
> >>       RECOMMENDED to include PREFIX64 options in ANNOUNCE messages
> if a
> >>       customized IPv6 prefix list is configured to the PCP server. "
> >>
> >> Better?
> >
> >[SRH] Maybe. Is there some way that including PREFIX64 options in
> >ANNOUNCE messages will work if a customized IPv6 prefix list
> >is configured to the PCP server? If not, this should be a
> >MUST NOT instead of a NOT RECOMMENDED.
>=20
> [Med] An example is the use of separate zones (see for instance
> http://tools.ietf.org/search/draft-penno-pcp-zones-01) or if several
> logical topologies are configured.
>=20
> >
> >> >7) When IPv4 prefix lists are configured and multiple IPv6
> >> >   prefix lists are also configured, the first PREFIX64
> >> >   option includes the IPv4 prefix lists. Can the later
> >> >   PREFIX64 options also include their own IPv4 prefix
> >> >   lists? If one or more of those later PREFIX64 options
> >> >   does NOT have its own IPv4 prefix list, what does that
> >> >   mean? Does it inherit the IPv4 prefix list of the
> >> >   previous PREFIX64 option? The current text is not clear.
> >> [Med] Only the first occurrence can carry the IPv4 prefix because
> other
> >> occurrences are not used by building IPv4-converted addresses, but
> only
> >> to distinguish these addresses if received in referrals. I can add a
> >> sentence to indicate this explicitly in the text.
> >
> >[SRH] Thanks. Please do.
> [Med] I added this sentence to Section 4.1:
>=20
> " When multiple PREFIX64 options are included in the same PCP message,
> only the first PREFIX64 option occurrence may include the IPv4 Prefix
> List field."
>=20
>=20
> >
> >> >8) The example in section 5.1 says that it "depicts a
> >> >   typical usage of the PREFIX64 option when a DNS64
> >> >   capability is embedded in the host." Did you mean
> >> >   "is not embedded"? I don't see how DNS64 is being
> >> >   used in this example.
> >>
> >> [Med] The text is correct. DNS64 is used to form locally an IPv4-
> >> converted IPv6 address. The example assumes the address of the IPv4
> >> server is retrieved using A records. DNS exchanges are not mentioned
> in
> >> the figure to avoid overloading it.
> >
> >[SRH] OK. You may want to explain this a bit more.
> [Med] I made this change:
>=20
> OLD:
> "once the IPv6-only client discovers the IPv4 address of the remote
> IPv4-only server"
>=20
> NEW:
> " once the IPv6-only client discovers the IPv4 address of the remote
> IPv4-only server (e.g., using DNS)"
>=20
> and added this sentence:
>=20
> " Note: DNS exchange to retrieve the IPv4 address of
>       the IPv4-only Server is not shown in the figure. "
>=20
> >
> >> >9) Is this document still relevant? RFC 7051 says:
> >> >
> >> >   Our conclusion is to recommend publishing the Well-Known DNS
> Name
> >> >   heuristic discovery-based method as a Standards Track IETF
> document
> >> >   for applications and host implementors to implement as-is.
> >> >
> >> >   With that, is there still a need for this document?
> >> [Med] Yes, this is explicitly mentioned in the shepherded text of
> >> RFC7050. Please refer to
> >> https://datatracker.ietf.org/doc/rfc7050/history/
> >>
> >> "    The document specifies a heuristic that is not perfect and so
> some
> >>     points were rough, but the constraint for this document was to
> >> operate
> >>     without changes to code (only configuration) in existing
> networks.
> >>     Given that constraint, there was strong consensus.  Relaxing the
> >>     constraint would allow one to do better, and that is the focus
> of a
> >>     draft recently submitted to the PCP WG."
> >
> >[SRH] OK, fine. You might want to mention that in your draft.
> >Otherwise, other readers may have the same confusion. They're
> >not likely to read the shepherd text for RFC 7050!
> >
>=20
>=20



From benl@google.com  Fri Jan 24 03:26:01 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 181BD1A02BA for ; Fri, 24 Jan 2014 03:26:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.914
X-Spam-Level: 
X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6wNqSMQu_YT for ; Fri, 24 Jan 2014 03:25:58 -0800 (PST)
Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 6119E1A02BD for ; Fri, 24 Jan 2014 03:25:58 -0800 (PST)
Received: by mail-ie0-f172.google.com with SMTP id e14so2656419iej.17 for ; Fri, 24 Jan 2014 03:25:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zA9h1DN5/OEgU7AWwnWO8cBThX0bxxXFJqtsN92vwoo=; b=dSw/IUJ0BprebTmmFwaPEnFXv1JmNA91b9xufRiusBs+B87Z4AMoFd2xxQyRVA3zM0 8cLf4Wm4yM6GfD0YggxyFf9t56JOypcYSXeBJVbIrKaljz99qV8FeOrj0Kor0q+iyy53 d7skiqVwHSLbCU1mQx+/U/wDbGyK8Tlkx/GKLysmJsM2Ts12nGTvkuCsUm/VEXgzfZWn M3hpKra5AZoeaXGvziFVxMbY5QmHDQibtkKSaaIHKIHc315BeE1Vh33Np7BvWxvdlhPc YUnwc0mMllN+Pu2Duub5kn1ilk3ha2YJ9qcJopEyVhMsSavZPfCInDmhyvE954YjJVil +ZXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zA9h1DN5/OEgU7AWwnWO8cBThX0bxxXFJqtsN92vwoo=; b=d8dRyNewNwaweri1nibl6BlafPyBbZAWb9zHnYzMAd88b8GPME+JnZSvVE/grWKhk7 nsgxx63/K4wrtHkZ8gX1a1zWZXdESjCTU0okx9EMY2ObYwS2HgltLiPTiTvXqBj78jna 34Xh9QooDj9H1nM5NZG+3ILMLItunIzlSUZHTqvrwqYKKmJl4OFGKrtbxZSc342DDtI0 fKnHSogk4FzZ2nLI7XidGnD8a0T0LjLwGpoBgj5H6NO6fv+K46yYzpaiN0kEWncVhPPB WQQJiYRLW9b+p8RnBRQYfhGhRU29yiYyh/bEfAHdpWwFHImdcEBoo1ZdX+jJ4JAZBuKb iToQ==
X-Gm-Message-State: ALoCoQmrw9p5/Iwt8oXtFk9F4QakZkvRadhTWw2BgT+2/eO8frSSAdxL97faDpGCmmrBTjwan73doRUDuOwu5a+L/1WLPtAElX5xiUIhB/hAFaY2eqxx0gNDYuk86Ox79GgJu+OwIoORcB4SMMZ6SGpaUgk/SwrRcgk+s0kP+LzReCIJdOnGkzzyT6nY0X+6ITBhtXaxGY0m
MIME-Version: 1.0
X-Received: by 10.50.161.132 with SMTP id xs4mr3976276igb.38.1390562755602; Fri, 24 Jan 2014 03:25:55 -0800 (PST)
Received: by 10.64.230.140 with HTTP; Fri, 24 Jan 2014 03:25:55 -0800 (PST)
In-Reply-To: <57C3345230A4F94C9B2F5CFA05D7F2BD1D570589@xmb-rcd-x01.cisco.com>
References: <57C3345230A4F94C9B2F5CFA05D7F2BD1D570589@xmb-rcd-x01.cisco.com>
Date: Fri, 24 Jan 2014 11:25:55 +0000
Message-ID: 
From: Ben Laurie 
To: "Roberta Maglione (robmgl)" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "secdir@ietf.org" , "draft-ietf-ancp-mc-extensions.all@tools.ietf.org" , "iesg@ietf.org" , Tom Taylor 
Subject: Re: [secdir] secdir review of draft-ietf-ancp-mc-extensions-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jan 2014 11:26:01 -0000

On 24 January 2014 00:43, Roberta Maglione (robmgl)  wrot=
e:
> Tom,
>
> Regarding this point:
>>[PTT] I can add references to Diameter security (with which I am
>>familiar) and RADIUS security (which I gather is being worked on)?
>>Roberta, can you help with the latter?
>
> I'm not very familiar with security, but as far as I know RADIUS security=
 is based on the MD5 algorithm, which has been proven to be  insecure.

Whilst it is generally a good idea to retire MD5, it hasn't actually
been proved insecure for the use RADIUS makes of it.

> In order to overcome this issue " Transport Layer Security (TLS) Encrypti=
on for RADIUS" has been specified in RFC 6614, I think we should add a refe=
rence to this RFC.
> I'm cc-ing Klaas who is one of the author of this RFC in order to get his=
 feedback too.
>
> Thanks
> Regards
> Roberta
>
> -----Original Message-----
> From: Tom Taylor [mailto:tom.taylor.stds@gmail.com]
> Sent: Thursday, January 23, 2014 7:19 PM
> To: Zhangdacheng (Dacheng); iesg@ietf.org; secdir@ietf.org; draft-ietf-an=
cp-mc-extensions.all@tools.ietf.org
> Subject: Re: [spam] [secdir] secdir review of draft-ietf-ancp-mc-extensio=
ns-14
>
> Again, thank you for the work you out into this review. Responses marked =
with [PTT].
>
> On 22/01/2014 1:47 AM, Zhangdacheng (Dacheng) wrote:
>> Hello=EF=BC=9A
>>
>>
>> I have reviewed this document as part of the security directorate's
>> ongoing effort to review all IETF documents being processed by the
>> IESG.  These comments were written primarily for the benefit of the
>> security area directors.  Document editors and WG chairs should treat
>> these comments just like any other last call comments.
>>
>> This draft specifies the extensions to the Access Node Control
>> Protocol [RFC6320] required for support of the multicast use cases
>> proposed in [RFC5851].
>>
>> This huge document is well written. The authors must have spent much
>> energy on this work.
>>
>> Follows are some questions and comments:
>>
>> 1)
>>
>> In the introduction, there is a statement =E2=80=9CConditional access is
>> described in Section 3.4.1 and Section 3.4.2.3 of [RFC5851], with the
>> latter section particularly applicable to operation with white and
>> black lists only=E2=80=9D
>>
>> Section 3.4.2.3 of RFC5851 actually discusses how admission control
>> may defeat the purpose of using a white and black list. So, I suggest
>> re-writing this text.
>
> [PTT] Proposed to rephrase as follows:
>
> "Conditional access is described in Section 3.4.1 of [RFC5851]. Section
> 3.4.2.2 mentions a way in which conditional access can be combined with a=
dmission control to allow best effort multicast flows. Section 3.4.2.3 poin=
ts out the necessary conditions for using both conditional access and admis=
sion control."
>>
>> 2)
>>
>> It would make the document easier to understand if the key terms can
>> be clearly introduced. So, I suggest refining Section 2.
>>
>> In details, terms such as =E2=80=9CConditional Access=E2=80=9D, =E2=80=
=9Cadmission control=E2=80=9D,
>> and "conditional access and admission control (CAC)" are widely used
>> in this draft. In addition, this document specifies that conditional
>> access and admission control can consist of two parts: policy-based
>> admission control and resource-based admission control. However, there
>> is no clear definition provided about those terms.
>>
>> According to RFC5851, conditional access can use white, back, and grey
>> lists to manage the generation of multicast flows, while admission
>> control is used in the cases where the bandwidth reservation for newly
>> generated flows is required.
>>
>> So, it should be clarified whether there is any relationship between
>> the admission control in RFC5851, and the policy-based admission
>> control and resource-based admission control proposed in this
>> document. Examples will help a lot.
>>
>> In addition, in RFC 5851, CAC is an abbreviation of Connection
>> Admission Control. This may cause confusing.
>>
> [PTT] Proposed to rely specifically on RFC 5851 terminology.
> Co-authors, please verify that I have this correctly:
>
>  1) The terms "admission control" and "Connection Admission Control (CAC)=
" mean the same thing and have to do with bandwidth allocation.
>
>  2) "Conditional access" refers specifically to the use of white, black, =
and grey lists.
>
>  3) I don't need any other terms to describe the service control capabili=
ties specified in this document.
>
> Assuming this is correct, I'll make sure those terms are called out in Se=
ction 2, drop any other text on the topic, and propagate the necessary chan=
ges throughout the rest of the document.
>
> Apologies for being so slow to understand the correct terminology.
>>
>>
>> 3)
>>
>> In section 4.1.1, there is a statement =E2=80=9CThe NAS SHOULD NOT inclu=
de any
>> list type (white, black, or grey) that is not supported by the set of
>> multicast capabilities negotiated between the NAS and the AN.=E2=80=9D
>> In section 4.1.2, there is a corresponding statement =E2=80=9CIn keeping=
 with
>> the general rule stated in Section 4, the AN MUST ignore instances of
>> the List-Action TLV referring to any list type (white, black, or
>> grey) that is not supported by the set of multicast capabilities
>> negotiated between the NAS and the AN.=E2=80=9D
>>
>> So, I suggest using =E2=80=9CMUST=E2=80=9D to take place of =E2=80=9CSHO=
ULD=E2=80=9D in the first
>> statement unless we can find out a scenario where the NAS needs to
>> send out a TLV which is not supported by the AN and will be eventually
>> discarded.
>>
>>
> [PTT] This is an example of "be conservative in what you send and liberal=
 (i.e, survive gracefully) with what you receive". I had in mind that the N=
AS might have a template based on support of grey lists as well as white an=
d black, and fill it out leaving the grey list empty.
> Strictly an implementation shortcut, obviously not the required protocol =
behaviour. I don't feel strongly about SHOULD, so I'll replace it with unle=
ss anyone else has a comment.
>>
>> 4)
>>
>> Section 6.1.3 lists the protocol elements that MUST be implemented to
>> support the conditional access with white and black lists multicast
>> capability. I found White-List-CAC TLV is included in the list.
>> However, the White-List-CAC TLV is used to indicate that the NAS
>> wishes the AN to do admission control for white-listed flows, and this
>> use case is discussed in Section 3.4.2.3 of RFC 5851 =E2=80=9CMulticast
>> Admission Control and White Lists=E2=80=9D. So, I doubt whether this TLV=
 needs
>> to be supported is this case.
>>
> [PTT] Doesn't Section 3.4.2.3 describe a case where the AN does both admi=
ssion control and white listing, and sets the conditions for doing that?
>
>   "IPTV is an example of a service that will not be offered as best
>    effort, but requires some level of guaranteed quality of service.
>    This requires the use of Multicast Admission Control.  Hence, if the
>    Access Node wants to autonomously perform the admission process, it
>    must be aware of the bandwidth characteristics of multicast flows.
>    Otherwise, the Access Node would have to query the NAS for Multicast
>    Admission Control (per the grey list behavior); this would defeat the
>    purpose of using a white and black list."
>
>> 5)
>>
>> Section 4.1.2, it is stated =E2=80=9CThe buffering time specified in an
>> instance of the Report-Buffering- Time TLV applies only to Committed
>> Bandwidth Report messages initiated after the new buffering time is
>> received at the AN, not to any message already in the process of
>> accumulation .=E2=80=9D
>>
>> This policy indicates an implementation may have to maintain two or
>> multiple accumulation processes when NAS frequently sends the
>> Report-Buffering- Time TLVs to the AN and then changes the buffering
>> time. This may not result in serious security problem but will
>> introduce more complexity in the system implementation. So, I suggest
>> changing the text to =E2=80=9CThe buffering time specified in an instanc=
e of
>> the Report-Buffering- Time TLV will not be applied until the current
>> accumulation process of Committed Bandwidth Report messages finishes.=E2=
=80=9D
>
> [PTT] Accepted.
>>
>> 6)
>>
>> In the security consideration, the issues with the attacks on the
>> communication channel between AAA and NAS is not sufficient. It is
>> mentioned in this section that it is possible to download per- device
>> policy to the NAS directly so as to eliminate the communication
>> between NAS and AAA. I agree this is an option. However, I believe it
>> is still worthwhile for us to discuss how to secure the communication
>> between NAS and AAA.
>>
> [PTT] I can add references to Diameter security (with which I am
> familiar) and RADIUS security (which I gather is being worked on)?
> Roberta, can you help with the latter?
>>
>>
>> Nits:
>>
>> 1)       Section 4.1.2: In keeping with the general rule stated in
>> Section 4 -> In keeping with the general rule stated in Section
>> 4.1.1
>
> [PTT] The general rule is in Section 4:
>
>   "Unless stated otherwise, receivers MUST ignore message contents that
>    are not supported by the set of capabilities negotiated between the
>    NAS and the Access Node."
>
>>
>> Typos:
>>
>> Section 4.4:      first directive that can not -> first directive
>> that cannot
>
> [PTT] OK
>>
>> Section 7:                   An attacker able to to -> An attacker
>> able to
>
> [PTT] OK
>>
>> Cheers
>>
>> Dacheng
>>
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

From tom.taylor.stds@gmail.com  Fri Jan 24 03:56:13 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 019AE1A02B8; Fri, 24 Jan 2014 03:56:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id di37Rn1o6ejL; Fri, 24 Jan 2014 03:56:11 -0800 (PST)
Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 88E9F1A02BA; Fri, 24 Jan 2014 03:56:11 -0800 (PST)
Received: by mail-ig0-f182.google.com with SMTP id uy17so2340245igb.3 for ; Fri, 24 Jan 2014 03:56:10 -0800 (PST)
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=F1eK1Fi0GzvhwGkal/wTOCN0UYKdZzwdQYQ0A8zWPHg=; b=JmvbP+8CroWED9TZCWNFE39LuvRS4Ct/jG70IwwtUd3u224f6lvynTgQekSeWvCTUh swEVCeIj7/hEDUZoYt6BFTppGLrArpXzTrDsckJp6Yw13EMr8owXWX+tUQJSIRiPnaIm 8BVBBJ00XmuLY2a6cS1tu7rPm6c4Z6QmnIqMX1XxpUELNA3RHQf7iu7xa9IBeDH3RCBC YZ4V6kvC5BJC1RmI+zMVnXC2ZNItGN4Bkp80lUep94nz9Q+ENcxQxnqNNarFWH3EEBdt gJLqrCvAyK1xXcyxFXhzmYDGrXOJMmscLahXahK9q4QtYLzXas64MT3ysDo908/8ki7r 7Few==
X-Received: by 10.50.154.102 with SMTP id vn6mr4068572igb.1.1390564570320; Fri, 24 Jan 2014 03:56:10 -0800 (PST)
Received: from [192.168.1.69] ([64.56.225.169]) by mx.google.com with ESMTPSA id x6sm9306429igb.3.2014.01.24.03.56.09 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 Jan 2014 03:56:09 -0800 (PST)
Message-ID: <52E254D6.7000804@gmail.com>
Date: Fri, 24 Jan 2014 06:56:06 -0500
From: Tom Taylor 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Ben Laurie ,  "Roberta Maglione (robmgl)" 
References: <57C3345230A4F94C9B2F5CFA05D7F2BD1D570589@xmb-rcd-x01.cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "draft-ietf-ancp-mc-extensions.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" 
Subject: Re: [secdir] secdir review of draft-ietf-ancp-mc-extensions-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jan 2014 11:56:13 -0000

Based on a totally separate discussion (in 6man), it would be preferable 
not to mention MD-5 in a new IETF document.

Tom Taylor

On 24/01/2014 6:25 AM, Ben Laurie wrote:
> On 24 January 2014 00:43, Roberta Maglione (robmgl)  wrote:
>> Tom,
>>
>> Regarding this point:
>>> [PTT] I can add references to Diameter security (with which I am
>>> familiar) and RADIUS security (which I gather is being worked on)?
>>> Roberta, can you help with the latter?
>>
>> I'm not very familiar with security, but as far as I know RADIUS security is based on the MD5 algorithm, which has been proven to be  insecure.
>
> Whilst it is generally a good idea to retire MD5, it hasn't actually
> been proved insecure for the use RADIUS makes of it.
>
>> In order to overcome this issue " Transport Layer Security (TLS) Encryption for RADIUS" has been specified in RFC 6614, I think we should add a reference to this RFC.
>> I'm cc-ing Klaas who is one of the author of this RFC in order to get his feedback too.
>>
>> Thanks
>> Regards
>> Roberta
>>
>> -----Original Message-----
>> From: Tom Taylor [mailto:tom.taylor.stds@gmail.com]
>> Sent: Thursday, January 23, 2014 7:19 PM
>> To: Zhangdacheng (Dacheng); iesg@ietf.org; secdir@ietf.org; draft-ietf-ancp-mc-extensions.all@tools.ietf.org
>> Subject: Re: [spam] [secdir] secdir review of draft-ietf-ancp-mc-extensions-14
>>
>> Again, thank you for the work you out into this review. Responses marked with [PTT].
>>
>> On 22/01/2014 1:47 AM, Zhangdacheng (Dacheng) wrote:
>>> Hello：
>>>
>>>
...

From mohamed.boucadair@orange.com  Fri Jan 24 04:51:10 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22E251A02F5; Fri, 24 Jan 2014 04:51:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.549
X-Spam-Level: 
X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECjsEduYMDIo; Fri, 24 Jan 2014 04:51:07 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA461A02D1; Fri, 24 Jan 2014 04:51:07 -0800 (PST)
Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 411A22AC3F8; Fri, 24 Jan 2014 13:51:05 +0100 (CET)
Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 21BF318004F; Fri, 24 Jan 2014 13:51:02 +0100 (CET)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Fri, 24 Jan 2014 13:51:01 +0100
From: 
To: Stephen Hanna , "secdir@ietf.org" , The IESG , "draft-ietf-pcp-nat64-prefix64.all@tools.ietf.org" 
Date: Fri, 24 Jan 2014 13:51:00 +0100
Thread-Topic: secdir Review of draft-ietf-pcp-nat64-prefix64-04
Thread-Index: Ac8XAvhsFQvpZlpNT8uP4E8QAIyyLQBPUUuAAAMzYfAAIo4UkAAGxHpwAAQQFCA=
Message-ID: <94C682931C08B048B7A8645303FDC9F36F4736056F@PUEXCB1B.nanterre.francetelecom.fr>
References: <1f794d77ca95458d9d7cf06e20950090@BLUPR05MB737.namprd05.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36F4736024C@PUEXCB1B.nanterre.francetelecom.fr> <638ccecdeecb4b458718b1c33821c092@BLUPR05MB737.namprd05.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36F473603EB@PUEXCB1B.nanterre.francetelecom.fr> <9e76a90f04f24e3aa156abcc1cca7f5e@BLUPR05MB737.namprd05.prod.outlook.com>
In-Reply-To: <9e76a90f04f24e3aa156abcc1cca7f5e@BLUPR05MB737.namprd05.prod.outlook.com>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.24.102114
Subject: Re: [secdir] secdir Review of draft-ietf-pcp-nat64-prefix64-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jan 2014 12:51:10 -0000

Re-,

For issue#9, I didn't added any change for the moment but will reconsider i=
t if we received a similar comment during the WGLC.=20

The next revision of the draft will include what we have agreed so far.

Thank you very much for your careful review. Much appreciated !

Cheers,
Med

>-----Message d'origine-----
>De=A0: Stephen Hanna [mailto:shanna@juniper.net]
>Envoy=E9=A0: vendredi 24 janvier 2014 11:54
>=C0=A0: BOUCADAIR Mohamed IMT/OLN; secdir@ietf.org; The IESG; draft-ietf-p=
cp-
>nat64-prefix64.all@tools.ietf.org
>Objet=A0: RE: secdir Review of draft-ietf-pcp-nat64-prefix64-04
>
>Med,
>
>Thanks for addressing so many of my concerns. I'm happy with
>the changes that you have made.
>
>I didn't see a response to issue 9) below (about RFC 7050).
>Do you have any plans to address that?
>
>Thanks,
>
>Steve
>
>> -----Original Message-----
>> From: mohamed.boucadair@orange.com
>> [mailto:mohamed.boucadair@orange.com]
>> Sent: Friday, January 24, 2014 3:56 AM
>> To: Stephen Hanna; secdir@ietf.org; The IESG; draft-ietf-pcp-nat64-
>> prefix64.all@tools.ietf.org
>> Subject: RE: secdir Review of draft-ietf-pcp-nat64-prefix64-04
>>
>> Dear Stephen,
>>
>> Please see inline.
>>
>> Cheers,
>> Med
>>
>> >-----Message d'origine-----
>> >De=A0: Stephen Hanna [mailto:shanna@juniper.net]
>> >Envoy=E9=A0: jeudi 23 janvier 2014 16:20
>> >=C0=A0: BOUCADAIR Mohamed IMT/OLN; secdir@ietf.org; The IESG; draft-iet=
f-
>> pcp-
>> >nat64-prefix64.all@tools.ietf.org
>> >Objet=A0: RE: secdir Review of draft-ietf-pcp-nat64-prefix64-04
>> >
>> >Med,
>> >
>> >Thanks for your response. Coming along nicely!
>> >
>> >A few comments on your changes below, marked with [SRH].
>> >
>> >Thanks,
>> >
>> >Steve
>> >
>> >Med wrote:
>> >> Steve wrote:
>> >> >1) The second paragraph of the Security Considerations section
>> >> >   points out that if an attacker can fool a host into using
>> >> >   the wrong value for Pref64::/n, the traffic generated using
>> >> >   that value will be delivered to the wrong location. That's
>> >> >   right but not all the implications are mentioned. A MITM
>> >> >   (Man In The Middle) attack can be performed in this manner,
>> >> >   permitting alterations to the traffic (not just eavesdropping).
>> >> >   This should be mentioned.
>> >> [Med] I updated the text as follows:
>> >>
>> >> OLD:
>> >>
>> >>    As discussed in [RFC6147], if an attacker can manage to change
>> the
>> >>    Pref64::/n used by the DNS64 function, the traffic generated by
>> the
>> >>    host that receives the synthetic reply will be delivered to the
>> >>    altered Pref64.  This can result in either a denial-of-service
>> (DoS)
>> >>    attack, a flooding attack, or an eavesdropping attack.  This
>> attack
>> >>    could be achieved either by altering PCP messages issued by a
>> >>    legitimate PCP server or by using a fake PCP server.
>> >>
>> >> NEW:
>> >>
>> >>    As discussed in [RFC6147], if an attacker can manage to change
>> the
>> >>    Pref64::/n used by the DNS64 function, the traffic generated by
>> the
>> >>    host that receives the synthetic reply will be delivered to the
>> >>    altered Pref64.  This can result in either a denial-of-service
>> (DoS)
>> >>    attack, a flooding attack, or a MIM (Man In The Middle) attack.
>> >> This attack
>> >>    could be achieved either by altering PCP messages issued by a
>> >>    legitimate PCP server or by using a fake PCP server.
>> >>
>> >> Better?
>> >
>> >[SRH] Yes, but the conventional abbreviation for
>> >Man In The Middle is MITM not MIM. Who knows why?!
>> [Med] Fixed.
>>
>> >
>> >> >2) The next paragraph of the Security Considerations section
>> >> >   suggests defenses to prevent the attacker from substituting
>> >> >   the wrong value for Pref64::/n. However, the defense that
>> >> >   is suggested (IP-based ACLs on the PCP server, client, or
>> >> >   network) won't help much. Attackers can just place the
>> >> >   PCP server's IP address in the source address of the fake
>> >> >   PCP response packet sent by the attack.
>> >>
>> >> [Med] anti-spoofing filters can be used to prevent such attack.
>> Ingress
>> >> filters can be also enforced at boundaries of a domain to prevent
>> such
>> >> attack. I do think the text is still correct.
>> >
>> >[SRH] These countermeasures provide no defense against an attacker
>> >who is on the path from the PCP server to the client. This is
>> >not a theoretical attack, as described in certain news reports
>> >recently (Der Spiegel).
>> [Med] The deployment I have in mind is a pcp service offered by a
>> service provider while pcp clients are hosted in a CPE or in connected
>> devices (either behind the CPE or directly to the service provider
>> network). To achieve the attack vector you described, the mis-behaving
>> node should be in the service provider network or connected to that
>> network. If that service provider enforced anti-spoofing filters, then
>> a mis-behaving node cannot act as a fake pcp server.
>>
>> I understand this is a deployment case among others. So to be accurate,
>> I changed the text as follows:
>>
>> OLD:
>>    For example, access control lists (ACLs) can be installed on the PCP
>>    client, PCP server, and the network between them, so those ACLs
>> allow
>>    only communications from a trusted PCP server to the PCP client.
>>
>> NEW:
>>    In some deployments, access control lists (ACLs) can be installed on
>>    the PCP client, PCP server, and the network between them, so those
>>    ACLs allow only communications from a trusted PCP server to the PCP
>>    client.
>>
>>
>> >
>> >> > The nonce in the
>> >> >   MAP or PEER response means that the attacker must capture
>> >> >   or predict this value but no nonce is present in the ANNOUNCE
>> >> >   response so that would probably be the preferred attack
>> >> >   method, especially since ANNOUNCE responses can be sent
>> >> >   out via multicast at any time. I suggest that the spec
>> >> >   prohibit sending the PREFIX64 option in a multicast
>> >> >   ANNOUNCE response, unless effective countermeasures for
>> >> >   this attack are found.
>> >> [Med] Isn't this covered by this text:
>> >>
>> >> "   Means to defend against attackers who can modify packets between
>> >> the
>> >>    PCP server and the PCP client, or who can inject spoofed packets
>> >> that
>> >>    appear to come from a legitimate PCP server SHOULD be enabled."
>> >
>> >[SRH] That would be a reasonable countermeasure if such means
>> >actually existed. Could you describe what those means
>> >would be? As I mentioned above, ingress filters and
>> >anti-spoofing filters are ineffective against on-path
>> >attackers.
>> [Med] As mentioned above, ACLs are sufficient in some deployment
>> contexts.
>>
>>
>> >
>> >> >In addition to these security issues, I found some other issues
>> >> >that are not related to security:
>> >> >
>> >> >1) You should explain that RFC 6146 defines Pref64::/n.
>> >> >   Otherwise, that term is quite cryptic.
>> >> [Med] I added this new sentence:
>> >>
>> >>    According to [RFC6146], NAT64 uses Pref64::/n to construct
>> >>    IPv4-Converted IPv6 addresses as defined in [RFC6052].
>> >>
>> >> Better?
>> >
>> >[SRH] Great!
>> >
>> >[SRH] Deleted several more comments that you have addressed.
>> >
>> >> >6) Text near the top of page 8 says "The PCP server can be
>> >> >   configured with a customized IPv6 prefix list" but that
>> >> >   won't work when PREFIX64 is added to a multicast ANNOUNCE
>> >> >   response. That's another reason not to permit this, in
>> >> >   addition to security issue 2) above.
>> >> [Med] I added this sentence:
>> >>
>> >> " Note, it is NOT
>> >>       RECOMMENDED to include PREFIX64 options in ANNOUNCE messages
>> if a
>> >>       customized IPv6 prefix list is configured to the PCP server. "
>> >>
>> >> Better?
>> >
>> >[SRH] Maybe. Is there some way that including PREFIX64 options in
>> >ANNOUNCE messages will work if a customized IPv6 prefix list
>> >is configured to the PCP server? If not, this should be a
>> >MUST NOT instead of a NOT RECOMMENDED.
>>
>> [Med] An example is the use of separate zones (see for instance
>> http://tools.ietf.org/search/draft-penno-pcp-zones-01) or if several
>> logical topologies are configured.
>>
>> >
>> >> >7) When IPv4 prefix lists are configured and multiple IPv6
>> >> >   prefix lists are also configured, the first PREFIX64
>> >> >   option includes the IPv4 prefix lists. Can the later
>> >> >   PREFIX64 options also include their own IPv4 prefix
>> >> >   lists? If one or more of those later PREFIX64 options
>> >> >   does NOT have its own IPv4 prefix list, what does that
>> >> >   mean? Does it inherit the IPv4 prefix list of the
>> >> >   previous PREFIX64 option? The current text is not clear.
>> >> [Med] Only the first occurrence can carry the IPv4 prefix because
>> other
>> >> occurrences are not used by building IPv4-converted addresses, but
>> only
>> >> to distinguish these addresses if received in referrals. I can add a
>> >> sentence to indicate this explicitly in the text.
>> >
>> >[SRH] Thanks. Please do.
>> [Med] I added this sentence to Section 4.1:
>>
>> " When multiple PREFIX64 options are included in the same PCP message,
>> only the first PREFIX64 option occurrence may include the IPv4 Prefix
>> List field."
>>
>>
>> >
>> >> >8) The example in section 5.1 says that it "depicts a
>> >> >   typical usage of the PREFIX64 option when a DNS64
>> >> >   capability is embedded in the host." Did you mean
>> >> >   "is not embedded"? I don't see how DNS64 is being
>> >> >   used in this example.
>> >>
>> >> [Med] The text is correct. DNS64 is used to form locally an IPv4-
>> >> converted IPv6 address. The example assumes the address of the IPv4
>> >> server is retrieved using A records. DNS exchanges are not mentioned
>> in
>> >> the figure to avoid overloading it.
>> >
>> >[SRH] OK. You may want to explain this a bit more.
>> [Med] I made this change:
>>
>> OLD:
>> "once the IPv6-only client discovers the IPv4 address of the remote
>> IPv4-only server"
>>
>> NEW:
>> " once the IPv6-only client discovers the IPv4 address of the remote
>> IPv4-only server (e.g., using DNS)"
>>
>> and added this sentence:
>>
>> " Note: DNS exchange to retrieve the IPv4 address of
>>       the IPv4-only Server is not shown in the figure. "
>>
>> >
>> >> >9) Is this document still relevant? RFC 7051 says:
>> >> >
>> >> >   Our conclusion is to recommend publishing the Well-Known DNS
>> Name
>> >> >   heuristic discovery-based method as a Standards Track IETF
>> document
>> >> >   for applications and host implementors to implement as-is.
>> >> >
>> >> >   With that, is there still a need for this document?
>> >> [Med] Yes, this is explicitly mentioned in the shepherded text of
>> >> RFC7050. Please refer to
>> >> https://datatracker.ietf.org/doc/rfc7050/history/
>> >>
>> >> "    The document specifies a heuristic that is not perfect and so
>> some
>> >>     points were rough, but the constraint for this document was to
>> >> operate
>> >>     without changes to code (only configuration) in existing
>> networks.
>> >>     Given that constraint, there was strong consensus.  Relaxing the
>> >>     constraint would allow one to do better, and that is the focus
>> of a
>> >>     draft recently submitted to the PCP WG."
>> >
>> >[SRH] OK, fine. You might want to mention that in your draft.
>> >Otherwise, other readers may have the same confusion. They're
>> >not likely to read the shepherd text for RFC 7050!
>> >
>>
>>
>


From charliek@microsoft.com  Fri Jan 24 17:19:01 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2929C1A02D3; Fri, 24 Jan 2014 17:19:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rN5APSCe6ys9; Fri, 24 Jan 2014 17:18:59 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) by ietfa.amsl.com (Postfix) with ESMTP id B9D711A0293; Fri, 24 Jan 2014 17:18:58 -0800 (PST)
Received: from CH1PR03MB599.namprd03.prod.outlook.com (10.255.156.164) by CH1PR03MB599.namprd03.prod.outlook.com (10.255.156.164) with Microsoft SMTP Server (TLS) id 15.0.847.13; Sat, 25 Jan 2014 01:18:50 +0000
Received: from CH1PR03MB599.namprd03.prod.outlook.com ([169.254.7.197]) by CH1PR03MB599.namprd03.prod.outlook.com ([169.254.7.197]) with mapi id 15.00.0847.008; Sat, 25 Jan 2014 01:18:49 +0000
From: Charlie Kaufman 
To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-yourtchenko-cisco-ies.all@tools.ietf.org" 
Thread-Topic: [secdir] secdir review of draft-yourtchenko-cisco-ies-09
Thread-Index: Ac8ZaAlSJfd9ZHMbTi+Pma3WGHP9yA==
Date: Sat, 25 Jan 2014 01:18:49 +0000
Message-ID: <5d469d015350423b83a782a78a5527b5@CH1PR03MB599.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [131.107.192.211]
x-o365ent-eop-header: Message processed by -  O365_ENT: Allow from ranges (Engineering ONLY)
x-forefront-prvs: 01026E1310
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(199002)(189002)(54356001)(56776001)(54316002)(74316001)(76796001)(85306002)(87266001)(2656002)(93136001)(81542001)(47446002)(74876001)(74366001)(47736001)(86362001)(83322001)(94316002)(76176001)(76576001)(2201001)(76786001)(19580395003)(69226001)(31966008)(74706001)(74502001)(93516002)(33646001)(49866001)(53806001)(56816005)(47976001)(76482001)(81816001)(59766001)(83072002)(65816001)(15202345003)(85852003)(80022001)(15975445006)(74662001)(77982001)(77096001)(87936001)(4396001)(80976001)(51856001)(90146001)(46102001)(79102001)(92566001)(81342001)(66066001)(50986001)(81686001)(63696002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CH1PR03MB599; H:CH1PR03MB599.namprd03.prod.outlook.com; CLIP:131.107.192.211; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Subject: [secdir]  secdir review of draft-yourtchenko-cisco-ies-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Jan 2014 01:19:01 -0000

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

This document is a mechanism to bring an IANA registry of log event types u=
p to date to correspond with existing practice based on updates to the prot=
ocol defined in RFC3954. There are no security considerations other than va=
gue concerns over what a buggy existing implementations might do if they se=
e new event types that they don't recognize. This should not be controversi=
al.

Formatting nits:

At the bottom of page 2 and the top of page 3, there are question marks tha=
t seem to have a pre-pended space that looks out of place, but it may have =
been required by some formatting requirement around the bracketed reference=
 that precedes it.

The formatter that translated the XML in appendix A into text for the RFC s=
eems to have strange taste in where to place line breaks. For example, in t=
he middle of page 13, there appears:


 http://www
 .cisco.com
 /en/US/pro
 ducts/hw/s
 witches/ps
 700/products_configuration_example...

	--Charlie

From scott@hyperthought.com  Sat Jan 25 07:18:07 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601941A0253 for ; Sat, 25 Jan 2014 07:18:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lirsH8eyq17a for ; Sat, 25 Jan 2014 07:18:05 -0800 (PST)
Received: from smtp122.iad3a.emailsrvr.com (smtp122.iad3a.emailsrvr.com [173.203.187.122]) by ietfa.amsl.com (Postfix) with ESMTP id EA6B71A00CA for ; Sat, 25 Jan 2014 07:18:04 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp16.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 5C8373C0083; Sat, 25 Jan 2014 10:18:03 -0500 (EST)
X-Virus-Scanned: OK
Received: from app16.wa-webapps.iad3a (relay.iad3a.rsapps.net [172.27.255.110]) by smtp16.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 1FCB83C0071; Sat, 25 Jan 2014 10:18:03 -0500 (EST)
Received: from hyperthought.com (localhost.localdomain [127.0.0.1]) by app16.wa-webapps.iad3a (Postfix) with ESMTP id 106F138005E; Sat, 25 Jan 2014 10:18:03 -0500 (EST)
Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com)  with HTTP; Sat, 25 Jan 2014 07:18:03 -0800 (PST)
Date: Sat, 25 Jan 2014 07:18:03 -0800 (PST)
From: "Scott G. Kelly" 
To: "Alan Johnston" 
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Importance: Normal
X-Priority: 3 (Normal)
X-Type: plain
In-Reply-To: 
References: <1369961279.70598635@apps.rackspace.com>  
Message-ID: <1390663083.06483927@apps.rackspace.com>
X-Mailer: webmail7.0
Cc: draft-ietf-cuss-sip-uui.all@tools.ietf.org, "secdir@ietf.org" 
Subject: Re: [secdir] secdir review of draft-ietf-cuss-sip-uui-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Jan 2014 15:18:07 -0000

Hi Alan,=0A=0AIt appears that the modifications answer the questions I rais=
ed, but I again want to emphasize my lack of experience with SIP. One nit w=
ith the second paragraph of the security considerations section - it says =
=0A=0A   One model treats the SIP layer as untrusted and requires end-to-en=
d=0A   integrity protection and/or encryption.  This model can be achieved=
=0A   by providing these security services at a layer above SIP.  In this=
=0A   case, applications are encouraged to use their own integrity=0A   mec=
hanisms such as encrypting the UUI data before passing it to the=0A   SIP l=
ayer.=0A=0AEncryption is not an integrity mechanism. One way to fix this wo=
uld be to change that last sentence to something like =0A=0A   In this case=
, applications are encouraged to use their own integrity=0A   and/or encryp=
tion mechanisms.=0A=0AThanks,=0A=0AScott=0A=0AOn Thursday, January 23, 2014=
 11:44am, "Alan Johnston"  said:=0A=0A> Scott,=
=0A> =0A> Thanks for your review of the draft.  We made some edits based on=
 your=0A> comments a while back, so I'm pinging you to make sure they addre=
ss your=0A> concerns.=0A> =0A>      http://tools.ietf.org/html/draft-ietf-c=
uss-sip-uui=0A> =0A> Thanks!=0A> - Alan -=0A> =0A> =0A> On Thu, May 30, 201=
3 at 7:47 PM, Scott G. Kelly wrote:=0A> =0A>> I hav=
e reviewed this document as part of the security directorate's=0A>> ongoing=
 effort to review all IETF documents being processed by the IESG.=0A>>  The=
se comments were written primarily for the benefit of the security area=0A>=
> directors.  Document editors and WG chairs should treat these comments ju=
st=0A>> like any other last call comments.=0A>>=0A>> I have no expertise in=
 SIP, and am providing this review as a first-level=0A>> filter for our ove=
r-worked security ADs. So, please take my comments=0A>> accordingly. Also, =
this review is a day late -- I hope it is still useful.=0A>>=0A>> This docu=
ment defines a method for exchanging a blob of information=0A>> between use=
r agents during SIP session establishment (User to User=0A>> Information, o=
r UUI data) by adding a new SIP header. The data is intended=0A>> to be opa=
que to SIP.=0A>>=0A>> There is a related problem statement RFC (6567) that =
briefly describes 3=0A>> different approaches to security, but neither docu=
ment describes likely=0A>> threats. They are implicit in the 3 models descr=
ibed in 6567 (e.g. treat=0A>> the sip layer as "untrusted", treat the sip l=
ayer as "trusted", treat the=0A>> transport domain as "trusted"), but I fou=
nd myself wishing I had more info=0A>> about real-world threats and counter=
measures.=0A>>=0A>> Given that I am not a SIP expert (and don't have time t=
o become one as=0A>> part of this review), I don't know if this is an issue=
 or not, but this is=0A>> an impression I think worth mentioning.=0A>>=0A>>=
 A second question relates to the binding of the UUI to its originator. The=
=0A>> security considerations section suggests that the UUI might carry sen=
sitive=0A>> info requiring privacy or integrity protection, but does not me=
ntion origin=0A>> authentication. There is a hint in the next paragraph (it=
 says=0A>> "History-Info can be used to determine the identity of the inser=
ter"), but=0A>> the relative security of this mechanism is not clear to me.=
 Could an=0A>> attacker forge History-Info? I don't know. What are the cons=
equences of=0A>> such behavior? I don't know. Seems like a well-written sec=
urity=0A>> considerations section would lay these questions to rest.=0A>>=
=0A>> Again, I have almost zero knowledge of SIP, so maybe answers are obvi=
ous=0A>> to someone steeped in SIP lore, and I apologize if this is the cas=
e. But,=0A>> these are my impressions.=0A>>=0A>> --Scott=0A>>=0A>>=0A>>=0A>=
 =0A


From alan.b.johnston@gmail.com  Sat Jan 25 10:09:16 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCA901A000E for ; Sat, 25 Jan 2014 10:09:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRJ5QoSklh1r for ; Sat, 25 Jan 2014 10:09:13 -0800 (PST)
Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2101A0007 for ; Sat, 25 Jan 2014 10:09:13 -0800 (PST)
Received: by mail-pb0-f51.google.com with SMTP id un15so4423739pbc.38 for ; Sat, 25 Jan 2014 10:09:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a3Fz1aV2tI8yAbuL3G74WvvmCnMhvLeOT0XJHVxDPqA=; b=rO3yae1LOLh/34p4b7M/dIP0c7PTlfoydmTxW4oMForaZPHR80H6ERwyrMRMApBDeA wyAz8A9D/uO8WCHR+hyroBCIGRLB4ZL1rtIP9sD7qEgvnHOhqw8rbP6GjkfCzKe7wkqa KPNCmNGci0irpRI7sgx3+ix8z7sflODJ4xxLmzQw9Qttzj+K+c0PSC9810BYJ5W7AHWg oaBXHhlkJrWdjdaUaigYhiIUDabzAUuLWWZYAFZMZuSiisw8F7GVvwuBrnPiobHLKe9P UOzy4bifgsQp+8JOVgg7A0d5m0gJENVI2Puyn0c9w2ooXpfHuJo1UsE/gfSslhdlVfgN K77Q==
MIME-Version: 1.0
X-Received: by 10.68.178.229 with SMTP id db5mr20791955pbc.97.1390673351666; Sat, 25 Jan 2014 10:09:11 -0800 (PST)
Received: by 10.68.168.132 with HTTP; Sat, 25 Jan 2014 10:09:11 -0800 (PST)
In-Reply-To: <1390663083.06483927@apps.rackspace.com>
References: <1369961279.70598635@apps.rackspace.com>  <1390663083.06483927@apps.rackspace.com>
Date: Sat, 25 Jan 2014 12:09:11 -0600
Message-ID: 
From: Alan Johnston 
To: "Scott G. Kelly" 
Content-Type: multipart/alternative; boundary=047d7b6d8d9620056d04f0cf5fa4
Cc: draft-ietf-cuss-sip-uui.all@tools.ietf.org, "secdir@ietf.org" 
Subject: Re: [secdir] secdir review of draft-ietf-cuss-sip-uui-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Jan 2014 18:09:17 -0000

--047d7b6d8d9620056d04f0cf5fa4
Content-Type: text/plain; charset=ISO-8859-1

Scott,

Thanks for reviewing the draft again.  We will fix that mistake.

- Alan -


On Sat, Jan 25, 2014 at 9:18 AM, Scott G. Kelly wrote:

> Hi Alan,
>
> It appears that the modifications answer the questions I raised, but I
> again want to emphasize my lack of experience with SIP. One nit with the
> second paragraph of the security considerations section - it says
>
>    One model treats the SIP layer as untrusted and requires end-to-end
>    integrity protection and/or encryption.  This model can be achieved
>    by providing these security services at a layer above SIP.  In this
>    case, applications are encouraged to use their own integrity
>    mechanisms such as encrypting the UUI data before passing it to the
>    SIP layer.
>
> Encryption is not an integrity mechanism. One way to fix this would be to
> change that last sentence to something like
>
>    In this case, applications are encouraged to use their own integrity
>    and/or encryption mechanisms.
>
> Thanks,
>
> Scott
>
> On Thursday, January 23, 2014 11:44am, "Alan Johnston" <
> alan.b.johnston@gmail.com> said:
>
> > Scott,
> >
> > Thanks for your review of the draft.  We made some edits based on your
> > comments a while back, so I'm pinging you to make sure they address your
> > concerns.
> >
> >      http://tools.ietf.org/html/draft-ietf-cuss-sip-uui
> >
> > Thanks!
> > - Alan -
> >
> >
> > On Thu, May 30, 2013 at 7:47 PM, Scott G. Kelly  >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.
> >>
> >> I have no expertise in SIP, and am providing this review as a
> first-level
> >> filter for our over-worked security ADs. So, please take my comments
> >> accordingly. Also, this review is a day late -- I hope it is still
> useful.
> >>
> >> This document defines a method for exchanging a blob of information
> >> between user agents during SIP session establishment (User to User
> >> Information, or UUI data) by adding a new SIP header. The data is
> intended
> >> to be opaque to SIP.
> >>
> >> There is a related problem statement RFC (6567) that briefly describes 3
> >> different approaches to security, but neither document describes likely
> >> threats. They are implicit in the 3 models described in 6567 (e.g. treat
> >> the sip layer as "untrusted", treat the sip layer as "trusted", treat
> the
> >> transport domain as "trusted"), but I found myself wishing I had more
> info
> >> about real-world threats and countermeasures.
> >>
> >> Given that I am not a SIP expert (and don't have time to become one as
> >> part of this review), I don't know if this is an issue or not, but this
> is
> >> an impression I think worth mentioning.
> >>
> >> A second question relates to the binding of the UUI to its originator.
> The
> >> security considerations section suggests that the UUI might carry
> sensitive
> >> info requiring privacy or integrity protection, but does not mention
> origin
> >> authentication. There is a hint in the next paragraph (it says
> >> "History-Info can be used to determine the identity of the inserter"),
> but
> >> the relative security of this mechanism is not clear to me. Could an
> >> attacker forge History-Info? I don't know. What are the consequences of
> >> such behavior? I don't know. Seems like a well-written security
> >> considerations section would lay these questions to rest.
> >>
> >> Again, I have almost zero knowledge of SIP, so maybe answers are obvious
> >> to someone steeped in SIP lore, and I apologize if this is the case.
> But,
> >> these are my impressions.
> >>
> >> --Scott
> >>
> >>
> >>
> >
>
>
>

--047d7b6d8d9620056d04f0cf5fa4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Scott,

Thanks for reviewing the draft a=
gain. =A0We will fix that mistake.

- Alan -
<=
/div>


On Sat, =
Jan 25, 2014 at 9:18 AM, Scott G. Kelly <scott@hyperthought.com&g=
t; wrote:


Hi Alan,



It appears that the modifications answer the questions I raised, but I agai=
n want to emphasize my lack of experience with SIP. One nit with the second=
 paragraph of the security considerations section - it says



=A0 =A0One model treats the SIP layer as untrusted and requires end-to-end<=
br>
=A0 =A0integrity protection and/or encryption. =A0This model can be achieve=
d

=A0 =A0by providing these security services at a layer above SIP. =A0In thi=
s

=A0 =A0case, applications are encouraged to use their own integrity

=A0 =A0mechanisms such as encrypting the UUI data before passing it to the<=
br>
=A0 =A0SIP layer.



Encryption is not an integrity mechanism. One way to fix this would be to c=
hange that last sentence to something like



=A0 =A0In this case, applications are encouraged to use their own integrity=


=A0 =A0and/or encryption mechanisms.



Thanks,



Scott



On Thursday, January 23, 2014 11:44am, "Alan Johnston" <alan.b.johnston@gmail.com> sa=
id:



> Scott,

>

> Thanks for your review of the draft. =A0We made some edits based on yo=
ur

> comments a while back, so I'm pinging you to make sure they addres=
s your

> concerns.

>

> =A0 =A0 =A0http://tools.ietf.org/html/draft-ietf-cuss-sip-uui

>

> Thanks!

> - Alan -

>

>

> On Thu, May 30, 2013 at 7:47 PM, Scott G. Kelly <scott@hyperthought.com>wrote:

>

>> I have reviewed this document as part of the security directorate&=
#39;s

>> ongoing effort to review all IETF documents being processed by the=
 IESG.

>> =A0These comments were written primarily for the benefit of the se=
curity area

>> directors. =A0Document editors and WG chairs should treat these co=
mments just

>> like any other last call comments.

>>

>> I have no expertise in SIP, and am providing this review as a firs=
t-level

>> filter for our over-worked security ADs. So, please take my commen=
ts

>> accordingly. Also, this review is a day late -- I hope it is still=
 useful.

>>

>> This document defines a method for exchanging a blob of informatio=
n

>> between user agents during SIP session establishment (User to User=


>> Information, or UUI data) by adding a new SIP header. The data is =
intended

>> to be opaque to SIP.

>>

>> There is a related problem statement RFC (6567) that briefly descr=
ibes 3

>> different approaches to security, but neither document describes l=
ikely

>> threats. They are implicit in the 3 models described in 6567 (e.g.=
 treat

>> the sip layer as "untrusted", treat the sip layer as &qu=
ot;trusted", treat the

>> transport domain as "trusted"), but I found myself wishi=
ng I had more info

>> about real-world threats and countermeasures.

>>

>> Given that I am not a SIP expert (and don't have time to becom=
e one as

>> part of this review), I don't know if this is an issue or not,=
 but this is

>> an impression I think worth mentioning.

>>

>> A second question relates to the binding of the UUI to its origina=
tor. The

>> security considerations section suggests that the UUI might carry =
sensitive

>> info requiring privacy or integrity protection, but does not menti=
on origin

>> authentication. There is a hint in the next paragraph (it says

>> "History-Info can be used to determine the identity of the in=
serter"), but

>> the relative security of this mechanism is not clear to me. Could =
an

>> attacker forge History-Info? I don't know. What are the conseq=
uences of

>> such behavior? I don't know. Seems like a well-written securit=
y

>> considerations section would lay these questions to rest.

>>

>> Again, I have almost zero knowledge of SIP, so maybe answers are o=
bvious

>> to someone steeped in SIP lore, and I apologize if this is the cas=
e. But,

>> these are my impressions.

>>

>> --Scott

>>

>>

>>

>









--047d7b6d8d9620056d04f0cf5fa4--

From new-work-bounces@ietf.org  Fri Jan 24 09:53:38 2014
Return-Path: 
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 588071A00CE; Fri, 24 Jan 2014 09:53:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1390586018; bh=ioLhgUbflx3p7VO0QkUzyrMxMoxzyc9xJ4ku5I3KTJQ=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=G4PseJN7exB7zYWemVIdNqAwBBQi1TqY72e4mJLVaWjt+bmU269FCJDO/7Z0F95+u Tw7fkNcoTkXvn/trj0YJWsfBVsJgT9MPU+NyzIwS8zj69ZqYazApP8Wkd9dBBvjUZ0 P/3pkQFdvlDRbUIhK43dAqoTXTzeY6EDKBvQihG8=
X-Original-To: new-work@ietfa.amsl.com
Delivered-To: new-work@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7381A00BB; Fri, 24 Jan 2014 09:53:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVjyocoGvwDz; Fri, 24 Jan 2014 09:53:35 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EB05C1A00B7; Fri, 24 Jan 2014 09:53:34 -0800 (PST)
MIME-Version: 1.0
From: The IESG 
To: new-work@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.90.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140124175334.27816.88603.idtracker@ietfa.amsl.com>
Date: Fri, 24 Jan 2014 09:53:34 -0800
X-BeenThere: new-work@ietf.org
X-Mailman-Version: 2.1.15
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: new-work-bounces@ietf.org
Sender: "new-work" 
X-Mailman-Approved-At: Sat, 25 Jan 2014 12:03:08 -0800
Subject: [secdir] [new-work] WG Review: Public Notary Transparency (trans)
X-BeenThere: secdir@ietf.org
Reply-To: iesg@ietf.org
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jan 2014 17:53:38 -0000

A new IETF working group has been proposed in the Security Area. The IESG
has not made any determination yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send
your comments to the IESG mailing list (iesg at ietf.org) by 2014-02-03.

Public Notary Transparency  (trans)
------------------------------------------------
Current Status: Proposed WG

Assigned Area Director:
  Stephen Farrell 

Mailing list
  Address: therightkey@ietf.org
  To Subscribe: https://www.ietf.org/mailman/listinfo/therightkey
  Archive: http://www.ietf.org/mail-archive/web/therightkey/

Charter:

Mitigating web site certificate mis-issuance is the initial problem of
interest for this working group. Certificate Transparency (CT,
RFC6962) allows such mis-issuance to be detected in interesting and
useful cases, for example by an auditor acting for the web site, or
one acting to check general CA behaviour. The working group will
produce a standards-track version of the experimental RFC 6962
for HTTP over TLS, reflecting implementation and deployment 
experience since that specification was completed.

Many Internet protocols for example, SMTPS, IPsec, DNSSEC, 
OpenPGP and HTTPS, require  a mapping between some kind of 
identifier and some kind of public key. These protocols rely
on either ad-hoc mappings, (as in a web of trust), or on authorities
(such as CAs) that attest to the mappings. History shows that neither
of these mechanisms is entirely satisfactory.  Ad-hoc mappings are
difficult to discover and maintain, and authorities make mistakes or
are subverted.

Cryptographically verifiable logs can help to ameliorate these
problems by making it possible to discover errors quickly, so that 
other mechanisms can be applied to rectify them. A cryptographically 
verifiable log is an append-only log of hashes of more-or-less anything 
that  is structured in such a way as to provide efficiently-accessible,
cryptographically-supported evidence of correct log behaviour. For
example, RFC 6962 says: "The append-only property of each log is
technically achieved using Merkle Trees, which can be used to show
that any particular version of the log is a superset of any particular
previous version. Likewise, Merkle Trees avoid the need to blindly
trust logs: if a log attempts to show different things to different
people, this can be efficiently detected by comparing tree roots and
consistency proofs. Similarly, other misbehaviors of any log (e.g.,
issuing signed timestamps for certificates they then don't log) can be
efficiently detected and proved to the world at large."

These logs can potentially also assist with other interesting
problems, such as how to assure end users that software they are
running is, indeed, the software they intend to run.

While the privacy issues related to use of RFC6962 for public
web sites are minimal, the working group will consider privacy
as it might impact on uses of CT e.g. within enterprises or
for other uses of logs.

Work items:

- Publish an update to RFC 6962 as a standards-track mechanism to
apply verifiable logs to HTTP over TLS.  As DANE (RFC6698) provides an
alternative keying infrastructure to that used in the current web PKI,
the working group should consider appropriate client behavior in the
presence of both DANE-based keying and current web PKI when
standardising CT.

- Discuss mechanisms and techniques that allow cryptographically
verifiable logs to be deployed to improve the security of protocols
other than HTTP over TLS, for example SMTP/TLS or software 
distribution. Where such mechanisms appear sufficiently useful, 
the WG will re-charter to add relevant new work items.  Should
no such items be chartered the WG will close when documents 
associated with the first work item are complete.



Milestones:

TBD
_______________________________________________
new-work mailing list
new-work@ietf.org
https://www.ietf.org/mailman/listinfo/new-work

From zhangdacheng@huawei.com  Sat Jan 25 21:53:41 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3661A00FC; Sat, 25 Jan 2014 21:53:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.736
X-Spam-Level: 
X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qICkwoVd7eFh; Sat, 25 Jan 2014 21:53:39 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCC71A00FB; Sat, 25 Jan 2014 21:53:38 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAK68708; Sun, 26 Jan 2014 05:53:36 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 26 Jan 2014 05:53:11 +0000
Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 26 Jan 2014 05:53:35 +0000
Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.75]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Sun, 26 Jan 2014 13:53:28 +0800
From: "Zhangdacheng (Dacheng)" 
To: Tom Taylor , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-ancp-mc-extensions.all@tools.ietf.org" 
Thread-Topic: [spam] [secdir] secdir review of draft-ietf-ancp-mc-extensions-14
Thread-Index: Ac8XPd+LcI+ULRdMSv6oBbGFFsLvBwBGPR0AAHy3lIA=
Date: Sun, 26 Jan 2014 05:53:27 +0000
Message-ID: 
References:  <52E1B176.9070209@gmail.com>
In-Reply-To: <52E1B176.9070209@gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.139]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [secdir] [spam] secdir review of draft-ietf-ancp-mc-extensions-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 26 Jan 2014 05:53:41 -0000

> >
> > 4)
> >
> > Section 6.1.3 lists the protocol elements that MUST be implemented to
> > support the conditional access with white and black lists multicast
> > capability. I found White-List-CAC TLV is included in the list.
> > However, the White-List-CAC TLV is used to indicate that the NAS
> > wishes the AN to do admission control for white-listed flows, and this
> > use case is discussed in Section 3.4.2.3 of RFC 5851 "Multicast
> > Admission Control and White Lists". So, I doubt whether this TLV needs
> > to be supported is this case.
> >
> [PTT] Doesn't Section 3.4.2.3 describe a case where the AN does both
> admission control and white listing, and sets the conditions for doing th=
at?
>=20
>   "IPTV is an example of a service that will not be offered as best
>    effort, but requires some level of guaranteed quality of service.
>    This requires the use of Multicast Admission Control.  Hence, if the
>    Access Node wants to autonomously perform the admission process, it
>    must be aware of the bandwidth characteristics of multicast flows.
>    Otherwise, the Access Node would have to query the NAS for Multicast
>    Admission Control (per the grey list behavior); this would defeat the
>    purpose of using a white and black list."
>=20

[Dacheng Zhang:]=20
Maybe I didn't explain my point view clearly last time. Sorry for that.

If the title of section 6.13 is "Protocol Requirements For Admission Contro=
l With White and Black Lists ", then everything is perfect because this TLV=
 is used to indicate that the NAS wishes the AN to do admission control for=
 white-listed flows. The use case you provided above is also one for admiss=
ion control. But at the moment, the tile of this section is " Protocol Requ=
irements For Conditional Access With White and Black Lists ". That is why I=
 raised a question here for your consideration. ^_^

Cheers

Dacheng

From tom.taylor.stds@gmail.com  Sun Jan 26 02:10:22 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7A71A011F; Sun, 26 Jan 2014 02:10:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NePiGCbrWeqU; Sun, 26 Jan 2014 02:10:21 -0800 (PST)
Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id DE5FA1A0119; Sun, 26 Jan 2014 02:10:20 -0800 (PST)
Received: by mail-ie0-f173.google.com with SMTP id e14so4679446iej.4 for ; Sun, 26 Jan 2014 02:10:19 -0800 (PST)
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:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=AO7G0cS+U2+IsXg3iAHhGLJWDjMvOZPCPHdNSbovCBc=; b=EOoUmMhrlPM4RbzBTakLtKb3Ft1X71r7Pq0cPrISfTTtdnzOTLnSY9k2pSnWkDlg9W qgjH99d/gcfbey/AVl/oVoRnpxJScax+yF/vG26UWzioEdSexlchFw/ZNEOFYtuMITHa mD4OGBgA6mOxwY/FB67rAlCp4O2J8/1fT5hSlAPyjGTVs09DXRAoyUQBqHAq/pEUZQ4V VfrbqpOcf0Kq9fVXGOWVRMVHUzhcbZrBWzOEALUghLFd47syZrttlTVwSv2JmzHB54Di XKEerA7QM9D4U3dSEm9HcjDhouNqRSxkBZpsVpC+HZIJDBKcQmFm0YyO8XT+TTF8wGia XPYA==
X-Received: by 10.42.228.65 with SMTP id jd1mr8589icb.62.1390731019031; Sun, 26 Jan 2014 02:10:19 -0800 (PST)
Received: from [192.168.1.69] ([64.56.225.169]) by mx.google.com with ESMTPSA id w4sm31478820igb.5.2014.01.26.02.10.17 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 26 Jan 2014 02:10:18 -0800 (PST)
Message-ID: <52E4DF07.6070303@gmail.com>
Date: Sun, 26 Jan 2014 05:10:15 -0500
From: Tom Taylor 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "Zhangdacheng (Dacheng)" ,  "iesg@ietf.org" , "secdir@ietf.org" ,  "draft-ietf-ancp-mc-extensions.all@tools.ietf.org" 
References:  <52E1B176.9070209@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [secdir] [spam] secdir review of draft-ietf-ancp-mc-extensions-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 26 Jan 2014 10:10:22 -0000

OK. let's review this point when I clean up all the terminology. I think 
you may be right and this belongs in one of the combined sections.

On 26/01/2014 12:53 AM, Zhangdacheng (Dacheng) wrote:
>>>
>>> 4)
>>>
>>> Section 6.1.3 lists the protocol elements that MUST be implemented to
>>> support the conditional access with white and black lists multicast
>>> capability. I found White-List-CAC TLV is included in the list.
>>> However, the White-List-CAC TLV is used to indicate that the NAS
>>> wishes the AN to do admission control for white-listed flows, and this
>>> use case is discussed in Section 3.4.2.3 of RFC 5851 "Multicast
>>> Admission Control and White Lists". So, I doubt whether this TLV needs
>>> to be supported is this case.
>>>
>> [PTT] Doesn't Section 3.4.2.3 describe a case where the AN does both
>> admission control and white listing, and sets the conditions for doing that?
>>
>>    "IPTV is an example of a service that will not be offered as best
>>     effort, but requires some level of guaranteed quality of service.
>>     This requires the use of Multicast Admission Control.  Hence, if the
>>     Access Node wants to autonomously perform the admission process, it
>>     must be aware of the bandwidth characteristics of multicast flows.
>>     Otherwise, the Access Node would have to query the NAS for Multicast
>>     Admission Control (per the grey list behavior); this would defeat the
>>     purpose of using a white and black list."
>>
>
> [Dacheng Zhang:]
> Maybe I didn't explain my point view clearly last time. Sorry for that.
>
> If the title of section 6.13 is "Protocol Requirements For Admission Control With White and Black Lists ", then everything is perfect because this TLV is used to indicate that the NAS wishes the AN to do admission control for white-listed flows. The use case you provided above is also one for admission control. But at the moment, the tile of this section is " Protocol Requirements For Conditional Access With White and Black Lists ". That is why I raised a question here for your consideration. ^_^
>
> Cheers
>
> Dacheng
>
>

From hartmans@mit.edu  Mon Jan 27 05:59:00 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818AD1A0231; Mon, 27 Jan 2014 05:59:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NN55ZJebvHcH; Mon, 27 Jan 2014 05:58:59 -0800 (PST)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7981A0200; Mon, 27 Jan 2014 05:58:59 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 52F0320656; Mon, 27 Jan 2014 08:55:56 -0500 (EST)
Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0mV3xWA8exb; Mon, 27 Jan 2014 08:55:55 -0500 (EST)
Received: from carter-zimmerman.suchdamage.org (c-50-177-27-27.hsd1.ma.comcast.net [50.177.27.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 27 Jan 2014 08:55:55 -0500 (EST)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E21F68131A; Mon, 27 Jan 2014 08:58:55 -0500 (EST)
From: Sam Hartman 
To: iesg@ietf.org,secdir@ietf.org
Date: Mon, 27 Jan 2014 08:58:55 -0500
Message-ID: 
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [secdir] secdir review of draft-ietf-manet-olsrv2-rmpr-optimization-00
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Jan 2014 13:59:00 -0000

This draft describes an optimization to OLSRV2's MPR distribution
algorithm designed to remove MPRs that are redundant from what is
distributed.


According to the spec, a receiver will ignore the redundant information
if included.  As such, I believe the claim in the security
considerations section that this cannot have a security impact is
accurate.

From d3e3e3@gmail.com  Tue Jan 28 09:25:45 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE621A0158; Tue, 28 Jan 2014 09:25:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level: 
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xZBU3pdVHCy; Tue, 28 Jan 2014 09:25:43 -0800 (PST)
Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE021A0146; Tue, 28 Jan 2014 09:25:43 -0800 (PST)
Received: by mail-oa0-f41.google.com with SMTP id j17so752635oag.14 for ; Tue, 28 Jan 2014 09:25:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=YYYtz7v6Vx9wYCBVslDy+TaR2rxgSednhhQyilIu7qc=; b=ETYBwZoF5M7lyost4NOJRtCLC5ikuMBqGn5nDR3aCBn3wAl1tRcFA9dehsTqVj0bx8 LKhMNELFTsxpdUO5D58IEQ46mgUd5HFhcGrsVveQ1c9K8k3FigkJcelC4AZdWPcmCDKP L0UcCm9luflyg/4u6W3cVygDGALsrbcZbVNN0QkQLVulOFtGhGwU54Xzj5JP2Xy0w4Ae pMGiJ4+vBjTVZ4L2iH4flTpquC6u0OJ68q8S3mUxVxzm8wVbFv7g6I0SBYO9JN3lXmxu g7Qiiqu2b/kpiAIquZSEmraEacQi2a32KY2XVxTp2iuDECUMFBm3e3S7fA9KB5M1JJ9U wLGw==
X-Received: by 10.60.97.193 with SMTP id ec1mr2030127oeb.20.1390929940934; Tue, 28 Jan 2014 09:25:40 -0800 (PST)
MIME-Version: 1.0
Received: by 10.76.33.102 with HTTP; Tue, 28 Jan 2014 09:25:20 -0800 (PST)
From: Donald Eastlake 
Date: Tue, 28 Jan 2014 12:25:20 -0500
Message-ID: 
To: "iesg@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: draft-ietf-netmod-system-mgmt.all@tools.ietf.org, "secdir@ietf.org" 
Subject: [secdir] SECDIR review of draft-ietf-netmod-system-mgmt-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Jan 2014 17:25:45 -0000

Hi,

Sorry this review is late.

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.

I believe this draft is ready with issues.

This draft specifies a YANG data model for configuration and
identification of NETCONF server device information. You might think
there would not be much in the way of Security Considerations for a
"data model" but the model includes User Authentication,  sensitive
writable data objects, and the like.

For user password authentication, there are provisions for storing a
plain text of the password or a salted hash. Hash functions available
are MD5, SHA-256, and SHA-512.

Security Considerations:

The Security Considerations section seems pretty thorough in covering
NETCONF security features such as SSH transport and access controls.
However, I believe the Security Considerations should recommend not
storing passwords as plaintext but rather as a salted hash. While the
Security Considerations section refers to RFC 6151 for MD5 Security
Considerations and having that reference is good, I believe this
document should also recommend that MD5 not be used as the password
salted hash function.

For the list of sensitive readable data and sensitive remote procedure
call operations, the draft is careful to say "It is thus important to
control access to these operations." However, while it is pretty
obvious, these words or equivalent seem to be missing in reference to
the sensitive writable data.

Trivial:

Section 2.3, first line: "need" -> "needs"
Section 2.3, 2nd paragraph, second line: "need" -> "needs"
I believe RPC should be expanded to "remote procedure call" at its one
use in the text of the draft, unless I've expanded the acronym wrong,
which would be proof that whatever it stands for it should be spelled
out.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com

From paul.hoffman@vpnc.org  Tue Jan 28 15:47:58 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCB71A036C for ; Tue, 28 Jan 2014 15:47:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level: 
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljvgwXUJJsJd for ; Tue, 28 Jan 2014 15:47:57 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 895931A02EC for ; Tue, 28 Jan 2014 15:47:57 -0800 (PST)
Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id s0SNReIx015901 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 28 Jan 2014 16:27:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90]
From: Paul Hoffman 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <41A9BF82-9F09-4733-8721-75529D51A8C4@vpnc.org>
Date: Tue, 28 Jan 2014 15:47:51 -0800
To: secdir 
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
X-Mailer: Apple Mail (2.1827)
Subject: [secdir] Secdir review of draft-ietf-radext-ieee802ext
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Jan 2014 23:47:58 -0000

This document defines some additional RADIUS attributes for IEEE 802 =
authenticators acting as AAA clients, and also clarifies some EAP =
usages. Thus, it describes authentication and authorization requests =
that are supposedly local to a network. The security considerations are =
pretty massive, but they are covered in other RFCs reasonably well, and =
those are listed in the Security Considerations. If you buy into the =
normal use of RADIUS in IEEE 802 networks, this document doesn't present =
anything at all challenging.

--Paul Hoffman=

From tobias.gondrom@gondrom.org  Wed Jan 29 09:29:22 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB981A02F2; Wed, 29 Jan 2014 09:29:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.535
X-Spam-Level: 
X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQXcI_inU-Ru; Wed, 29 Jan 2014 09:29:20 -0800 (PST)
Received: from www.gondrom.org (www.gondrom.org [91.250.114.153]) by ietfa.amsl.com (Postfix) with ESMTP id 57FAD1A0216; Wed, 29 Jan 2014 09:29:20 -0800 (PST)
X-No-Relay: not in my network
DomainKey-Signature: a=rsa-sha1;  q=dns; c=nofws; s=default; d=gondrom.org; b=P9h6WLvAGT4Szbd0Is2J/WQmwOqK6Nb34HYEUZIT5wG9KSVTQjbXFdzpPkrUE6Id1HQ5snPVeurRDSSY1dmE2rrHyqgbNPckCqbX0kIKglmWBSO3ftsOTcxzJm24+w7kj74GiWkggSw0+I8AUD+LBp5NXXMyi7dFJyfoicKD8f0=; h=X-No-Relay:X-No-Relay:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-Priority:References:In-Reply-To:X-Enigmail-Version:Content-Type;
X-No-Relay: not in my network
X-No-Relay: not in my network
Received: from [192.168.0.4] (2e40e864.skybroadband.com [46.64.232.100]) by www.gondrom.org (Postfix) with ESMTPSA id E23B71539000D; Wed, 29 Jan 2014 18:29:15 +0100 (CET)
Message-ID: <52E93A6B.9020400@gondrom.org>
Date: Wed, 29 Jan 2014 17:29:15 +0000
From: Tobias Gondrom 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: draft-ietf-dane-registry-acronyms.all@tools.ietf.org
X-Priority: 4 (Low)
References: <52101187.2060409@gondrom.org> <5293E22B.90705@gondrom.org>
In-Reply-To: <5293E22B.90705@gondrom.org>
X-Enigmail-Version: 1.6
Content-Type: multipart/alternative; boundary="------------020800000602060106040409"
Cc: iesg@ietf.org, secdir@ietf.org
Subject: [secdir] secdir review of draft-ietf-dane-registry-acronyms-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Jan 2014 17:29:23 -0000

This is a multi-part message in MIME format.
--------------020800000602060106040409
Content-Type: text/plain; charset=UTF-8
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.


The document is basically just about acronyms to simplify DANE
conversations
The document appears ready for publication.

The security consideration section is sufficient and there are no
security issues with this document.

There are only two small nits / spelling issues:
in section "Abstract":
- s/Experience has show that/Experience has shown that
- speaking of acronyms, the first mention of TLSA should spell it out.

Thank you and best regards.

Tobias

--------------020800000602060106040409
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


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

      

      

      The document is basically just about acronyms to simplify DANE
      conversations 

    The
          document appears ready for publication. 

        

      The security consideration
            section is sufficient and there are no security issues with
            this document. 

          

        There are only two small nits / spelling issues: 

        in section "Abstract":

        - s/Experience has show that/Experience has shown that

        - speaking of acronyms, the first mention of TLSA should spell
        it out. 

        

        Thank you and best regards. 

        

        Tobias

      
  


--------------020800000602060106040409--

From kwiereng@cisco.com  Thu Jan 30 01:19:58 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1702B1A0417; Thu, 30 Jan 2014 01:19:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.036
X-Spam-Level: 
X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wl99s1LPIYDf; Thu, 30 Jan 2014 01:19:56 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7003F1A03E9; Thu, 30 Jan 2014 01:19:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1733; q=dns/txt; s=iport; t=1391073595; x=1392283195; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=AOZO14KwyJF4vFT7YW55YkQnd81tpHJJxbIZlgqK+1w=; b=Dv937Mfln4lASrjnZIpTiMRUD+mz7zuM0hHsDDNCwgezUF5rix8YNMOX mfsg+tOTLCQtvAcHUJpEAOCRG5+k/G+hgOTDZumasMQkxEKWpiSa+smiY 8hz9rXfF6tQLdAY+OkbjHNyuTfnwrOjeJlqchdenXGqGv1trW/OD9AL1Z 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhgFAJwY6lKtJXHB/2dsb2JhbABZgww4V7xPT4EFFnSCLDo/EgE+QicEDg6HfA3LSheOJwcBAU8CgymBFASYKJIfgy2BaAkXIg
X-IronPort-AV: E=Sophos;i="4.95,748,1384300800"; d="scan'208";a="297696675"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 30 Jan 2014 09:19:54 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s0U9Jr9S003931 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Jan 2014 09:19:53 GMT
Received: from xmb-aln-x12.cisco.com ([169.254.7.104]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Thu, 30 Jan 2014 03:19:52 -0600
From: "Klaas Wierenga (kwiereng)" 
To: "draft-ietf-p2psip-rpr.all@tools.ietf.org" 
Thread-Topic: Secdir review of draft-ietf-p2psip-rpr-11
Thread-Index: AQHPHZxuadjFPudg1EiEZvef0HUYVg==
Date: Thu, 30 Jan 2014 09:19:52 +0000
Message-ID: <521F1B37-7D82-485C-AA8F-624695BC5797@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.103.205]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2C2742D2AAC06E419AB37639AAEB848D@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "iesg@ietf.org" , "secdir@ietf.org" 
Subject: [secdir] Secdir review of draft-ietf-p2psip-rpr-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Jan 2014 09:19:58 -0000

Hi,=20

I reviewed earlier version 10 (http://www.ietf.org/mail-archive/web/secdir/=
current/msg04256.html), I didn't get any response and the security consider=
ations don't seem to address what I wrote at that time, so I'll repeat:

--
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 co=
mments were written primarily for the benefit of the security area director=
s.  Document editors and WG chairs should treat these comments just like an=
y other last call comments.

This document defines an optional extension to RELOAD to support Relay Peer=
 Routing (RPR) mode (as opposed to Symmetric Recursive Routing (SRR). The d=
ocument is straightforward and clear, but with respect to the security cons=
iderations a few comments:

- I am surprised that there is no discussion on the relay peer being the si=
ngle (or few) point of failure,  and thus becoming an interesting target fo=
r DoS attacks: the relay peer acts as a hub for all traffic coming from the=
 peers that have it as their relay. Especially when there is a limited numb=
er of relays it becomes attractive to bring the relay down.=20

- The other thing I wonder about is why there is the need to trust the rela=
y, why is this different from the DRR case (apart from the observation in m=
y previous comment)? It seems that the system would work just fine without =
the explicit trust in the relay peer, in fact, the way I understand it ever=
y peer in the overlay can in principle act as a relay peer (I imagine a sce=
nario where the relay peer acts as the "established connection").

Cheers,

Klaas Wierenga
--

 =

From kivinen@iki.fi  Thu Jan 30 05:38:29 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 737DF1A0233 for ; Thu, 30 Jan 2014 05:38:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0I_KjOY7UaTh for ; Thu, 30 Jan 2014 05:38:27 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id F10561A0230 for ; Thu, 30 Jan 2014 05:38:26 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s0UDcLPn008256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 30 Jan 2014 15:38:21 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s0UDcLFx003400; Thu, 30 Jan 2014 15:38:21 +0200 (EET)
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: <21226.21965.39110.551467@fireball.kivinen.iki.fi>
Date: Thu, 30 Jan 2014 15:38:21 +0200
From: Tero Kivinen 
To: secdir@ietf.org
X-Edit-Time: 0 min
X-Total-Time: 0 min
Subject: [secdir] Assignments
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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 Jan 2014 13:38:29 -0000

Review instructions and related resources are at:
http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

Julien Laganier is next in the rotation.

For telechat 2014-02-06

Reviewer                 LC end     Draft
Dan Harkins            T 2014-02-04 draft-ietf-alto-protocol-25
Julien Laganier        T 2013-12-11 draft-ietf-stox-core-09
Ben Laurie             T 2013-12-11 draft-ietf-stox-presence-07
Brian Weis             TR2013-09-30 draft-ietf-p2psip-drr-11


For telechat 2014-02-20

Dorothy Gellert        T 2014-02-11 draft-housley-pkix-test-oids-00

Last calls and special requests:

Dave Cridland          E 2013-11-21 draft-dunbar-armd-arp-nd-scaling-practices-07
Phillip Hallam-Baker     2014-01-27 draft-ietf-qresync-rfc5162bis-09
Steve Hanna              2014-01-28 draft-ietf-v6ops-nat64-experience-09
David Harrington         2014-02-04 draft-ietf-avtext-rtp-duplication-04
Jeffrey Hutzelman      E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-05
Jeffrey Hutzelman        2014-02-04 draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01
Leif Johansson           2014-02-04 draft-ietf-xrblock-rtcp-xr-synchronization-07
Scott Kelly              2014-02-11 draft-ietf-pwe3-iccp-13
Stephen Kent             2014-02-12 draft-ietf-mpls-forwarding-06
Tero Kivinen             2014-02-07 draft-ietf-manet-nhdp-olsrv2-tlv-extension-01
Warren Kumari            2014-02-12 draft-ietf-l3vpn-mldp-vrf-in-band-signaling-03
Julien Laganier        E 2013-11-21 draft-ietf-websec-key-pinning-09
Sandy Murphy             2013-12-17 draft-ietf-netmod-iana-timezones-03
Ondrej Sury              2013-12-27 draft-ietf-tls-applayerprotoneg-04
Brian Weis             E 2014-01-16 draft-ietf-radext-dynamic-discovery-09
Glen Zorn                2013-08-30 draft-kaplan-insipid-session-id-03
-- 
kivinen@iki.fi

From mbj@tail-f.com  Fri Jan 31 12:16:49 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6971A0423; Fri, 31 Jan 2014 12:16:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuyA7tLFOZ5z; Fri, 31 Jan 2014 12:16:46 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 7A07E1A03F5; Fri, 31 Jan 2014 12:16:46 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 5984E37C197; Fri, 31 Jan 2014 21:16:41 +0100 (CET)
Date: Fri, 31 Jan 2014 21:16:40 +0100 (CET)
Message-Id: <20140131.211640.309066023.mbj@tail-f.com>
To: d3e3e3@gmail.com
From: Martin Bjorklund 
In-Reply-To: 
References: 
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-netmod-system-mgmt.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] SECDIR review of draft-ietf-netmod-system-mgmt-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Jan 2014 20:16:49 -0000

Hi,

Thank you for your review!

Donald Eastlake  wrote:
> Hi,
> 
> Sorry this review is late.
> 
> 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.
> 
> I believe this draft is ready with issues.
> 
> This draft specifies a YANG data model for configuration and
> identification of NETCONF server device information. You might think
> there would not be much in the way of Security Considerations for a
> "data model" but the model includes User Authentication,  sensitive
> writable data objects, and the like.
> 
> For user password authentication, there are provisions for storing a
> plain text of the password or a salted hash. Hash functions available
> are MD5, SHA-256, and SHA-512.
> 
> Security Considerations:
> 
> The Security Considerations section seems pretty thorough in covering
> NETCONF security features such as SSH transport and access controls.
> However, I believe the Security Considerations should recommend not
> storing passwords as plaintext but rather as a salted hash.

Actually, the clear text password is never stored:

       The '$0$' prefix signals that the value is clear text.  When
       such a value is received by the server, a hash value is
       calculated, and the string '$$$' or
       $$$$ is prepended to the result.  This
       value is stored in the configuration data store.

The client can send a clear text password (over SSH or TLS) but the
server will never store it in clear text.

> While the
> Security Considerations section refers to RFC 6151 for MD5 Security
> Considerations and having that reference is good, I believe this
> document should also recommend that MD5 not be used as the password
> salted hash function.

This was discussed in the WG, and we felt that whatever we would say
would be better stated in RFC 6151.  Maybe we can be more explicit
about the recommendation:

OLD:

This YANG model defines a type "crypt-hash" that can be used to store
MD5 hashes.  ^RFC6151^ discusses security considerations for MD5.


NEW:

This YANG model defines a type "crypt-hash" that can be used to store
MD5 hashes.  ^RFC6151^ discusses security considerations for MD5.  The
usage of MD5 is NOT RECOMMENDED.


> For the list of sensitive readable data and sensitive remote procedure
> call operations, the draft is careful to say "It is thus important to
> control access to these operations." However, while it is pretty
> obvious, these words or equivalent seem to be missing in reference to
> the sensitive writable data.

The Security Consideration section is modeled after a template found
at:

http://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines

I don't mind an update, but I believe we should update the template as
well in this case.

The current text says that "write operations [...] without protection
can have a negative effect [...]".

The other paragraphs use the phrase:

"It is thus important to control [...] access [to these data nodes]".

I think the current text says the same thing, but I guess it can be
made more explicit:

OLD:

There are a number of data nodes defined in this YANG module which are
writable/creatable/deletable (i.e. config true, which is the
default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g. edit-config) to
these data nodes without proper protection can have a negative effect
on network operations. These are the subtrees and data nodes and their
sensitivity/vulnerability:


NEW:

There are a number of data nodes defined in this YANG module which are
writable/creatable/deletable (i.e. config true, which is the
default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations to these data nodes can
have a negative effect on network operations.  It is thus important to
control write access (e.g., via edit-config) to these data nodes.
These are the subtrees and data nodes and their
sensitivity/vulnerability:


> Trivial:
> 
> Section 2.3, first line: "need" -> "needs"
> Section 2.3, 2nd paragraph, second line: "need" -> "needs"
> I believe RPC should be expanded to "remote procedure call" at its one
> use in the text of the draft, unless I've expanded the acronym wrong,
> which would be proof that whatever it stands for it should be spelled
> out.

All fixed.


/martin

From bew@cisco.com  Fri Jan 31 14:20:07 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3C01A0574; Fri, 31 Jan 2014 14:20:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.036
X-Spam-Level: 
X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7OMlrVV_9GO; Fri, 31 Jan 2014 14:20:05 -0800 (PST)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 68D3E1A04E8; Fri, 31 Jan 2014 14:20:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1796; q=dns/txt; s=iport; t=1391206802; x=1392416402; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=qK6eYXw1WIGKFbEUApWxK3TPdtlwG6+N4FJktpa5Cs0=; b=fRqk7WkDxbhkmceEnwFjlzHWL4X0nfVE04+o/tvhU83iXmiKuf/WuvGE jMmTceVWmEdb5cRRuyaPGqeYx+f8DJ0X1sXKD/i+cykX3gDDR16jaD2Yq stUp6qFLScCDMc6JzzRoewnubjtzMx/mh5UuwdTkm0C9mjBDYnhd56d/z 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjMGAOog7FKrRDoJ/2dsb2JhbABZgwypDpVagQ8WdIJmP4E+AYgWzS4XjwKDK4EUBIlJjmGGSItZg04b
X-IronPort-AV: E=Sophos;i="4.95,760,1384300800"; d="scan'208";a="104502416"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 31 Jan 2014 22:19:59 +0000
Received: from [10.154.161.136] ([10.154.161.136]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0VMJxLY016883 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 31 Jan 2014 22:19:59 GMT
From: Brian Weis 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Fri, 31 Jan 2014 14:19:59 -0800
Message-Id: 
To: "secdir@ietf.org" , The IESG 
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
X-Mailer: Apple Mail (2.1510)
Cc: "draft-ietf-p2psip-drr.all@tools.ietf.org" 
Subject: [secdir] Secdir review of draft-ietf-p2psip-drr-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Jan 2014 22:20:07 -0000

I have reviewed this document as part of the security directorate's =
ongoing effort to review all IETF documents being processed by the IESG. =
These 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 routing mechanism for Peer-to-Peer Session =
Initiation Protocol (P2PSIP). The routing mechanism in the base P2PSIP =
protocol specifies an initiator sending a request message hop by hop =
through a DHT to a responder, with the responder returning a reply using =
the reverse path. The alternative routing method defined in this I-D =
describes a shortcut for the response message. The response is returned =
directly to the initiator using an IP address provided by the initiator. =
This shortcut method is described as an optimization that is useful in =
private networks where a self-reported IP address is likely to be =
reliable (i.e., no NAT).

I previously reviewed draft-ietf-p2psip-drr-10 and had some =
clarification questions and minor comments. This version adequately =
addressed those comments, and I have no additional concerns.

The only thing that I wish could be clarified in the draft is that the =
"DRR(DTLS)" values for "No. of Msgs" values in Table 1 and Table 2 =
assume that the DTLS session had been setup previously, so the cost of =
those messages is thus not included in this table. That's fine, but the =
cost of setting up that session might not be obvious to someone looking =
at the tables and it would be worth pointing it out explicitly in the =
text. But this is not a security consideration concern, only a =
suggestion to make the draft easier to understand.

Brian=

From tom.taylor.stds@gmail.com  Fri Jan 31 18:20:28 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7231ACCF4; Fri, 31 Jan 2014 18:20:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMhurur0kvv7; Fri, 31 Jan 2014 18:20:26 -0800 (PST)
Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id D3C6B1ACCE3; Fri, 31 Jan 2014 18:20:25 -0800 (PST)
Received: by mail-ig0-f170.google.com with SMTP id m12so2238043iga.1 for ; Fri, 31 Jan 2014 18:20:22 -0800 (PST)
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:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=d6sb92ttkxEobdFj82ZWJhH65++uS/Zlj7Krse7GY7Y=; b=KyWr1Jz8IS/fd9hXE/3U0TttuxRf4U9AFooC6B2by9Se2NJzJyy6ClX2u9FlmQQO6t ERUjx1yxnXbLMMKlEFmyKqKdyckZrMqDBPYx0RBj/0RtTcAkMplKiOGQNBLShq/Z7SNF K5D7bj8ohf/hd6cvVlMiG1UGYo2MYR6yjEgqolV8QRtMvGczyVqEFn7pmk15iyXE6AoN nI723djMdincEYWMAI6cS2vArMCLQ2r+e/Z5/wGSI3D38kBTUFUj4e10oRlGTHX+nlhq 2F/syJbGrEoB9E+cKikBNMTzwJVGAXgSwGyLTBj/7NYFWVRg8MWQOgUsqPW0j72473uN Imdw==
X-Received: by 10.50.176.165 with SMTP id cj5mr1486645igc.19.1391221221991; Fri, 31 Jan 2014 18:20:21 -0800 (PST)
Received: from [192.168.0.101] ([199.246.39.82]) by mx.google.com with ESMTPSA id l7sm3530347igx.2.2014.01.31.18.20.20 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Jan 2014 18:20:21 -0800 (PST)
Message-ID: <52EC59E2.7090500@gmail.com>
Date: Fri, 31 Jan 2014 21:20:18 -0500
From: Tom Taylor 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "Zhangdacheng (Dacheng)" ,  "iesg@ietf.org" , "secdir@ietf.org" ,  "draft-ietf-ancp-mc-extensions.all@tools.ietf.org" 
References:  <52E1B176.9070209@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [secdir] [spam] secdir review of draft-ietf-ancp-mc-extensions-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 01 Feb 2014 02:20:28 -0000

On 26/01/2014 12:53 AM, Zhangdacheng (Dacheng) wrote:
>>>
>>> 4)
>>>
>>> Section 6.1.3 lists the protocol elements that MUST be
>>> implemented to support the conditional access with white and
>>> black lists multicast capability. I found White-List-CAC TLV is
>>> included in the list. However, the White-List-CAC TLV is used to
>>> indicate that the NAS wishes the AN to do admission control for
>>> white-listed flows, and this use case is discussed in Section
>>> 3.4.2.3 of RFC 5851 "Multicast Admission Control and White
>>> Lists". So, I doubt whether this TLV needs to be supported is
>>> this case.
>>>
>> [PTT] Doesn't Section 3.4.2.3 describe a case where the AN does
>> both admission control and white listing, and sets the conditions
>> for doing that?
>>
>> "IPTV is an example of a service that will not be offered as best
>> effort, but requires some level of guaranteed quality of service.
>> This requires the use of Multicast Admission Control.  Hence, if
>> the Access Node wants to autonomously perform the admission
>> process, it must be aware of the bandwidth characteristics of
>> multicast flows. Otherwise, the Access Node would have to query the
>> NAS for Multicast Admission Control (per the grey list behavior);
>> this would defeat the purpose of using a white and black list."
>>
>
> [Dacheng Zhang:] Maybe I didn't explain my point view clearly last
> time. Sorry for that.
>
> If the title of section 6.13 is "Protocol Requirements For Admission
> Control With White and Black Lists ", then everything is perfect
> because this TLV is used to indicate that the NAS wishes the AN to do
> admission control for white-listed flows. The use case you provided
> above is also one for admission control. But at the moment, the tile
> of this section is " Protocol Requirements For Conditional Access
> With White and Black Lists ". That is why I raised a question here
> for your consideration. ^_^
>
> Cheers
>
> Dacheng
>
>
[PTT] This is the last outstanding item from your review.

The simple resolution is as you suggest: change the names of the 
capabilities. I'll do that.

Tom