From nobody Fri Apr 1 07:49:53 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762DC12D633; Fri, 1 Apr 2016 07:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.851 X-Spam-Level: X-Spam-Status: No, score=-100.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, USER_IN_WHITELIST=-100] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RC7MG7mWUr1E; Fri, 1 Apr 2016 07:49:51 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id F36B112D197; Fri, 1 Apr 2016 07:49:50 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 6478BF2403D; Fri, 1 Apr 2016 10:49:50 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id ZRxom3iaqzrc; Fri, 1 Apr 2016 10:35:36 -0400 (EDT) Received: from dhcp-88a7.meeting.ietf.org (dhcp-88a7.meeting.ietf.org [31.133.136.167]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id C3E21F2403B; Fri, 1 Apr 2016 10:49:48 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 31 Mar 2016 19:21:55 -0400 Message-Id: <077CD27B-ED2C-43B9-844F-D8ADA21B279E@vigilsec.com> To: draft-ietf-p2psip-share.all@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Alissa Cooper , IETF SecDir Subject: [secdir] Early SecDir Review of draft-ietf-p2psip-share-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 14:49:52 -0000 I reviewed this document for the Security Directorate after a request by the ART AD for an early review. Version reviewed: draft-ietf-p2psip-share-08 Summary: Not Ready (from a Security Directorate perspective) Major Concerns: In Section 3.1, there is an algorithm for assigning index values, and the text says that the high-order 24 bits of the Node-ID serve as a pseudo-random identifier. Since these 24 bits are obtained from the certificate that will be used to sign the stored data, the I think that the same bits will be used over and over. If I got this correct, then they are not pseudo-random. In addition, Section 3.1 points to RFC 3550, Section 8.1 for a discussion of the probability of a collision. The consequences of a collision seem to be different in the two documents. The consequences of a collision in the index should be clearly described in this document. Minor Concerns: None Nits: Please pick one spelling for Resource-IDs. (This is the spelling used in RFC 6940.) However, this document sometimes uses "Resource Id". Section 4.1 includes several examples for array indices. All of them are more than 32 bits: 0x123abc001, 0x123abc002, 0x123abc003, 0x123abc004, and 0x456def001. The most straightforward solution is to drop one of the zero digits. To improve readability, I think the first sentence of Section 5.1 should read: "In certain use cases, such as conferencing, it is desirable..." Section 5.1 says: When defining the pattern, care must be taken to avoid conflicts arising from two user names of witch one is a substring of the other. I think this paragraph would be improved with an acceptable example and a problematic example. In Section 5.3: s/AOR/Address of Record (AOR)/ In Section 6.2: s/This allows to invalidate entire subtrees/ /This allows the invalidation of entire subtrees/ In Section 8, please provide a reference for RELOAD. From nobody Sat Apr 2 08:03:41 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F7E12D62E; Fri, 1 Apr 2016 07:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zahg5McQ0MKI; Fri, 1 Apr 2016 07:53:46 -0700 (PDT) Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8820612D588; Fri, 1 Apr 2016 07:53:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,427,1454972400"; d="scan'208";a="38554579" Received: from post.haw-hamburg.de (HELO HUB01.mailcluster.haw-hamburg.de) ([141.22.24.50]) by mail6.is.haw-hamburg.de with ESMTP/TLS/AES256-SHA; 01 Apr 2016 16:53:40 +0200 Received: from CAS02.mailcluster.haw-hamburg.de (2002:8d16:183d::8d16:183d) by HUB01.mailcluster.haw-hamburg.de (2002:8d16:1832::8d16:1832) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 1 Apr 2016 16:53:40 +0200 Received: from [192.168.101.34] (141.22.250.35) by haw-mailer.haw-hamburg.de (141.22.24.61) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 1 Apr 2016 16:53:40 +0200 To: Russ Housley , "draft-ietf-p2psip-share.all@ietf.org" References: <46d6459124394dddbff5e9d7f48bf23b@HUB02.mailcluster.haw-hamburg.de> From: "Thomas C. Schmidt" Message-ID: <56FE8B6E.7050208@haw-hamburg.de> Date: Fri, 1 Apr 2016 11:53:34 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <46d6459124394dddbff5e9d7f48bf23b@HUB02.mailcluster.haw-hamburg.de> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [141.22.250.35] Archived-At: X-Mailman-Approved-At: Sat, 02 Apr 2016 08:03:41 -0700 Cc: Alissa Cooper , IETF SecDir Subject: Re: [secdir] Early SecDir Review of draft-ietf-p2psip-share-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 14:53:48 -0000 Hi Russ, thanks for the quick review. We will internally discuss and address within the next (IETF-) days and be back. Thomas On 31.03.2016 20:21, Russ Housley wrote: > I reviewed this document for the Security Directorate after a request > by the ART AD for an early review. > > Version reviewed: draft-ietf-p2psip-share-08 > > > Summary: Not Ready (from a Security Directorate perspective) > > > Major Concerns: > > In Section 3.1, there is an algorithm for assigning index values, and > the text says that the high-order 24 bits of the Node-ID serve as a > pseudo-random identifier. Since these 24 bits are obtained from the > certificate that will be used to sign the stored data, the I think that > the same bits will be used over and over. If I got this correct, then > they are not pseudo-random. > > In addition, Section 3.1 points to RFC 3550, Section 8.1 for a > discussion of the probability of a collision. The consequences of a > collision seem to be different in the two documents. The consequences > of a collision in the index should be clearly described in this > document. > > > Minor Concerns: None > > > Nits: > > Please pick one spelling for Resource-IDs. (This is the spelling used > in RFC 6940.) However, this document sometimes uses "Resource Id". > > Section 4.1 includes several examples for array indices. All of > them are more than 32 bits: 0x123abc001, 0x123abc002, 0x123abc003, > 0x123abc004, and 0x456def001. The most straightforward solution is > to drop one of the zero digits. > > To improve readability, I think the first sentence of Section 5.1 > should read: "In certain use cases, such as conferencing, it is > desirable..." > > Section 5.1 says: > > When defining the pattern, care must be taken to avoid conflicts > arising from two user names of witch one is a substring of the other. > > I think this paragraph would be improved with an acceptable example and > a problematic example. > > In Section 5.3: s/AOR/Address of Record (AOR)/ > > In Section 6.2: s/This allows to invalidate entire subtrees/ > /This allows the invalidation of entire subtrees/ > > In Section 8, please provide a reference for RELOAD. > -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From nobody Mon Apr 4 08:14:52 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACAEC12D702; Mon, 4 Apr 2016 08:14:47 -0700 (PDT) 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_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNL-ewRSGTNf; Mon, 4 Apr 2016 08:14:46 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 5890012D58F; Mon, 4 Apr 2016 08:14:46 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 2DC2F1022404C; Mon, 4 Apr 2016 08:14:46 -0700 (PDT) Received: from 31.133.176.131 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 4 Apr 2016 08:14:46 -0700 (PDT) Message-ID: <10417009fba695628b364f7d191f1672.squirrel@www.trepanning.net> Date: Mon, 4 Apr 2016 08:14:46 -0700 (PDT) From: "Dan Harkins" To: iesg@ietf.org, secdir@ietf.org, draft-ietf-tls-chacha20-poly1305.all@tools.ietf.org User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Subject: [secdir] secdir review of draft-ietf-tls-chacha20-poly1305 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 15:14:47 -0000 Greetings, 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 defines how to use the chacha20+poly1305 AEAD mode in TLS. chacha is a cipher mode "designed by D.J. Bernstein" and poly1305 is an authenticator "designed by D.J. Bernstein" (as the draft sees necessary to mention) and the two have been combined into an AEAD mode as defined in RFC 7539. This draft just says to use the method of AEAD incorporation that the TLS specification (RFC 5246) defines to put this AEAD mode into (D)TLS. It asks for 7 new TLS cipher suites. It's very concise and I consider it "Ready". That said, I'd add a personal nit (which doesn't rise to the level of "Ready with nits") that it's probably not necessary to have both a TLS_PSK_WITH and a PSK_ECDHE_PSK_WITH cipher suite and would prefer doing away with the former. regards, Dan. From nobody Mon Apr 4 09:47:43 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2127A12D612; Mon, 4 Apr 2016 09:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QK5Kzh-IYXOC; Mon, 4 Apr 2016 09:47:37 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09FE312D603; Mon, 4 Apr 2016 09:47:36 -0700 (PDT) X-AuditID: c6180641-f79fa6d0000057a9-34-57029a8251b8 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 12.F4.22441.28A92075; Mon, 4 Apr 2016 18:46:59 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0248.002; Mon, 4 Apr 2016 12:47:35 -0400 From: Kevin Ma J To: "cdni@ietf.org" Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-footprint-capabilities-semantics-14.txt Thread-Index: AQHRjpF1Jc9CDfq230a5hen6oGJfrp96BhOA Date: Mon, 4 Apr 2016 16:47:34 +0000 Message-ID: References: <20160404164550.15683.12529.idtracker@ietfa.amsl.com> In-Reply-To: <20160404164550.15683.12529.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyuXRPoG7zLKZwg1mzOSz63jayWjyd/YfV 4uqrzywW+9c1MFn0Ni1htmhv6GK0+LDwIYsDu8eU3xtZPXbOusvusWTJT6YA5igum5TUnMyy 1CJ9uwSujJ9LfzAV/BOuuL75MnMD4wr+LkYODgkBE4lZ18S7GDmBTDGJC/fWs3UxcnEICRxl lNi59BkjhLOMUeLMqrlsIFVsAloSj7/+ZQJpFhFQlvh5yBEkzCzwk1HiyM90EFtYIFKivfMa E4gtIhAlsXnpGXYI20ji7dpDjCA2i4CKxI6DO5hBbF4BX4m5l16B1QsJOEq8nbACLM4p4CRx Z8N1sF5GoOO+n1rDBLFLXOLWk/lMEEcLSCzZc54ZwhaVePn4HyuErSQx5/U1Zoh6HYkFuz+x QdjaEssWvobaKyhxcuYTlgmMYrOQjJ2FpGUWkpZZSFoWMLKsYuQoLS7IyU03MtzECIyvYxJs jjsY9/Z6HmIU4GBU4uFdcIoxXIg1say4MvcQowQHs5II7+ZpTOFCvCmJlVWpRfnxRaU5qcWH GKU5WJTEeb0j/4UJCaQnlqRmp6YWpBbBZJk4OKUaGHnWsi10qjplyKBlUnb4iNC9O7FbLTyT mezX1TZtuPnsR/u6xLIFk1Q/c0RY97fuktzGZeZX+Y2ju8jHwmv6Yed3gtaL96RX8Nm8tND0 +pzs9eaQwaWONUtjbmt2SDneZ8qcKjb16EsGTb6rW3d7pn6xjl4w4eunKZ9rJ81U2mm8Ri7h wakJ65VYijMSDbWYi4oTAfP5d5mrAgAA Archived-At: Cc: "ops-dir@ietf.org" , "secdir@ietf.org" , Jouni , Rick Casarez , "gen-art@ietf.org \(gen-art@ietf.org\)" Subject: Re: [secdir] [CDNi] I-D Action: draft-ietf-cdni-footprint-capabilities-semantics-14.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 16:47:42 -0000 Hi All, This latest version addresses secdir, genart, and opsdir comments. thanx! -- Kevin J. Ma > -----Original Message----- > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Monday, April 04, 2016 12:46 PM > To: i-d-announce@ietf.org > Cc: cdni@ietf.org > Subject: [CDNi] I-D Action: draft-ietf-cdni-footprint-capabilities- > semantics-14.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Content Delivery Networks Interconnectio= n > of the IETF. >=20 > Title : CDNI Request Routing: Footprint and Capabilitie= s > Semantics > Authors : Jan Seedorf > Jon Peterson > Stefano Previdi > Ray van Brandenburg > Kevin J. Ma > Filename : draft-ietf-cdni-footprint-capabilities-semantics- > 14.txt > Pages : 22 > Date : 2016-04-04 >=20 > Abstract: > This document captures the semantics of the "Footprint and > Capabilities Advertisement" part of the CDNI Request Routing > interface, i.e., the desired meaning of "Footprint" and > "Capabilities" in the CDNI context, and what the "Footprint and > Capabilities Advertisement Interface (FCI)" offers within CDNI. The > document also provides guidelines for the CDNI FCI protocol. It > further defines a Base Advertisement Object, the necessary registries > for capabilities and footprints, and guidelines on how these > registries can be extended in the future. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cdni-footprint-capabilities- > semantics/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-cdni-footprint-capabilities- > semantics-14 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-footprint-capabilitie= s- > semantics-14 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Mon Apr 4 16:29:45 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4156A12D8D7; Mon, 4 Apr 2016 16:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebRq4azCnHc4; Mon, 4 Apr 2016 16:29:40 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A2BB12D8CF; Mon, 4 Apr 2016 16:29:37 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id c20so45304128pfc.1; Mon, 04 Apr 2016 16:29:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:message-id:date:user-agent:mime-version; bh=ityBS8jy2n/UFZcchfym0W3q00aTKczLFXEzP2PwVto=; b=xwajxSyEDvQuG5q6xuyN/eJKAoucduvEEK7QNzIrqyAgBR6Jalr53eNT77u+/f2U2d rgW+c0dX44i7gQMecUe5L3JhDtkbMHyo7EBEFNJv13zkDdy4Ip0aQlA5T3qNxGCX7gan 3ooN5TZvjwl8XVS18NfHtJBX6859dkhSKfl+QUjjpquuKjZdeHcLUqNc6cxE0qvdJ7Uq SmrNTB6JfSc6PXLmKWtzZXDCJqb8Y0uTHEqZNo4qEYyzPOilE6T6bbR9u/I559HPNb9L XBFMu/TB40RAC7AwderMZ8ae2ygztkjhNrKs0PsTZGa695yyEJCmhkXCJjS/FPQkpVT9 ekHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:message-id:date:user-agent :mime-version; bh=ityBS8jy2n/UFZcchfym0W3q00aTKczLFXEzP2PwVto=; b=anUGm30a+cazqySc+mpVS0ONgRsWYrmbj1rJbyXyp3BDtPztLnp/gDSI8GYpKJmUiA /JiueeCMzjEzUsiCrXbwOQiQB/bLrE3AqZS9VdG6SMMWcvL0p1XFR4kKazdS9hdDXeQY X/xUBDQXaldyTW9jKWZfasQioGULmxc309xZhrGNXihCUpfoJ1I5tj1CSzIvq3mk1Ur5 ZwfpnHBzlBTtzP2kG6Qb6fteu0lRgBz09AjcpX6V5DlUviHglOfiev4jPrFaVHOnpFp+ Ju4OPJ6CbB+ZWdsHhc/eaeG6zglj7iII3nc8wQ5qTyVIOPvN+BvDB4vXCnkn0GpuWbMJ M7Sw== X-Gm-Message-State: AD7BkJI2F3fbcPjVBEFJNdxXonjQXVjMJgjFtOaOWvslE00UD/vtXUXv3Sar3X/sTdS73g== X-Received: by 10.157.12.200 with SMTP id o8mr12509021otd.148.1459812577075; Mon, 04 Apr 2016 16:29:37 -0700 (PDT) Received: from Chriss-Air.attlocal.net ([2602:306:838b:1c40:43a:4567:5271:7b4e]) by smtp.googlemail.com with ESMTPSA id v34sm9144552otv.0.2016.04.04.16.29.36 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Apr 2016 16:29:36 -0700 (PDT) From: Chris Lonvick To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-roll-applicability-ami.all@ietf.org Message-ID: <5702F8DE.8000809@gmail.com> Date: Mon, 4 Apr 2016 18:29:34 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------030209010502070405060903" Archived-At: Subject: [secdir] SECDIR review of draft-ietf-roll-applicability-ami-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 23:29:42 -0000 This is a multi-part message in MIME format. --------------030209010502070405060903 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Overall, the document looks great. This is a very information-dense document and the authors and contributors have done a wonderful job of putting it together. While I do not follow the technology, I was able to understand the concepts and I could see that the security considerations were appropriate. Some very small nits that the authors may want to consider: - the terms DODAG, DIO, and DAO are not expanded anywhere. (Yeah, I know I could go look them up... ;-) - The 2nd paragraph in 9.3 ends with "Known schemes". I figure someone was going to write something more there. Regards, Chris --------------030209010502070405060903 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi,

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

Overall, the document looks great. This is a very information-dense document and the authors and contributors have done a wonderful job of putting it together. While I do not follow the technology, I was able to understand the concepts and I could see that the security considerations were appropriate.

Some very small nits that the authors may want to consider:
- the terms DODAG, DIO, and DAO are not expanded anywhere. (Yeah, I know I could go look them up... ;-)
- The 2nd paragraph in 9.3 ends with "Known schemes". I figure someone was going to write something more there.

Regards,
Chris
--------------030209010502070405060903-- From nobody Tue Apr 5 06:53:26 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD4212D132 for ; Tue, 5 Apr 2016 06:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 acxoGykYhyWJ for ; Tue, 5 Apr 2016 06:53:22 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9890012D0AE for ; Tue, 5 Apr 2016 06:53:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1FD59BE53 for ; Tue, 5 Apr 2016 14:53:21 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HUm7oSilFFM for ; Tue, 5 Apr 2016 14:53:19 +0100 (IST) Received: from [31.133.178.21] (dhcp-b215.meeting.ietf.org [31.133.178.21]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DCD8FBE25 for ; Tue, 5 Apr 2016 14:53:18 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1459864399; bh=ElOc8hmqQhCiBEZkFmT3nRleFQTgcST9OqShj07YexA=; h=Subject:To:References:From:Date:In-Reply-To:From; b=MS43zXzxZTAxZf46SO3aYdRBhpedDecUTLv1k/lhEPN5REMvY5/GabCRnq68SKGaY nYzq0hJGYjL+ZunmEkfg53rFMmCWAidh/mV/3oycKu0zrcdqH1IScnEpdoz9lRyEKs OwhCmT+8AyiWio0PIV2LKdSrUB9zx9vVpMLHrw8g= To: "secdir@ietf.org" References: <56F2C599.5010309@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5703C34C.4080103@cs.tcd.ie> Date: Tue, 5 Apr 2016 14:53:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56F2C599.5010309@cs.tcd.ie> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080403080209060703060805" Archived-At: Subject: Re: [secdir] secdir lunch location X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 13:53:25 -0000 This is a cryptographically signed message in MIME format. --------------ms080403080209060703060805 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Reminder. There's a lunch option at -2 I think where the Sunday reception was held. (I've not been there so do correct this if that's wrong.) Also, if someone could volunteer to help out via offering a laptop for presenting at saag that'd be great - mine seems to be able to produce a really nice flicker that'd be quite irritating 2 hours in;-) Thanks, S. On 23/03/16 16:34, Stephen Farrell wrote: >=20 > Hi all, >=20 > We'll have the usual secdir lunch on Tuesday at IETF95. > The room is "Atlantico A" from 1230 to 1400. >=20 > See you then, > Cheers, > S. >=20 >=20 >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >=20 --------------ms080403080209060703060805 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA0MDUx MzUzMTZaMC8GCSqGSIb3DQEJBDEiBCC2oaCBmER8+P5KY+ierGhXj0/cL1ntkPiBjyLmsb1V 2zBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBx+ViauPAA/L532P1IyC/4is10y0Ev8q2P7iI0cDZGarIyPVfD2CyF VINLsXX5f8ZM4i6Ao6D3qvzYzQziT72RefX7Iax7rvpHaPvOjXJ55VR4j7SmuGU5dNruwwg0 lB3vAc/rxGTzFCDseGUmgVt0Ly3vgHUPFSro9yhE4VhHEQ/WOXihcChMr/bBhpeC0CXh117y nO/wf78yZt5UU+F1AzqY65nw6+m8jsAKiRwGNDNk6tFTJBFSiA5mPA2ncoWAIbmQSgIsZtwm als7NF31Jn225aK/C1uxaYB6Shh9KxIydlj98xv9xsUJ15ILxu3BUnfymFMQxxOw7zSPQTtc AAAAAAAA --------------ms080403080209060703060805-- From nobody Tue Apr 5 07:55:39 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEBAC12D0BD for ; Tue, 5 Apr 2016 07:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrAytXkauefF for ; Tue, 5 Apr 2016 07:55:34 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EE3F12D109 for ; Tue, 5 Apr 2016 07:55:33 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u35EtL5t029761 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 5 Apr 2016 17:55:21 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u35EtKjL001727; Tue, 5 Apr 2016 17:55:20 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22275.53720.815326.974452@fireball.acr.fi> Date: Tue, 5 Apr 2016 17:55:20 +0300 From: Tero Kivinen To: Stephen Farrell In-Reply-To: <5703C34C.4080103@cs.tcd.ie> References: <56F2C599.5010309@cs.tcd.ie> <5703C34C.4080103@cs.tcd.ie> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 1 min Archived-At: Cc: "secdir@ietf.org" Subject: Re: [secdir] secdir lunch location X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 14:55:37 -0000 Stephen Farrell writes: > Reminder. There's a lunch option at -2 I think where the > Sunday reception was held. (I've not been there so do > correct this if that's wrong.) And that is cash only, and was very slow on Monday, only one cashier, 4-7 other people behind the table not doing anything. -- kivinen@iki.fi From nobody Tue Apr 5 09:04:52 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B5012D703 for ; Tue, 5 Apr 2016 09:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmOr4VLNAC45 for ; Tue, 5 Apr 2016 09:04:48 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 640E412D6E6 for ; Tue, 5 Apr 2016 09:04:47 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u35G4h0v015025 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 5 Apr 2016 19:04:43 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u35G4hZE020339; Tue, 5 Apr 2016 19:04:43 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22275.57883.437270.81263@fireball.acr.fi> Date: Tue, 5 Apr 2016 19:04:43 +0300 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 2 min Archived-At: Subject: [secdir] SecDir tool url X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 16:04:51 -0000 https://art.tools.ietf.org/tools/art/secdir/ If you go to the My Info you can modify your information and mark yourself of being away until certain date (yyyy-mm-dd). After that you will be marked unavailable immediately and you will automatically marked available when the date comes. Or you can just send email to me and I can do it also. -- kivinen@iki.fi From nobody Tue Apr 5 09:07:14 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0729A12D716 for ; Tue, 5 Apr 2016 09:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTb9L5PgTF8s for ; Tue, 5 Apr 2016 09:07:11 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5525412D71A for ; Tue, 5 Apr 2016 09:07:08 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id o6so6768355qkc.2 for ; Tue, 05 Apr 2016 09:07:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7pCujvRSfslpLpAcLASgaqVQlQfp8/DTkpmjsWC5y+U=; b=SseNFvwOVuTeQTuWbwH6tjNoXvD8/jIRyCQNNKz0vquRB2NslPRy8nbm7GImLoSnR4 nvsaLfEOok3lyJPxfZv5SXFTRqxK9e+ZHnHrTGDGOXviZkdxL/caFuW4hon3Hx0+mqQH JIXIjESOwmsJHf+nEdSSJUiK6Ebe2OYDEbeil9JVfpyY5BmvoRkl70jyaWxJZbQRGanu CwlGiniztR5FoFKd17tTxZzl+0tOaeEZuUrbdT0azFkHhrx0Dbjz/0p/uDayMxdujOSP jorbIRu/JjY+CddFtwukE4G13EChWl28sp504MBLXAF04oV2kRcTf+bRLTA0Q2aviqEl nWaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7pCujvRSfslpLpAcLASgaqVQlQfp8/DTkpmjsWC5y+U=; b=l4zlA6oWdhb07CbHkOGkH5GHGe97oOqqcBwaVh8e2/34l2HngqFHvZf4W+hFTtFY3j iODATY1yv6V9XrEdyJI4wPTXVInEpKJzAnEutaRnAtH9uHOvq4T9ozDdOqUWRs3CxfHW 5+bAsibTqw9HMsCvr/01BbMNIv86ltsPxsMxgfGP72sPuMYGZh9sxBNrsQM+8KOfqqub ksbpgtKQi7vgnKXUq34Qw+3aFn55DubUHKl8Sq107NBiLg77YCfcx+MJdV1QcSRJB3xM bXTb24ycGP7ggA1kJ3M+OHV6VWgIKM0Wcdm5k3/VXWr4xLWSSOJ/AHbvI5LTKM8GHvvc Y2Iw== X-Gm-Message-State: AD7BkJIeOBK2JHVmCfOjJ2cvHQ5Wi1PdYyqbqoNS9+uFjKv84bal44u2XlVguvJD46QDgA== X-Received: by 10.55.82.6 with SMTP id g6mr16381004qkb.40.1459872427364; Tue, 05 Apr 2016 09:07:07 -0700 (PDT) Received: from ?IPv6:2001:67c:370:160:8144:811c:2d37:188b? ([2001:67c:370:160:8144:811c:2d37:188b]) by smtp.gmail.com with ESMTPSA id w16sm14893277qka.35.2016.04.05.09.07.06 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 05 Apr 2016 09:07:06 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: <22275.57883.437270.81263@fireball.acr.fi> Date: Tue, 5 Apr 2016 13:07:04 -0300 Content-Transfer-Encoding: 7bit Message-Id: References: <22275.57883.437270.81263@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3124) Archived-At: Cc: secdir@ietf.org Subject: Re: [secdir] SecDir tool url X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 16:07:13 -0000 Error is unauthorized to use this system > On 5 Apr 2016, at 1:04 PM, Tero Kivinen wrote: > > https://art.tools.ietf.org/tools/art/secdir/ > > If you go to the My Info you can modify your information and mark > yourself of being away until certain date (yyyy-mm-dd). After that you > will be marked unavailable immediately and you will automatically > marked available when the date comes. > > Or you can just send email to me and I can do it also. > -- > kivinen@iki.fi > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Tue Apr 5 09:10:52 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFAD912D72A for ; Tue, 5 Apr 2016 09:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgOCRRSZ0bG4 for ; Tue, 5 Apr 2016 09:10:50 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD8C212D725 for ; Tue, 5 Apr 2016 09:10:49 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qfYjz3NXbz79f; Tue, 5 Apr 2016 18:10:47 +0200 (CEST) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id E8qFlpUfKPqf; Tue, 5 Apr 2016 18:10:41 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 5 Apr 2016 18:10:41 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id B303A600BAE6; Tue, 5 Apr 2016 12:10:40 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca B303A600BAE6 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B124B875BEA; Tue, 5 Apr 2016 12:10:40 -0400 (EDT) Date: Tue, 5 Apr 2016 12:10:40 -0400 (EDT) From: Paul Wouters To: Yoav Nir In-Reply-To: Message-ID: References: <22275.57883.437270.81263@fireball.acr.fi> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: secdir@ietf.org Subject: Re: [secdir] SecDir tool url X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 16:10:52 -0000 On Tue, 5 Apr 2016, Yoav Nir wrote: > Error > > is unauthorized to use this system worked with my tools login. Paul From nobody Tue Apr 5 09:11:02 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C105F12D736 for ; Tue, 5 Apr 2016 09:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sp9uJfxVAo-Q for ; Tue, 5 Apr 2016 09:10:59 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72D1B12D731 for ; Tue, 5 Apr 2016 09:10:59 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u35GAu86021221 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 5 Apr 2016 19:10:56 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u35GAukj021678; Tue, 5 Apr 2016 19:10:56 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22275.58256.320120.145597@fireball.acr.fi> Date: Tue, 5 Apr 2016 19:10:56 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: References: <22275.57883.437270.81263@fireball.acr.fi> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 3 min Archived-At: Cc: secdir@ietf.org Subject: Re: [secdir] SecDir tool url X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 16:11:01 -0000 Yoav Nir writes: > is unauthorized to use this system If you have this issue, contact me with the email address you want to use. I now changed your checkpoint.com email to your gmail.com address. -- kivinen@iki.fi From nobody Tue Apr 5 09:17:42 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E5812D6CB for ; Tue, 5 Apr 2016 09:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4pHwxEJA-hE for ; Tue, 5 Apr 2016 09:17:39 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBD0C12D722 for ; Tue, 5 Apr 2016 09:17:38 -0700 (PDT) Received: by mail-qg0-x236.google.com with SMTP id j35so14348781qge.0 for ; Tue, 05 Apr 2016 09:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pFlLpQnNrfDz6JimDv1Mpw4YnxfLQWtA4WUWPqW9wGU=; b=OEgknBx7QXI8WKOvAFBtbK4SkSdZMbkBtC54DMmn245G2Ip3nIlKg/DFyuqzb+z2/8 kr0U3Pl+IvVaEGW8YkYy9uzQ6CWZ82YPfFlArlUeRxnOS8PQ3Gur00V2siHeG2uBa96k eQgEcfvTo39pPOt7+xMpnc3eXZWHnjLnOuKWZyJaU7ng1pAtjr+BZCxH5VEcPa092lJ1 732ov8q+IWMN9goh6nDD6wgrFJ7CG6qKfiGtrysO4H6jwNW8bRTJ+p5WWVq36TwJ7O4v 3WWuhik1rnxbD4c1s7cAZygExlRhT2Osrm4jKHG6/ao2ZgPkziq+3xffUAEn0PJehw7Q SnPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pFlLpQnNrfDz6JimDv1Mpw4YnxfLQWtA4WUWPqW9wGU=; b=fs6uvBUl2S0tPsMkqK0kSheuTxi+SPNbAM8KCpPgWQO8CeUM5liu3H2UOu/z9YvPYO VxGvWPAuEDKRGcGFubwRu3MUv3ccik/2pEXaLX8zdxjxi2KqduLiUog79B2nKYP5mSH8 hdebbhdANNE9AYDLa5HPCsQNjRMgLoREVKVCthWMF3vBuZCvNkrjsk+fWIjgz3Cd6rZ5 zE5dQUmpPkj10OQaiDYaZyihU7XMSF+flvXXmLF9NerpjDCA1lKz/9FQsc17+Z/sxdZ0 5fUiFpz+ADxD9O9PZArqVn37X9wWHHm2wdQklv0BpPOPTAwybwCCaxysfKVTIa4JyWvo mZXA== X-Gm-Message-State: AD7BkJKNF4oxNzBiEmDskBhSZb/h0vn2LHZVgGE4hTilaJAYzmlADoUFmQX5XFzq5B1Qkw== X-Received: by 10.140.18.114 with SMTP id 105mr47553878qge.41.1459873058150; Tue, 05 Apr 2016 09:17:38 -0700 (PDT) Received: from ?IPv6:2001:67c:370:160:8144:811c:2d37:188b? ([2001:67c:370:160:8144:811c:2d37:188b]) by smtp.gmail.com with ESMTPSA id a189sm14703471qhd.33.2016.04.05.09.17.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 05 Apr 2016 09:17:37 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: <22275.58256.320120.145597@fireball.acr.fi> Date: Tue, 5 Apr 2016 13:17:35 -0300 Content-Transfer-Encoding: 7bit Message-Id: References: <22275.57883.437270.81263@fireball.acr.fi> <22275.58256.320120.145597@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3124) Archived-At: Cc: secdir@ietf.org Subject: Re: [secdir] SecDir tool url X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 16:17:41 -0000 Works now. Thanks. > On 5 Apr 2016, at 1:10 PM, Tero Kivinen wrote: > > Yoav Nir writes: >> is unauthorized to use this system > > If you have this issue, contact me with the email address you want to > use. > > I now changed your checkpoint.com email to your gmail.com address. > -- > kivinen@iki.fi From nobody Tue Apr 5 09:56:17 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6124612D798 for ; Tue, 5 Apr 2016 09:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGeJSl5jCTJR for ; Tue, 5 Apr 2016 09:56:13 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7154412D78E for ; Tue, 5 Apr 2016 09:56:11 -0700 (PDT) X-AuditID: 1209190c-1a7ff70000002ca7-8a-5703ee2a2685 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 05.9C.11431.A2EE3075; Tue, 5 Apr 2016 12:56:10 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u35Gu94F011904 for ; Tue, 5 Apr 2016 12:56:10 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u35Gu6RO013273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 5 Apr 2016 12:56:09 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u35Gu6p8019459; Tue, 5 Apr 2016 12:56:06 -0400 (EDT) Date: Tue, 5 Apr 2016 12:56:06 -0400 (EDT) From: Benjamin Kaduk To: secdir@ietf.org Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBIsWRmVeSWpSXmKPExsUixCmqrav1jjnc4N4uYYsPCx+yODB6LFny kymAMYrLJiU1J7MstUjfLoEr48fDhSwFaRUv/s9ib2D062Lk5JAQMJFYt6WPuYuRi0NIoI1J 4kPnYnaQhJDAMUaJb3fcIBLXmSQW/zrKBpGolzj9ZRMLiM0ioCXx5vsJRhCbTUBFYuabjWA1 IgLCErcPPmAFsYUF9CR2Pm9hBrF5BRwlrh+eB1YvKqAjsXr/FBaIuKDEyZlPwGxmoJnLp29j mcDIOwtJahaS1AJGplWMsim5Vbq5iZk5xanJusXJiXl5qUW6hnq5mSV6qSmlmxjBASPJs4Px zBuvQ4wCHIxKPLwOb5nChVgTy4orcw8xSnIwKYnylj5hDhfiS8pPqcxILM6ILyrNSS0+xCjB wawkwhvxEijHm5JYWZValA+TkuZgURLnLdx/OkxIID2xJDU7NbUgtQgmK8PBoSTB++gNUKNg UWp6akVaZk4JQpqJgxNkOA/Q8BSQGt7igsTc4sx0iPwpRkuOZ9OurWXieAEmF/y4vZZJiCUv Py9VSpzXAqRBAKQhozQPbiY4AexmUn3FKA70ojDvH5AqHmDygJv6CmghE9DCemEmkIUliQgp qQbGZG29DLO7Qok8+e+SquI5rTourzYofTnlFpeVzWPOis3S2tP3P+ldann5mVl/nyLLb9cF Z7afYCpYefnn7N9KK8SPTjlVLn41x65MM/tbeKrIGhmbu2J8j69o3zaKz9Baw9KXWfzB58l3 qa0PNyYv9Y34FJ3+6VKr6NdjVTffiBuqzZ/d1hmjxFKckWioxVxUnAgAiqcFMNsCAAA= Archived-At: Subject: [secdir] coat left in ro9m after secdir lunch? X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 16:56:15 -0000 There's a medium, black, Austin Reed coat on the floor here. I'm leaving it alone for now. -Ben From nobody Tue Apr 5 10:16:50 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C92412D0DD for ; Tue, 5 Apr 2016 10:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEsJl0Mj_dMh for ; Tue, 5 Apr 2016 10:16:47 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 280E812D199 for ; Tue, 5 Apr 2016 10:16:47 -0700 (PDT) Received: by mail-lb0-x22d.google.com with SMTP id qe11so13654792lbc.3 for ; Tue, 05 Apr 2016 10:16:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to; bh=ZktGzyt4G99JxXBIPhiRavlO3nfVjexaSOeKUbEe2rA=; b=XmYoWvLxYxSTu5K0fkRAF9Jpgiz7qiVmcSgi3Av0vs1Ca/S4KVP3gLHoXN1pW35EhB yljUBMYAtc1669yQMy51rtOoAzmpeFvoMZc0y9ApVXie1wvWM1s0WE+UiDIw9OkKwWw5 ktSm1wxorYtUs0nD8JFU+qr4YNa4d/gnxhRyZdswkcEX0qntPvXbKPkWmwd/rLqhR6mY 39peMNiatYcinTUIVMjhDqdv8b+S/islqoMC1lF8I5442ji8CNXVeqfm4Zd9cV+X3Y9K eedo/GpBQCPUvOkaKJHWDHsJJP6b4ehSNl+Yt8XacEo39Y40u5NOSvsTn0k9+xw1vcmH WYEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to; bh=ZktGzyt4G99JxXBIPhiRavlO3nfVjexaSOeKUbEe2rA=; b=LM7yp9QQa1w/iP2KsB2jKKIW0/S4es9fdkqJXDCNSLMY5nGsR7vSpZGNeGG/olY/Zy cS5W5oc8szsexc36pgv3PYGGdM10cEm4u23HaXaW3lnvOeJA7CtW/eOswPf8OryvyQxv 3ZwqPp8dANu8+hy/MtxE+X7rh+nthCIco8KAymzxeUGLL0QdkfBF+FhsZPyY3MnHIlen bDTM2DjGOq6d3G7UZQJNuqKc0a8vXHtlJCskJwHM4TIuwQBW3fEKuSkJyE9bFGgvLL81 mmL1q6elk+z5KEANiekucVGkrSaP1Yr/VvNzAFreFtTJY4REP3VyE3866hW9YzzYT1uj eTOg== X-Gm-Message-State: AD7BkJLp2wPSpMHpY+3ZCnG19eYhQuYHfZBc1fESy3ccc8c+HVO3mR4lBtj6qi8sY18J1qDV8KQxOvS9owR7xA== MIME-Version: 1.0 X-Received: by 10.112.51.8 with SMTP id g8mr3475175lbo.109.1459876605347; Tue, 05 Apr 2016 10:16:45 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.151.67 with HTTP; Tue, 5 Apr 2016 10:16:45 -0700 (PDT) Date: Tue, 5 Apr 2016 14:16:45 -0300 X-Google-Sender-Auth: iTHHNt2BP7ZLTc9UTaqtcK7CwP8 Message-ID: From: Phillip Hallam-Baker To: "secdir@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [secdir] Paraiso NOT the room we were in for Mesh! 19:10-20:30 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 17:16:50 -0000 Sorry, turns out Pariso is NOT the IESG room we were in ---------- Forwarded message ---------- From: Phillip Hallam-Baker Date: Fri, Apr 1, 2016 at 6:19 PM Subject: MESH Bar BOF Tues 19:10-21:00 in the IESG room Paraiso To: "saag@ietf.org" People generally agree that usability is the biggest problem facing us in security. Security that people don't use is useless. The problem is harder than merely making secure applications as easy to use as regular apps. If we are going to change people's behavior, we have to make using the computer easier. Or at least make juggling the many computers, mobiles, IoT devices etc. easy. The Mathematical Mesh is a cryptographic infrastructure that allows a user to create a personal profile and securely connect applications and devices to it. All connections are authenticated bilaterally, end to end and with a direct trust model (no trusted third party required). There is a cloud service involved but it is an untrusted service and the user can switch to another any time they like (like a git repository). The tools are automated on the principle of 'don't give the user instructions that can be replaced by code'. When applications are connected, the user has the option of having the profile management tool add in security. So when you connect Windows Live Mail to a Mesh profile, the profile manager will automatically turn on S/MIME. Right now the certs are self-signed but I am working on getting it hooked up to the Comodo free cert issue. All the code is open source under an MIT license and there are links to the Internet Drafts and the demo videos on the following site: http://cryptomesh.org/ [or http://prismproof.org/] Right now the code has only been tested on Windows. But I am in the middle of trying to get the GUI to work under GTK# which will 'allegedly' allow the code to run on OSX and Linux. The first applications I want to get support for are SSH and a WebPassword manager. The advantage of the latter over existing cloud offerings being that it will be auditable. I am also working on hooking up some IoT devices. From nobody Tue Apr 5 10:17:39 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A0112D199 for ; Tue, 5 Apr 2016 10:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otnIM0V39o3b for ; Tue, 5 Apr 2016 10:17:35 -0700 (PDT) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 131C212D170 for ; Tue, 5 Apr 2016 10:17:35 -0700 (PDT) Received: by mail-qg0-x232.google.com with SMTP id f52so15657277qga.3 for ; Tue, 05 Apr 2016 10:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WlPIO3z1fi5hynGYboearTS53zKMjWf7kJpW6Hod8aw=; b=v+pa1uhRgKLDcC7cn+H9tt9yrGHaaHoa3y0JLf5fr/9tPWau6u0brHtesikq1KQBuX 1okz4PoueV39Rbi4gKfGSsyUY1W+TTZPNwx7olxbNDx4OSDc1p0QDWM2rVEdcU24rSJC +tHMcQDi0FdRtaNcUh2b+JGlsS1o7zsPq/mf5R7QbOwBehwZM7+A2f4NGTRM8Ewx2P+y 8oMgWLqF0R5I9D77HIdomwySMpl6mA0vEOBOM1mDf0eZTKp6GV+98HGnhEUHTwOTTxlP ldPBav/gmPOgv+hpGHLG30kS3Bv/8cVfu9EKV5iBX0a93gIbpSUDwAFMrWUcdzqjzWvZ E8vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WlPIO3z1fi5hynGYboearTS53zKMjWf7kJpW6Hod8aw=; b=bP5HoKXQKYBver/GosdwM36+oovcGBwUpwDOxCJgjAOSb7qhjaqMbnpNhdZu/nVPdD ODCyRN02jZPq0q8E8phobqPWFF+p0h5VqpXY7CBhZEDG3Mg+l5wZg3jQWmeHwdGTS8X7 JxGhU7mCkZcvPFcIxtyh7OO/94xxx8IDn11DVwCVQt5XdtNrmHfo3tdbC/8APgchsjs2 OuDk/Q4zb0cwBX3W1x49QlBgtK/uiLsfw3aDgsK5rHANQTMZ+ZlPqZ3vAWQ/JLAkEfXw vkbwOlmXh9Tb0MWY5+9MRAtkYz9I76LvVsV+rsRP7UZrkNHCrwDbiQXiu+0ET9/Jxoq9 eZXA== X-Gm-Message-State: AD7BkJL5oCqBEYPTbURPiIFK+Sruz1Xz/lPuMAxDfrrZO0mDndENnw2yJCxADXqtegfOYw== X-Received: by 10.140.165.205 with SMTP id l196mr93308qhl.58.1459876654107; Tue, 05 Apr 2016 10:17:34 -0700 (PDT) Received: from ?IPv6:2001:67c:370:160:54f8:faa7:efed:c3ea? ([2001:67c:370:160:54f8:faa7:efed:c3ea]) by smtp.gmail.com with ESMTPSA id r65sm15043656qki.17.2016.04.05.10.17.32 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 05 Apr 2016 10:17:33 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: Date: Tue, 5 Apr 2016 14:17:31 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <185E1B6A-C549-45DC-9A59-0BFC3F456805@gmail.com> References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "secdir@ietf.org" Subject: Re: [secdir] Paraiso NOT the room we were in for Mesh! 19:10-20:30 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 17:17:37 -0000 Yeah, that would be Atlantico A. So in which of them is your Bar BoF? > On 5 Apr 2016, at 2:16 PM, Phillip Hallam-Baker = wrote: >=20 > Sorry, turns out Pariso is NOT the IESG room we were in >=20 >=20 > ---------- Forwarded message ---------- > From: Phillip Hallam-Baker > Date: Fri, Apr 1, 2016 at 6:19 PM > Subject: MESH Bar BOF Tues 19:10-21:00 in the IESG room Paraiso > To: "saag@ietf.org" >=20 >=20 > People generally agree that usability is the biggest problem facing us > in security. Security that people don't use is useless. >=20 > The problem is harder than merely making secure applications as easy > to use as regular apps. If we are going to change people's behavior, > we have to make using the computer easier. Or at least make juggling > the many computers, mobiles, IoT devices etc. easy. >=20 > The Mathematical Mesh is a cryptographic infrastructure that allows a > user to create a personal profile and securely connect applications > and devices to it. All connections are authenticated bilaterally, end > to end and with a direct trust model (no trusted third party > required). >=20 > There is a cloud service involved but it is an untrusted service and > the user can switch to another any time they like (like a git > repository). >=20 > The tools are automated on the principle of 'don't give the user > instructions that can be replaced by code'. >=20 > When applications are connected, the user has the option of having the > profile management tool add in security. So when you connect Windows > Live Mail to a Mesh profile, the profile manager will automatically > turn on S/MIME. Right now the certs are self-signed but I am working > on getting it hooked up to the Comodo free cert issue. >=20 > All the code is open source under an MIT license and there are links > to the Internet Drafts and the demo videos on the following site: >=20 > http://cryptomesh.org/ > [or http://prismproof.org/] >=20 > Right now the code has only been tested on Windows. But I am in the > middle of trying to get the GUI to work under GTK# which will > 'allegedly' allow the code to run on OSX and Linux. >=20 > The first applications I want to get support for are SSH and a > WebPassword manager. The advantage of the latter over existing cloud > offerings being that it will be auditable. >=20 >=20 > I am also working on hooking up some IoT devices. >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Tue Apr 5 10:34:52 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A911412D7E9 for ; Tue, 5 Apr 2016 10:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYQCECY-ZnKV for ; Tue, 5 Apr 2016 10:34:49 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B15A312D775 for ; Tue, 5 Apr 2016 10:34:48 -0700 (PDT) Received: by mail-lb0-x235.google.com with SMTP id u8so14016445lbk.0 for ; Tue, 05 Apr 2016 10:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=o3CZOJP6rbqrYdmswAwFsUGnMEHzjsQ1jlvc4qDZH7Y=; b=yWrQCeIrMcpBP6CNPCbTq8CPYby/1O6Hy295GOf7qBvemlv1iyfbywmC/Q9cZfDB/e uVH7OTaqoTPgSElpXkx0e95lHCvS+hywJhHDHtIHterlJke0EBMu51+GbAmaBbp4a7Bb zvW2FJUnnGqszxCZimljwo3gOwDE7jAMhhVHrqNy5rXLvklaregU8sIuwIWiVkTKwXvn OwDdE+XRSv+c8VKBKuHXKvRvqEl/Iuf2ba3+pcPI+7kSBl/6AZHS+qNwMN8XoCnqSaR5 /POhUNnjnzDDOPEfZmvZ4qfoTt1oh0wF8M73YwTqH1BSidsFhXHqlh95qfdWhRciKZXA hHOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=o3CZOJP6rbqrYdmswAwFsUGnMEHzjsQ1jlvc4qDZH7Y=; b=E+NOEqb254Otu+bexyqflUPF8DeX9a3esdGq6K2+QgCuLX6Latl5XcvapWqVQo+nh9 rWMbe6O8Eduopz7w+USaRGqulHtuGSd+c502OeFsbNU7EwDahrkBk1GgaV0GB89e1OYv qyE8Hd8nHrekXb+yoY1MWaKMfpcuXAtdLvAJcLtFdg0ZSCM6ygrcYqLVHflc9UG542c9 A7QE2SPCN+MVhU3C0twOPyEQL/kyLyld1vxsOj3stKZSJYCeEuCR2n+7+opyZZthX649 W/F3lQjdskDfRZEd9ek1kGjQ1pPrOcNjkEivMgyx/etV6hR69zIQeX+eD280pwiI0IQp JmaA== X-Gm-Message-State: AD7BkJIwNHwXjLACaO8vasjPcdyaQm7YrcP5Q4Iz7Bg0RiLJHUCkSoxjrSm6RXuaAUfgln3tiJ4FeEj0tEW/DQ== MIME-Version: 1.0 X-Received: by 10.112.161.41 with SMTP id xp9mr1483890lbb.133.1459877686861; Tue, 05 Apr 2016 10:34:46 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.151.67 with HTTP; Tue, 5 Apr 2016 10:34:46 -0700 (PDT) In-Reply-To: <185E1B6A-C549-45DC-9A59-0BFC3F456805@gmail.com> References: <185E1B6A-C549-45DC-9A59-0BFC3F456805@gmail.com> Date: Tue, 5 Apr 2016 14:34:46 -0300 X-Google-Sender-Auth: 7TCDyxS-9ZeSCeZYSvzN-nsKtHk Message-ID: From: Phillip Hallam-Baker To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "secdir@ietf.org" Subject: Re: [secdir] Paraiso NOT the room we were in for Mesh! 19:10-20:30 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 17:34:51 -0000 OK I have checked and I have emails stating both. So I will check with Stephanie and post a note on the wrong one. On Tue, Apr 5, 2016 at 2:17 PM, Yoav Nir wrote: > Yeah, that would be Atlantico A. > > So in which of them is your Bar BoF? > >> On 5 Apr 2016, at 2:16 PM, Phillip Hallam-Baker wrote: >> >> Sorry, turns out Pariso is NOT the IESG room we were in >> >> >> ---------- Forwarded message ---------- >> From: Phillip Hallam-Baker >> Date: Fri, Apr 1, 2016 at 6:19 PM >> Subject: MESH Bar BOF Tues 19:10-21:00 in the IESG room Paraiso >> To: "saag@ietf.org" >> >> >> People generally agree that usability is the biggest problem facing us >> in security. Security that people don't use is useless. >> >> The problem is harder than merely making secure applications as easy >> to use as regular apps. If we are going to change people's behavior, >> we have to make using the computer easier. Or at least make juggling >> the many computers, mobiles, IoT devices etc. easy. >> >> The Mathematical Mesh is a cryptographic infrastructure that allows a >> user to create a personal profile and securely connect applications >> and devices to it. All connections are authenticated bilaterally, end >> to end and with a direct trust model (no trusted third party >> required). >> >> There is a cloud service involved but it is an untrusted service and >> the user can switch to another any time they like (like a git >> repository). >> >> The tools are automated on the principle of 'don't give the user >> instructions that can be replaced by code'. >> >> When applications are connected, the user has the option of having the >> profile management tool add in security. So when you connect Windows >> Live Mail to a Mesh profile, the profile manager will automatically >> turn on S/MIME. Right now the certs are self-signed but I am working >> on getting it hooked up to the Comodo free cert issue. >> >> All the code is open source under an MIT license and there are links >> to the Internet Drafts and the demo videos on the following site: >> >> http://cryptomesh.org/ >> [or http://prismproof.org/] >> >> Right now the code has only been tested on Windows. But I am in the >> middle of trying to get the GUI to work under GTK# which will >> 'allegedly' allow the code to run on OSX and Linux. >> >> The first applications I want to get support for are SSH and a >> WebPassword manager. The advantage of the latter over existing cloud >> offerings being that it will be auditable. >> >> >> I am also working on hooking up some IoT devices. >> >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > From nobody Tue Apr 5 11:01:47 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4790F12D739 for ; Tue, 5 Apr 2016 11:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CAzauYKJzED for ; Tue, 5 Apr 2016 11:01:43 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED45212D53D for ; Tue, 5 Apr 2016 10:56:06 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id j11so16098626lfb.1 for ; Tue, 05 Apr 2016 10:56:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=EVSjj5hZ/Cva4/GHWlqVr3G3VCF9rv2sfX4KsBE0oKY=; b=oZS+t/cI/JxEOfQeoWe8K5UUU7Vh4o/c7RrWV0eXWf3LU7zw2MIIzw+3BTiLjbSLZt 8EoI/uTCJc1b2aPkD69LOnM87K2vW6OfjgI2Jq9bpfT6zvaahG0Q6qv+ZQSXH/CPhVN1 1zSbsbPjJQrBvT8GE96WB1djO4W22+Rrq+dxZ2GRje9lxBGeqNcZJIrcIWOMlor8k/2f T07QLShb43AuVMalKaUtKTnuIsapP/lFEo0TyPI4fMqTdlsgDBP+L/uECcQE60uNdrsr qQMgy92GIQYpepyK367icQMXgHp190rgba9pz5PrnSDwrTMWZdiuxbT8mWuKN+6k/NSF OvHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=EVSjj5hZ/Cva4/GHWlqVr3G3VCF9rv2sfX4KsBE0oKY=; b=cl8RABgNjLU7IELZhvtFkcMUpHz/WgxDxYYvNkLridYl6JiSPNqDaWkbKXw9rew6pb qnlYPU539jmNnEc9jUaO/IDm9MNlQIqxfIBXasmnhMJUx7SLQf9lT/EiBgQLxJxUmh6d fsaVB7Ors5RBKZYvIx3gEHu1TQPp7uiNK7P3p9CRXJYbXF9eCd9zXjd0cpowahv6o8+y Ol8wGGuHRdz/07xKUtpWEdKWSbldDTktgwDuEpiizgpk/QA360cbEYfnQ8M0I7GqM6MY d3zwA6WE73FeIS9cl7gUK4ZW+1m098YLuk2cSi4Sa/WaxyvUAF8EJz0ypIQcPUkZ2lM3 Vrsg== X-Gm-Message-State: AD7BkJLEmc+MR/1higE0AImEFK2Uq+j55Ul6uRY7CQBYqlYfp5t+Mo26OFk99x1O5g1Ot8z9KSgJW27Cb2v89g== MIME-Version: 1.0 X-Received: by 10.25.205.7 with SMTP id d7mr9000485lfg.70.1459878964757; Tue, 05 Apr 2016 10:56:04 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.151.67 with HTTP; Tue, 5 Apr 2016 10:56:04 -0700 (PDT) In-Reply-To: References: <185E1B6A-C549-45DC-9A59-0BFC3F456805@gmail.com> Date: Tue, 5 Apr 2016 14:56:04 -0300 X-Google-Sender-Auth: 7AfmVBIX6aD8KDoLygbOAu0Pxv4 Message-ID: From: Phillip Hallam-Baker To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "secdir@ietf.org" Subject: Re: [secdir] Paraiso NOT the room we were in for Mesh! 19:10-20:30 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 18:01:45 -0000 OK have confirmed that it is the IESG Breakout Room Pariso on the 5th floor. The one we met in for SECDIR was the IESG breakfast room. On Tue, Apr 5, 2016 at 2:34 PM, Phillip Hallam-Baker wrote: > OK I have checked and I have emails stating both. So I will check with > Stephanie and post a note on the wrong one. > > On Tue, Apr 5, 2016 at 2:17 PM, Yoav Nir wrote: >> Yeah, that would be Atlantico A. >> >> So in which of them is your Bar BoF? >> >>> On 5 Apr 2016, at 2:16 PM, Phillip Hallam-Baker wrote: >>> >>> Sorry, turns out Pariso is NOT the IESG room we were in >>> >>> >>> ---------- Forwarded message ---------- >>> From: Phillip Hallam-Baker >>> Date: Fri, Apr 1, 2016 at 6:19 PM >>> Subject: MESH Bar BOF Tues 19:10-21:00 in the IESG room Paraiso >>> To: "saag@ietf.org" >>> >>> >>> People generally agree that usability is the biggest problem facing us >>> in security. Security that people don't use is useless. >>> >>> The problem is harder than merely making secure applications as easy >>> to use as regular apps. If we are going to change people's behavior, >>> we have to make using the computer easier. Or at least make juggling >>> the many computers, mobiles, IoT devices etc. easy. >>> >>> The Mathematical Mesh is a cryptographic infrastructure that allows a >>> user to create a personal profile and securely connect applications >>> and devices to it. All connections are authenticated bilaterally, end >>> to end and with a direct trust model (no trusted third party >>> required). >>> >>> There is a cloud service involved but it is an untrusted service and >>> the user can switch to another any time they like (like a git >>> repository). >>> >>> The tools are automated on the principle of 'don't give the user >>> instructions that can be replaced by code'. >>> >>> When applications are connected, the user has the option of having the >>> profile management tool add in security. So when you connect Windows >>> Live Mail to a Mesh profile, the profile manager will automatically >>> turn on S/MIME. Right now the certs are self-signed but I am working >>> on getting it hooked up to the Comodo free cert issue. >>> >>> All the code is open source under an MIT license and there are links >>> to the Internet Drafts and the demo videos on the following site: >>> >>> http://cryptomesh.org/ >>> [or http://prismproof.org/] >>> >>> Right now the code has only been tested on Windows. But I am in the >>> middle of trying to get the GUI to work under GTK# which will >>> 'allegedly' allow the code to run on OSX and Linux. >>> >>> The first applications I want to get support for are SSH and a >>> WebPassword manager. The advantage of the latter over existing cloud >>> offerings being that it will be auditable. >>> >>> >>> I am also working on hooking up some IoT devices. >>> >>> _______________________________________________ >>> secdir mailing list >>> secdir@ietf.org >>> https://www.ietf.org/mailman/listinfo/secdir >>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >> From nobody Tue Apr 5 15:48:16 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1797612D11E; Tue, 5 Apr 2016 15:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZXW8TzLs9ZS; Tue, 5 Apr 2016 15:48:09 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10A1B12D0CC; Tue, 5 Apr 2016 15:48:09 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id EB4562002A; Tue, 5 Apr 2016 18:51:37 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0AE796375A; Tue, 5 Apr 2016 18:48:08 -0400 (EDT) From: Michael Richardson To: Chris Lonvick , Nancy Cam-Winget In-Reply-To: <5702F8DE.8000809@gmail.com> References: <5702F8DE.8000809@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: draft-ietf-roll-applicability-ami.all@ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-roll-applicability-ami-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 22:48:11 -0000 --=-=-= Content-Type: text/plain Chris Lonvick 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. Chris thank you for this. > Overall, the document looks great. This is a very information-dense > document and the authors and contributors have done a wonderful job of > putting it together. While I do not follow the technology, I was able > to understand the concepts and I could see that the security > considerations were appropriate. > Some very small nits that the authors may want to consider: > - the terms DODAG, DIO, and DAO are not expanded anywhere. (Yeah, I > know I could go look them up... ;-) They are common terms from RFC6550 which is our core document. Would it work to say that they are from RFC6550 and rfc7102? > - The 2nd paragraph in 9.3 ends with "Known schemes". I figure someone > was going to write something more there. seems like an edit error. Nancy? -- Michael Richardson , Sandelman Software Works IETF ROLL WG outgoing co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVwRApYCLcPvd0N1lAQISZQgAgbGknI8SIvcv4JUSjVYfVOQ1lTXfSGqJ uD9JLLuV7DBJaqlUfTrMuxZkUsc7aNlBlUpnQp1cqExcXlvxmtD8oi+XD1M3FuKj Q5L0WAR8dD2AuAGcQgE6HLb/Jme5cjMequjCH9e9RV6k2hOnMe+B8ZjysM6MV/nW X3R9ns7L2zW5dJXIdr82Dt/WIPh6H7EIvqwxys+s4fBqf0hX9MZ1ZEFwWsnY8hTo MMdrq3emuW/Nu28ZtrpQlvD+qSY61QXLCEAoFPth5eOy0+3860kELGrs7y6SPBww BtGME9fKXYBus0sPjp4JNWeMuX5vqfN//RlYSbEbWbMKfu3+BrnkZA== =Fthn -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Apr 6 04:16:06 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A3112D7BC for ; Wed, 6 Apr 2016 04:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfMJsnAHqYOG for ; Wed, 6 Apr 2016 04:15:58 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF75B12D7D6 for ; Wed, 6 Apr 2016 04:15:50 -0700 (PDT) Received: by mail-lb0-x232.google.com with SMTP id u8so27540225lbk.0 for ; Wed, 06 Apr 2016 04:15:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=5YRucDUJIOmO6ZYjaEglBZQD4oNabUsrzLv6z+awgt8=; b=yu81RydjK1SlCQeHVVUDg2gzUAlPW7i23DdIehty8Oj/qpcn6R9E86Xfm4HglRXFZZ 3QBk4LP9PM3mCMSpeZhFZ0lqj6GBPL0f3jr+wOBMgY1TNxZ0htadsVOufn/L4G1mBq+4 bEoXkcXGuvFYSHVOdT3eQNK2ibC9ELMC6Mz5ihowHE1qfqxO1JjKaqrryCeNWzZOFXr5 x8MmG3uxGETlWqZqgshFM5FZ2McTD4AR+20CfpFVGKw5R0eVtyeCVlD8301Ys3KSwk30 s2MFTD+Pve4QpKDiPBicPzdYkjvUQRJV27aPkck4K1GvSNq9JoF0yRYqhyT6z92dYuqt 00ug== 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; bh=5YRucDUJIOmO6ZYjaEglBZQD4oNabUsrzLv6z+awgt8=; b=GVyDFkZdMJUXMi0Oat89kzMf5Km25Qhv1caDCCHJ1UKii6ztv7Tvn+3+o3jEo8ibvQ IxyNFC8cIMZo+eQekgzYE2krCkKPUQYcHrtphdyj5iZmu24jUYfc53N2koeEh7O7S5+n 3zI/K4xdp0JhGonlHagMNU1TSId1zyk+zUp/dYreFrEYGxh2gylL0hm5aAgIZJ4dQvBV YGz5ZlfWEuOUQ8MkgbuFaeMFJ8X3K3whNL67Cq0S+Wu465etjpszVQple3dHNcxERds2 UNrnAMJI809v8WcrrJUfN9d/pv0ocbCAfb6oaXxJPkVoO5nPnbbEIvA2kvqIJNCCoh+0 zzYw== X-Gm-Message-State: AD7BkJKjhQCFtCF3PQQC+V/p494HtfptunjbApyoAHzuURAoFOv+X/BOMuEIbV6g7bhHRjtVJ9bhPZo74xEL+g== MIME-Version: 1.0 X-Received: by 10.112.147.101 with SMTP id tj5mr5829762lbb.119.1459941348914; Wed, 06 Apr 2016 04:15:48 -0700 (PDT) Received: by 10.112.135.97 with HTTP; Wed, 6 Apr 2016 04:15:48 -0700 (PDT) In-Reply-To: <56F3FFE0.3040408@cisco.com> References: <6AAFCD6E-4F8D-409C-ACB1-53C03413AF7F@gmail.com> <56F3FFE0.3040408@cisco.com> Date: Wed, 6 Apr 2016 04:15:48 -0700 Message-ID: From: Andy Bierman To: Benoit Claise Content-Type: multipart/alternative; boundary=047d7b3a8bd27ecf70052fcf1540 Archived-At: Cc: Mahesh Jethanandani , draft-ietf-netconf-yang-library.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-netconf-yang-library-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 11:16:02 -0000 --047d7b3a8bd27ecf70052fcf1540 Content-Type: text/plain; charset=UTF-8 Hi, Here is the proposed text: OLD: o /modules-state/module: The module list used in a server implementation may help an attacker identify the server capabilities and server implementations with known bugs. Server vulnerabilities may be specific to particular modules, module revisions, module features, or even module deviations. This information is included in each module entry. ... NEW: o /modules-state/module: The module list used in a server implementation may help an attacker identify the server capabilities and server implementations with known bugs. Although some of this information may be available to all users via the NETCONF message (or similar messages in other management protocols), this YANG module potentially exposes additional details that could be of some assistance to an attacker. Server vulnerabilities may be specific to particular modules, module revisions, module features, or even module deviations. This information is included in each module entry. ... If this is acceptable, I will post a -05 version. Andy On Thu, Mar 24, 2016 at 7:55 AM, Benoit Claise wrote: > On 3/23/2016 9:30 PM, Andy Bierman wrote: > > > > On Wed, Mar 23, 2016 at 12:39 PM, Tom Yu wrote: > >> Andy Bierman writes: >> >> > The YANG library provides the revision date of the deviations module, >> > which is not included in the NETCONF . >> > >> > It also lists the submodules and their revisions, which is >> > not contained in the NETCONF . >> > >> > The NETCONF message is not specified well enough to >> > make any other generalizations about the differences. >> >> I think it would be good to explicitly mention that the YANG library >> provides a superset of the module and version information that might be >> available by other means, e.g., >> >> OLD >> >> Some of the readable data nodes in this YANG module may be considered >> sensitive or vulnerable in some network environments. It is thus >> important to control read access (e.g., via get, get-config, or >> notification) to these data nodes. These are the subtrees and data >> nodes and their sensitivity/vulnerability: >> >> NEW >> >> Some of the readable data nodes in this YANG module may be considered >> sensitive or vulnerable in some network environments and >> authorization configurations. Although some of this information may >> be available to all users via the NETCONF message (or similar >> messages in other management protocols), this YANG module potentially >> exposes additional details that could be of some assistance to an >> attacker. It is thus important to control read access (e.g., via >> get, get-config, or notification) to these data nodes. These are the >> subtrees and data nodes and their sensitivity/vulnerability: >> >> > > > This is the security boilterplate text that is supposed to > go into every YANG module > > > https://tools.ietf.org/html/rfc6087#section-6.1 > > > I prefer to leave the boilerplate alone and move your text into > YANG library specific part. > > I would support this. > > Regards, Benoit > > > > Andy > > > >> I think if NETCONF access is restricted to a small number of trusted >> users (even for read-only access), the incremental risk posed by >> revealing more details about the modules is small. I imagine that there >> are use cases for providing (restricted) read-only NETCONF access to a >> wider, mostly untrusted population, in which case the detailed module >> version information provided by the YANG library could constitute a >> non-trivial additional risk. I'm not sure of a good, concise way to >> express this. >> >> > The library is intended for other protocols such as RESTCONF. >> > >> > Is there some specific text you want changed? >> >> I think there could be ambiguity about whether "server" refers to the >> NETCONF (or other management protocol) server process on the device, or >> to the overall capabilities of the device. If the YANG library could >> provide details that could reveal to an attacker the existence of >> vulnerabilities in the underlying network device capabilities, it might >> be good to mention it, e.g., >> >> In addition to revealing the potential existence of vulnerabilities >> in the network management protocol server on a device, the detailed >> version information available in the module list could help an >> attacker to discover the existence of vulnerable code in the >> implementation of the underlying network capabilities (or other >> functionality) of the device on which the management server is >> running. >> > > > --047d7b3a8bd27ecf70052fcf1540 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Here is the proposed tex= t:


OLD:

=C2=A0 =C2=A0o =C2= =A0/modules-state/module: The module list used in a server
=C2=A0 =C2=A0= =C2=A0 implementation may help an attacker identify the server
=C2=A0 = =C2=A0 =C2=A0 capabilities and server implementations with known bugs.=C2= =A0 Server
=C2=A0 =C2=A0 =C2=A0 vulnerabilities may be specific to parti= cular modules, module
=C2=A0 =C2=A0 =C2=A0 revisions, module features, o= r even module deviations.=C2=A0 This
=C2=A0 =C2=A0 =C2=A0 information is= included in each module entry. ...

NEW:

<= /div>
=C2=A0 =C2=A0o =C2=A0/modules-state/module: The module list = used in a server
=C2=A0 =C2=A0 =C2=A0 implementation may help an = attacker identify the server
=C2=A0 =C2=A0 =C2=A0 capabilities an= d server implementations with known bugs.=C2=A0 Although
=C2=A0 = =C2=A0 =C2=A0 some of this information may be available to all users via th= e
=C2=A0 =C2=A0 =C2=A0 NETCONF <hello> message (or similar = messages in other management
=C2=A0 =C2=A0 =C2=A0 protocols), thi= s YANG module potentially exposes additional
=C2=A0 =C2=A0 =C2=A0= details that could be of some assistance to an attacker.=C2=A0 Server
=C2=A0 =C2=A0 =C2=A0 vulnerabilities may be specific to particular mo= dules, module
=C2=A0 =C2=A0 =C2=A0 revisions, module features, or= even module deviations.=C2=A0 This
=C2=A0 =C2=A0 =C2=A0 informat= ion is included in each module entry. ...

If this is acceptable, I will post a -05 version.

Andy


On Thu, Mar 24, 2016 at 7:55 AM, = Benoit Claise <bclaise@cisco.com> wrote:
=20 =20 =20
On 3/23/2016 9:30 PM, Andy Bierman wrote:
=20


On Wed, Mar 23, 2016 at 12:39 PM, Tom Yu <tlyu@mit.edu> wrote:
Andy Bierman <andy@yumaworks.com> writes:

> The YANG library provides the revision date of the deviations module,
> which is not included in the NETCONF <hello>.
>
> It=C2=A0 also lists the submodules and their revisions, which is
> not contained in the NETCONF <hello>.
>
> The NETCONF <hello> message is not specified well enough to
> make any other generalizations about the differences.
I think it would be good to explicitly mention that the YANG library
provides a superset of the module and version information that might be
available by other means, e.g.,

OLD

=C2=A0 =C2=A0Some of the readable data nodes in this YANG mod= ule may be considered
=C2=A0 =C2=A0sensitive or vulnerable in some network environm= ents.=C2=A0 It is thus
=C2=A0 =C2=A0important to control read access (e.g., via get, get-config, or
=C2=A0 =C2=A0notification) to these data nodes.=C2=A0 These a= re the subtrees and data
=C2=A0 =C2=A0nodes and their sensitivity/vulnerability:

NEW

=C2=A0 =C2=A0Some of the readable data nodes in this YANG mod= ule may be considered
=C2=A0 =C2=A0sensitive or vulnerable in some network environm= ents and
=C2=A0 =C2=A0authorization configurations.=C2=A0 Although som= e of this information may
=C2=A0 =C2=A0be available to all users via the NETCONF <he= llo> message (or similar
=C2=A0 =C2=A0messages in other management protocols), this YA= NG module potentially
=C2=A0 =C2=A0exposes additional details that could be of some assistance to an
=C2=A0 =C2=A0attacker.=C2=A0 It is thus important to control = read access (e.g., via
=C2=A0 =C2=A0get, get-config, or notification) to these data = nodes.=C2=A0 These are the
=C2=A0 =C2=A0subtrees and data nodes and their sensitivity/vulnerability:




This is the security boilterplate text that is supposed to
go into every YANG module


https://tools.ietf.org/html/rfc6087#section-6.1


I prefer to leave the boilerplate alone and move your text into
YANG library specific part.
I would support this.

Regards, Benoit


Andy

=C2=A0
I think if NETCONF access is restricted to a small number of trusted
users (even for read-only access), the incremental risk posed by
revealing more details about the modules is small.=C2=A0 I imagine that there
are use cases for providing (restricted) read-only NETCONF access to a
wider, mostly untrusted population, in which case the detailed module
version information provided by the YANG library could constitute a
non-trivial additional risk.=C2=A0 I'm not sure of a good= , concise way to
express this.

> The library is intended for other protocols such as RESTCONF.
>
> Is there some specific text you want changed?

I think there could be ambiguity about whether "server&q= uot; refers to the
NETCONF (or other management protocol) server process on the device, or
to the overall capabilities of the device.=C2=A0 If the YANG library could
provide details that could reveal to an attacker the existence of
vulnerabilities in the underlying network device capabilities, it might
be good to mention it, e.g.,

=C2=A0 =C2=A0 In addition to revealing the potential existenc= e of vulnerabilities
=C2=A0 =C2=A0 in the network management protocol server on a = device, the detailed
=C2=A0 =C2=A0 version information available in the module lis= t could help an
=C2=A0 =C2=A0 attacker to discover the existence of vulnerabl= e code in the
=C2=A0 =C2=A0 implementation of the underlying network capabi= lities (or other
=C2=A0 =C2=A0 functionality) of the device on which the manag= ement server is
=C2=A0 =C2=A0 running.



--047d7b3a8bd27ecf70052fcf1540-- From nobody Wed Apr 6 08:37:24 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB1F12D11F for ; Wed, 6 Apr 2016 08:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 QOivV1nSjFgN for ; Wed, 6 Apr 2016 08:37:19 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D47812D0FE for ; Wed, 6 Apr 2016 08:37:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E85F7BE33 for ; Wed, 6 Apr 2016 16:37:17 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaZrKGXxYh1S for ; Wed, 6 Apr 2016 16:37:16 +0100 (IST) Received: from [31.133.178.21] (dhcp-b215.meeting.ietf.org [31.133.178.21]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A50BABE2D for ; Wed, 6 Apr 2016 16:37:15 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1459957036; bh=TeeOSp1Y+80P4HmmyfQCOMWwHUn1J8BX4SMdthvWr7c=; h=To:From:Subject:Date:From; b=AonPuGg6EEDw0NhZPYiRuRVQTxqT8PTyaQ3s/9qt4s3nbepqdPWXTTozJU+6invi3 YQbXkb1zd3dybDhS27sk13+gU8hqGG0q7NYL/RemSVwuhi6w08YhU7lEV8Dd5TtQkq 22IWSnRIwuWvfXoO6glZhzSKfXGdKWTyRz8Dv47I= To: "secdir@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <57052D23.8070801@cs.tcd.ie> Date: Wed, 6 Apr 2016 16:37:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000803060304010505010204" Archived-At: Subject: [secdir] trill overview at routing area open meeting today X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 15:37:22 -0000 This is a cryptographically signed message in MIME format. --------------ms000803060304010505010204 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all (except Don:-), I tend to find trill documents a bit of a challenge to review because of my own ignorance. If you do too, then there's going to be an overview presentation at the routing area meeting [1] today that Alia tells me might be useful for secdir reviewers. So if you have time and interest, you might want to pop along to that. Cheers, S. [1] https://tools.ietf.org/agenda/95/agenda-95-rtgarea.html --------------ms000803060304010505010204 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA0MDYx NTM3MDdaMC8GCSqGSIb3DQEJBDEiBCCSv+SUeHzK2p2CFVg6KUrfuft0pgrcg7rFMokX9ILe cDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAXzMApM06cPZOJu1a6r7WG7NBqo6kV4S0qmuKe7sdZYwjiiXq89Muk MMFYdrXyl4uAgh6qxoIdRjI2sU0dJe09JbH24zlulaxV/Cx81nYFoMpOoloJP6NvzwELJVls 4wqwmBx/B+ZSJ54FiUEVxqhzgaBExXgWG2kWkVPlzGQamkVUgJDdZPtAJkEIctFgVmyUter9 q5ZliNaM1a/jk0Yfbfz07otAG0xPjdpCfDD0zkhMIROmIOgH5GdxzOUlupvvvVPOV7cOZjP6 Lnswb7DbubuA78sOEXEDeNBO5Z3PHJBjZ77LTFQ+wvyMWLo1Knt1MujcVuEc+QSf8ewFOxew AAAAAAAA --------------ms000803060304010505010204-- From nobody Thu Apr 7 07:16:42 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 042FD12D509; Thu, 7 Apr 2016 07:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DN2uHH_dB6G; Thu, 7 Apr 2016 07:16:30 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 447BE12D11E; Thu, 7 Apr 2016 07:16:21 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id f198so27545288wme.0; Thu, 07 Apr 2016 07:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=OGm9FawcCOXJ8KKaaMB/J3+zFMRN4ogtBityMlMeuCU=; b=Q0/oU25aNvx50Zf+xf6WnB/Sg7mgUoT4EOeav/x12u9cxdn5CZSUUJ2v2jocShPzP2 6RsezXeStbtWnVca+7ZI30CvQxkZrO8TptApfcjT9mygumStoXbUbzajtNgrcK2P1NIA //hlcuUAtdynhkybVCvpkFwwmEufSM69Fn63V2FW/ohwr65XYDKs7vZvVaTrkNurCykz iXS7FKwDrlL2obAzawfRl5Nbg7TYNNJsZgleHmJJ9B8hkihnJCFE+15Wz8n7AZam13gd nEJZEsImLLopKpxbWT0Sq2Ag1pZYk3dlEHhVKIbWcw629DKNnpscIVZFPVGmTac8zuhS OfFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=OGm9FawcCOXJ8KKaaMB/J3+zFMRN4ogtBityMlMeuCU=; b=FBtjj2DxtG856ormxyum6asKA1JWfPZ3DoBA8Vc4LmvH4OAnBn0Dwa7yZSigGJ6+2H 5NU4GXLAgPv5fEo/DzXbkYNeuzXkiDNuiR0RZIe7qJRUNn0qvO7ylHJ6hyaqmrZUhLpQ Iy21vQMcJId4v4upk2/KPRYP2OPT8ZyyWxFSSHelZFJdysrcdTKVCedKqwjeriyFRwHJ 6DHreKx6oX7FtlS9i+Xp47BZZy4/me133j9d8uRrSh5Etbl4UXLeJtetdHnZsMc0MkHX TzRDHLLowf5/4W/9dfIwqR+CuNc3rP9hJ36a5XrjQzFyZjl48SxMIde97KYJKklcAQEr RAOA== X-Gm-Message-State: AD7BkJKwtngVQs2jZP/ctTqQxdCk4wDGvSHw8J0Jm+UiY+s9v+In2GEmESBEra1YQ2uoyQ== X-Received: by 10.28.11.131 with SMTP id 125mr30784815wml.58.1460038579755; Thu, 07 Apr 2016 07:16:19 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id w193sm3506495wmd.0.2016.04.07.07.16.18 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2016 07:16:18 -0700 (PDT) To: Sandra Murphy , secdir@ietf.org, The IETF , draft-ietf-mpls-rfc6374-udp-return-path.all@tools.ietf.org References: <07A977A4-FD9E-4669-A8D0-7644131E06AD@tislabs.com> <5673D89F.7090409@gmail.com> From: Stewart Bryant Message-ID: <57066BB0.6060600@gmail.com> Date: Thu, 7 Apr 2016 15:16:16 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <5673D89F.7090409@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-mpls-rfc6374-udp-return-path X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 14:16:32 -0000 On 18/12/2015 09:57, Stewart Bryant wrote: Sandy, I have looked at this discussion again. Please see inline: > >> >> Section 4.2 >> >> >> If an Out-of-band response is requested and the Address object or the >> URO is missing, the query SHOULD be dropped in the case of a >> unidirectional LSP. If both these TLVs are missing on a >> bidirectional LSP, the control code of Response message should set to >> 0x1C indicating "Error - Invalid Message" ([RFC6374] Section 3.1) and >> the response SHOULD be sent over the reverse LSP. The receipt of >> such a mal-formed request SHOULD be notified to the operator through >> the management system, taking the normal precautions with respect to >> the prevention of overload of the error reporting system. >> >> The first sentence says that both the Address object and the URO must >> be present or the query is dropped - right? I'm reading this as >> >> (if not(Address) OR not(URO)) then drop. >> >> What Address object - there are three - Return, Source and >> Destination. I'm betting on Return, but the text should be clear. > > That is return address - I will update the text. Looking at the text again, since we are ONLY talking about systems using the URO, the Address object text fragment is pointless so I have deleted it. > > >> >> The RFC6374 out-of-band response feature and the "Return Address" >> object seem to indicate the potential exists in RFC6374 as well. >> RFC6374's security consideration section does not mention the >> reflection attack possibility, only the integrity of the return >> out-of-band path and the possibility of affecting the validity of the >> measurements. But even if the assumptions of well-managed, private, >> service provider networks are met, I believe that the potential and >> increased need for careful configuration should be mentioned. "Note: >> the feature can be misused, so take care". Perhaps a manageability >> section caution about checking the Return Address or URO to ensure >> addresses are within the private or service provider network. >> something? Or presume all will be well, because this is to be used in >> well managed private and service provider networks? > I will look at adding some text, although the assumption is that > MPLS networks are well managed, and there are many other ways > they would break if they were not. > This text is only about the URO case. The only residual text on the DA obj is in the section that is to be deleted. - Stewart From nobody Thu Apr 7 07:42:39 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D81312D8A9 for ; Thu, 7 Apr 2016 07:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaiWGn5gZgNX for ; Thu, 7 Apr 2016 07:42:36 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D45F012D9A1 for ; Thu, 7 Apr 2016 07:28:01 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u37ERx6K004148 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 7 Apr 2016 17:27:59 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u37ERx2b002953; Thu, 7 Apr 2016 17:27:59 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22278.28271.439659.924226@fireball.acr.fi> Date: Thu, 7 Apr 2016 17:27:59 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 14:42:38 -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 2016-04-21 Reviewer LC end Draft Shaun Cooley T 2016-03-29 draft-ietf-pce-iro-update-06 Donald Eastlake TR2016-02-22 draft-ietf-dane-openpgpkey-08 Steve Hanna T 2016-04-11 draft-ietf-pim-hierarchicaljoinattr-06 Jeffrey Hutzelman T 2015-12-04 draft-ietf-core-block-19 Leif Johansson T 2016-04-06 draft-ietf-p2psip-sip-17 Joe Salowey T 2016-03-09 draft-ietf-rtcweb-audio-codecs-for-interop-05 Carl Wallace T 2016-03-30 draft-schoenw-opsawg-copspr-historic-03 Liang Xia T 2016-04-08 draft-alakuijala-brotli-08 For telechat 2016-05-05 Donald Eastlake T 2016-04-13 draft-ietf-bess-multicast-damping-04 Shawn Emery T 2016-04-12 draft-ietf-bfd-seamless-base-08 Daniel Kahn Gillmor T 2016-04-12 draft-ietf-bfd-seamless-ip-03 Tobias Gondrom T 2016-04-12 draft-ietf-bfd-seamless-use-case-04 Christian Huitema T 2016-04-13 draft-ietf-bess-pta-flags-02 Chris Inacio T 2016-05-03 draft-ietf-ospf-sbfd-discriminator-03 Benjamin Kaduk T 2016-05-03 draft-ietf-rtcweb-alpn-03 Eric Osterweil T 2016-01-05 draft-campbell-art-rfc5727-update-03 Yaron Sheffer T 2016-03-09 draft-ietf-v6ops-host-addr-availability-06 Sam Weiler T 2016-03-18 draft-ietf-avtext-sdes-hdr-ext-05 Dacheng Zhang T 2016-03-28 draft-ietf-grow-route-leak-problem-definition-04 Last calls and special requests: Alan DeKok 2016-04-30 draft-bradner-rfc3979bis-08 Daniel Kahn Gillmor E 2016-02-01 draft-ietf-rtcweb-security-08 Phillip Hallam-Baker 2016-04-05 draft-ietf-pals-seamless-vccv-02 Charlie Kaufman 2016-04-20 draft-ietf-tls-falsestart-01 Hannes Tschofenig 2015-12-28 draft-ietf-hip-rfc5204-bis-07 Hannes Tschofenig E None draft-ietf-ntp-network-time-security-13 Hannes Tschofenig E None draft-ietf-ntp-cms-for-nts-message-06 Hannes Tschofenig E None draft-ietf-ntp-using-nts-for-ntp-04 Brian Weis E 2016-02-01 draft-ietf-cdni-uri-signing-07 Tom Yu 2016-03-24 draft-ietf-dime-drmp-04 -- kivinen@iki.fi From nobody Thu Apr 7 08:50:30 2016 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 30BA212D991; Thu, 7 Apr 2016 08:11:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1460041888; bh=rpirthMZ8K1URo+dpIN2fQ8IyWgnCVwB0qq1FAfbP8Q=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=jBO4tPKwN9qF8mLGgiscnzDAmm/86Rit11NOOBW7TGrDBE0wXU8eY4QMEcUEjDkpG /uKk+kM1aIbLLPlv//UfaQzTtRZ+iDx/HkR/JcePqmKAIiBl6IF73FAhw2dWB035FA R5FqBmjvdGhoE1x09It9jLAQbKgMRfLJQxVPPWz4= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC22C12D97A for ; Thu, 7 Apr 2016 08:11:20 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Reply_to: Message-ID: <20160407151120.19792.22392.idtracker@ietfa.amsl.com> Date: Thu, 07 Apr 2016 08:11:20 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.17 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Thu, 07 Apr 2016 08:50:28 -0700 Subject: [secdir] [new-work] WG Review: Locator/ID Separation Protocol (lisp) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 15:11:36 -0000 The Locator/ID Separation Protocol (lisp) WG in the Routing Area of the IETF is undergoing rechartering. 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@ietf.org) by 2016-04-18. Locator/ID Separation Protocol (lisp) ----------------------------------------------------------------------- Current status: Active WG Chairs: Joel Halpern Luigi Iannone Secretaries: Damien Saucez Wassim Haddad Assigned Area Director: Deborah Brungard Routing Area Directors: Alia Atlas Alvaro Retana Deborah Brungard Mailing list: Address: lisp@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/lisp Archive: https://mailarchive.ietf.org/arch/browse/lisp/ Charter: https://datatracker.ietf.org/doc/charter-ietf-lisp/ The LISP WG has completed the first set of Experimental RFCs describing the Locator/ID Separation Protocol (LISP). LISP supports a routing architecture which decouples the routing locators and identifiers, thus allowing for efficient aggregation of the routing locator space and providing persistent identifiers in the identifier space. LISP requires no changes to end-systems or to routers that do not directly participate in the LISP deployment. LISP aims for an incrementally deployable protocol. The scope of the LISP technology is potentially applicable to have a large span, including unicast and multicast overlays at Layer 2 as well as at Layer 3, encompassing NAT traversal, VPNs, and supporting mobility as a general feature, independently of whether it is a mobile user or a migrating Virtual Machine (VM). Hence, the LISP technology is applicable in both Data Centers and public Internet environments. The LISP WG is chartered to continue work on the LISP base protocol and produce standard-track documents (unless the content of the document itself is of a different type, e.g., informational or experimental). In order to produce a coherent set of documents, the first (and high priority) work item of the LISP Working Group is to develop a standard-track solution based on the completed Experimental RFCs and the experience gained from early deployments. This work will include reviewing the existing set of Experimental RFCs and doing the necessary enhancements to support a base set of standards track RFCs. The group will review the current set of Working Group documents to identify potential standards-track documents and do the necessary enhancements to support standards-track. In parallel with the previous main work item, the LISP WG will work on the items listed below: - Multi-protocol support: Specifying the required extensions to support multi-protocol encapsulation (e.g., L2 or NSH (Network Service Headers). Rather than developing new encapsulations the work will aim at using existing well-established encapsulations or emerging from other Working Groups such as NVO3 and SFC. - Alternative Mapping System Design: By extending LISP with new multi-protocols support, it becomes necessary to develop the required mapping function and control plane extensions to operate LISP map-assisted networks (which might include Hierarchical Pull, Publish/Subscribe, or Push models, independent mapping systems interconnection, security extensions, or alternative transports of the LISP control protocol). - Mobility: Some LISP deployment scenarios include mobile nodes (in mobile environments) or Virtual Machines (VMs in data centers), hence, support needs to be provided in order to achieve seamless connectivity. This work item may benefit from experience of other Working Groups like DMM (Distributed Mobility Management) or NVO3 (for VM migration). - Multicast: Support for overlay multicast by means of replication as well as interfacing with existing underlay multicast support. This may need discussion with other Working Groups related to multicast solutions (e.g. PIM). - Data-Plane Encryption: In some scenarios, it may be desirable to encrypt LISP encapsulated traffic. In this case, the data-plane encryption mechanism itself and support for control-plane security material exchange needs to be specified. Any solution proposed in this work item has to be reviewed by security experts. - NAT-Traversal: Support for NAT-traversal solution in deployments where LISP tunnel routers are separated from correspondent tunnel routers by a NAT (e.g., LISP mobile node). - Models for managing the LISP protocol and deployments that include data models, as well as allowing for programmable management interfaces. These management methods should be considered for both the data-plane, control plane, and mapping system components of standards-track documents. Documents of these work items will as well target standard-track unless the main content of the document itself clearly demands for a different type (e.g., informational or experimental). In the latter case the Working Group needs to determine the proper document class. Collaboration with other working groups, as stated in the different work items (e.g., PIM, NVO3, DMM, SFC), is important to ensure to have technologies that work smoothly together. The LISP Working Group is chartered to work on the LISP technology, and only use solutions/technology developed in other working groups. The LISP Working Group may provide feedback to other working groups based on experience gained while using their solutions. Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Thu Apr 7 12:31:11 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C0C12D0EF; Thu, 7 Apr 2016 12:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.481 X-Spam-Level: X-Spam-Status: No, score=-13.481 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSZKtRXlgBOs; Thu, 7 Apr 2016 12:31:07 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76E3812D0BA; Thu, 7 Apr 2016 12:31:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18507; q=dns/txt; s=iport; t=1460057467; x=1461267067; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=RGtFypzpTrqU2SryRkZHChEWWh4AtIfwcOWPa7tR4K4=; b=NZ3AHm2BAsafmZ2+L/ynOBQis0M1wrzgr9Feh4af98YeVV/sU/GK+35f bT5ebElZzw3mYi//Yt7IpUf5XLwMQUJ9qdjGjOuoWEbj5gvjfFHL93OzW AYkge863mMtSCtzp8bLrO+de0TM32fnPE6BcMFOKKohCOw+dhrMLY+l+3 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaAgBVtAZX/4YNJK1TCoM3U326QwENg?= =?us-ascii?q?XMhhWwCgUU4FAEBAQEBAQFlJ4RBAQEBAwEjVQEFCwsYCRYIAwICCQMCAQIBNBE?= =?us-ascii?q?GDAEGAgEBiBsIDq9okX0BAQEBAQEBAQEBAQEBAQEBAQEBAQERBIYhhEuEFRKDG?= =?us-ascii?q?IJWBZMZhGuFd4gVgWeHUiOFMo8kHgEBQoQBIjABiTgBAQE?= X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208,217";a="257939009" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Apr 2016 19:31:05 +0000 Received: from [10.24.90.81] ([10.24.90.81]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u37JUwiO013774; Thu, 7 Apr 2016 19:30:59 GMT To: Andy Bierman References: <6AAFCD6E-4F8D-409C-ACB1-53C03413AF7F@gmail.com> <56F3FFE0.3040408@cisco.com> From: Benoit Claise Message-ID: <5705C32C.2010200@cisco.com> Date: Wed, 6 Apr 2016 23:17:16 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------080201010401070606030905" Archived-At: Cc: Mahesh Jethanandani , draft-ietf-netconf-yang-library.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-netconf-yang-library-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 19:31:11 -0000 This is a multi-part message in MIME format. --------------080201010401070606030905 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Andy, I believe it works. Regards, Benoit > Hi, > > Here is the proposed text: > > > OLD: > > o /modules-state/module: The module list used in a server > implementation may help an attacker identify the server > capabilities and server implementations with known bugs. Server > vulnerabilities may be specific to particular modules, module > revisions, module features, or even module deviations. This > information is included in each module entry. ... > > NEW: > > o /modules-state/module: The module list used in a server > implementation may help an attacker identify the server > capabilities and server implementations with known bugs. Although > some of this information may be available to all users via the > NETCONF message (or similar messages in other management > protocols), this YANG module potentially exposes additional > details that could be of some assistance to an attacker. Server > vulnerabilities may be specific to particular modules, module > revisions, module features, or even module deviations. This > information is included in each module entry. ... > > > If this is acceptable, I will post a -05 version. > > > Andy > > > On Thu, Mar 24, 2016 at 7:55 AM, Benoit Claise > wrote: > > On 3/23/2016 9:30 PM, Andy Bierman wrote: >> >> >> On Wed, Mar 23, 2016 at 12:39 PM, Tom Yu > > wrote: >> >> Andy Bierman > >> writes: >> >> > The YANG library provides the revision date of the >> deviations module, >> > which is not included in the NETCONF . >> > >> > It also lists the submodules and their revisions, which is >> > not contained in the NETCONF . >> > >> > The NETCONF message is not specified well enough to >> > make any other generalizations about the differences. >> >> I think it would be good to explicitly mention that the YANG >> library >> provides a superset of the module and version information >> that might be >> available by other means, e.g., >> >> OLD >> >> Some of the readable data nodes in this YANG module may be >> considered >> sensitive or vulnerable in some network environments. It >> is thus >> important to control read access (e.g., via get, >> get-config, or >> notification) to these data nodes. These are the subtrees >> and data >> nodes and their sensitivity/vulnerability: >> >> NEW >> >> Some of the readable data nodes in this YANG module may be >> considered >> sensitive or vulnerable in some network environments and >> authorization configurations. Although some of this >> information may >> be available to all users via the NETCONF message >> (or similar >> messages in other management protocols), this YANG module >> potentially >> exposes additional details that could be of some >> assistance to an >> attacker. It is thus important to control read access >> (e.g., via >> get, get-config, or notification) to these data nodes. >> These are the >> subtrees and data nodes and their sensitivity/vulnerability: >> >> >> >> >> This is the security boilterplate text that is supposed to >> go into every YANG module >> >> >> https://tools.ietf.org/html/rfc6087#section-6.1 >> >> >> I prefer to leave the boilerplate alone and move your text into >> YANG library specific part. > I would support this. > > Regards, Benoit >> >> >> Andy >> >> I think if NETCONF access is restricted to a small number of >> trusted >> users (even for read-only access), the incremental risk posed by >> revealing more details about the modules is small. I imagine >> that there >> are use cases for providing (restricted) read-only NETCONF >> access to a >> wider, mostly untrusted population, in which case the >> detailed module >> version information provided by the YANG library could >> constitute a >> non-trivial additional risk. I'm not sure of a good, concise >> way to >> express this. >> >> > The library is intended for other protocols such as RESTCONF. >> > >> > Is there some specific text you want changed? >> >> I think there could be ambiguity about whether "server" >> refers to the >> NETCONF (or other management protocol) server process on the >> device, or >> to the overall capabilities of the device. If the YANG >> library could >> provide details that could reveal to an attacker the existence of >> vulnerabilities in the underlying network device >> capabilities, it might >> be good to mention it, e.g., >> >> In addition to revealing the potential existence of >> vulnerabilities >> in the network management protocol server on a device, >> the detailed >> version information available in the module list could >> help an >> attacker to discover the existence of vulnerable code in the >> implementation of the underlying network capabilities (or >> other >> functionality) of the device on which the management >> server is >> running. >> >> > > --------------080201010401070606030905 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Andy,

I believe it works.

Regards, Benoit
Hi,

Here is the proposed text:


OLD:

   o  /modules-state/module: The module list used in a server
      implementation may help an attacker identify the server
      capabilities and server implementations with known bugs.  Server
      vulnerabilities may be specific to particular modules, module
      revisions, module features, or even module deviations.  This
      information is included in each module entry. ...

NEW:

   o  /modules-state/module: The module list used in a server
      implementation may help an attacker identify the server
      capabilities and server implementations with known bugs.  Although
      some of this information may be available to all users via the
      NETCONF <hello> message (or similar messages in other management
      protocols), this YANG module potentially exposes additional
      details that could be of some assistance to an attacker.  Server
      vulnerabilities may be specific to particular modules, module
      revisions, module features, or even module deviations.  This
      information is included in each module entry. ...


If this is acceptable, I will post a -05 version.


Andy


On Thu, Mar 24, 2016 at 7:55 AM, Benoit Claise <bclaise@cisco.com> wrote:
On 3/23/2016 9:30 PM, Andy Bierman wrote:


On Wed, Mar 23, 2016 at 12:39 PM, Tom Yu <tlyu@mit.edu> wrote:
Andy Bierman <andy@yumaworks.com> writes:

> The YANG library provides the revision date of the deviations module,
> which is not included in the NETCONF <hello>.
>
> It  also lists the submodules and their revisions, which is
> not contained in the NETCONF <hello>.
>
> The NETCONF <hello> message is not specified well enough to
> make any other generalizations about the differences.

I think it would be good to explicitly mention that the YANG library
provides a superset of the module and version information that might be
available by other means, e.g.,

OLD

   Some of the readable data nodes in this YANG module may be considered
   sensitive or vulnerable in some network environments.  It is thus
   important to control read access (e.g., via get, get-config, or
   notification) to these data nodes.  These are the subtrees and data
   nodes and their sensitivity/vulnerability:

NEW

   Some of the readable data nodes in this YANG module may be considered
   sensitive or vulnerable in some network environments and
   authorization configurations.  Although some of this information may
   be available to all users via the NETCONF <hello> message (or similar
   messages in other management protocols), this YANG module potentially
   exposes additional details that could be of some assistance to an
   attacker.  It is thus important to control read access (e.g., via
   get, get-config, or notification) to these data nodes.  These are the
   subtrees and data nodes and their sensitivity/vulnerability:




This is the security boilterplate text that is supposed to
go into every YANG module




I prefer to leave the boilerplate alone and move your text into
YANG library specific part.
I would support this.

Regards, Benoit


Andy

 
I think if NETCONF access is restricted to a small number of trusted
users (even for read-only access), the incremental risk posed by
revealing more details about the modules is small.  I imagine that there
are use cases for providing (restricted) read-only NETCONF access to a
wider, mostly untrusted population, in which case the detailed module
version information provided by the YANG library could constitute a
non-trivial additional risk.  I'm not sure of a good, concise way to
express this.

> The library is intended for other protocols such as RESTCONF.
>
> Is there some specific text you want changed?

I think there could be ambiguity about whether "server" refers to the
NETCONF (or other management protocol) server process on the device, or
to the overall capabilities of the device.  If the YANG library could
provide details that could reveal to an attacker the existence of
vulnerabilities in the underlying network device capabilities, it might
be good to mention it, e.g.,

    In addition to revealing the potential existence of vulnerabilities
    in the network management protocol server on a device, the detailed
    version information available in the module list could help an
    attacker to discover the existence of vulnerable code in the
    implementation of the underlying network capabilities (or other
    functionality) of the device on which the management server is
    running.




--------------080201010401070606030905-- From nobody Thu Apr 7 15:52:18 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 640F912D718; Thu, 7 Apr 2016 15:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5o18_uOcHgA; Thu, 7 Apr 2016 15:52:10 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C878512D103; Thu, 7 Apr 2016 15:52:09 -0700 (PDT) X-AuditID: 1209190f-c8fff70000004b9e-7b-5706e4987c47 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 0C.20.19358.894E6075; Thu, 7 Apr 2016 18:52:08 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u37Mq7Sv016688; Thu, 7 Apr 2016 18:52:08 -0400 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u37Mq5SI014893; Thu, 7 Apr 2016 18:52:06 -0400 From: Tom Yu To: Benoit Claise References: <6AAFCD6E-4F8D-409C-ACB1-53C03413AF7F@gmail.com> <56F3FFE0.3040408@cisco.com> <5705C32C.2010200@cisco.com> Date: Thu, 07 Apr 2016 18:52:05 -0400 In-Reply-To: <5705C32C.2010200@cisco.com> (Benoit Claise's message of "Wed, 6 Apr 2016 23:17:16 -0300") Message-ID: Lines: 169 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUixCmqrTvjCVu4QeNvLYsHR2axWxx9LGHx 4HALm8WMPxOZLU6/Wcdm8WHhQxYHNo8pvzeyeuycdZfdY8mSn0weXy5/ZvNo6b/IEsAaxWWT kpqTWZZapG+XwJVx/eZS5oL1BhWHtl1kbGA8oNjFyMkhIWAicWzSXrYuRi4OIYE2JonlzauZ IZwNjBJ75jUxQTivGSV+PpnFDtLCJiAtcfzyLiYQW0RAVaJ/6xYWkCJmgUuMEh3vzjCDJIQF HCR2nl/HCNG9jEWiYfsWsAQLUMfVb0/BJnEKZErc23GTDcTmFdCVWHFqK9BUDg4eAS6JNdc5 IcKCEidnPmEBsZkFtCRu/HvJNIGRfxaS1CwkqQWMTKsYZVNyq3RzEzNzilOTdYuTE/PyUot0 TfRyM0v0UlNKNzGCA1iSfwfjnAbvQ4wCHIxKPLwWnazhQqyJZcWVuYcYJTmYlER5ZXayhQvx JeWnVGYkFmfEF5XmpBYfYpTgYFYS4ZW8D5TjTUmsrEotyodJSXOwKInzMjIwMAgJpCeWpGan phakFsFkZTg4lCR4Jz8GahQsSk1PrUjLzClBSDNxcIIM5wEa3gJSw1tckJhbnJkOkT/FqCgl zhsIkhAASWSU5sH1ghOMEOO+V4ziQK8I88qAVPEAkxNc9yugwUxAgy/wgw0uSURISTUwKhm3 rdOzfPDzUpzCO5sqq4X/rpQEvU2+dS1I2OnDwwjZxas+/wiNMjXg5OHcsdNy3fdbHa9V+M6v 1zn3qSPzxTdfKdvIBbwm+xld5jcXri0+tahVULKP45X2npdhbxQSA8UvpUxeF6v7/MLHooC1 1hLSk87u1LQNuMYyIYqfq7dzc9iEvC+pSizFGYmGWsxFxYkA043V+wsDAAA= Archived-At: Cc: Mahesh Jethanandani , draft-ietf-netconf-yang-library.all@tools.ietf.org, secdir@ietf.org, Andy Bierman , The IESG Subject: Re: [secdir] secdir review of draft-ietf-netconf-yang-library-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 22:52:12 -0000 I also think that is reasonable. -Tom Benoit Claise writes: > Hi Andy, > > I believe it works. > > Regards, Benoit >> Hi, >> >> Here is the proposed text: >> >> >> OLD: >> >> o /modules-state/module: The module list used in a server >> implementation may help an attacker identify the server >> capabilities and server implementations with known bugs. Server >> vulnerabilities may be specific to particular modules, module >> revisions, module features, or even module deviations. This >> information is included in each module entry. ... >> >> NEW: >> >> o /modules-state/module: The module list used in a server >> implementation may help an attacker identify the server >> capabilities and server implementations with known bugs. Although >> some of this information may be available to all users via the >> NETCONF message (or similar messages in other management >> protocols), this YANG module potentially exposes additional >> details that could be of some assistance to an attacker. Server >> vulnerabilities may be specific to particular modules, module >> revisions, module features, or even module deviations. This >> information is included in each module entry. ... >> >> >> If this is acceptable, I will post a -05 version. >> >> >> Andy >> >> >> On Thu, Mar 24, 2016 at 7:55 AM, Benoit Claise > > wrote: >> >> On 3/23/2016 9:30 PM, Andy Bierman wrote: >>> >>> >>> On Wed, Mar 23, 2016 at 12:39 PM, Tom Yu >> > wrote: >>> >>> Andy Bierman > >>> writes: >>> >>> > The YANG library provides the revision date of the >>> deviations module, >>> > which is not included in the NETCONF . >>> > >>> > It also lists the submodules and their revisions, which is >>> > not contained in the NETCONF . >>> > >>> > The NETCONF message is not specified well enough to >>> > make any other generalizations about the differences. >>> >>> I think it would be good to explicitly mention that the YANG >>> library >>> provides a superset of the module and version information >>> that might be >>> available by other means, e.g., >>> >>> OLD >>> >>> Some of the readable data nodes in this YANG module may be >>> considered >>> sensitive or vulnerable in some network environments. It >>> is thus >>> important to control read access (e.g., via get, >>> get-config, or >>> notification) to these data nodes. These are the subtrees >>> and data >>> nodes and their sensitivity/vulnerability: >>> >>> NEW >>> >>> Some of the readable data nodes in this YANG module may be >>> considered >>> sensitive or vulnerable in some network environments and >>> authorization configurations. Although some of this >>> information may >>> be available to all users via the NETCONF message >>> (or similar >>> messages in other management protocols), this YANG module >>> potentially >>> exposes additional details that could be of some >>> assistance to an >>> attacker. It is thus important to control read access >>> (e.g., via >>> get, get-config, or notification) to these data nodes. >>> These are the >>> subtrees and data nodes and their sensitivity/vulnerability: >>> >>> >>> >>> >>> This is the security boilterplate text that is supposed to >>> go into every YANG module >>> >>> >>> https://tools.ietf.org/html/rfc6087#section-6.1 >>> >>> >>> I prefer to leave the boilerplate alone and move your text into >>> YANG library specific part. >> I would support this. >> >> Regards, Benoit >>> >>> >>> Andy >>> >>> I think if NETCONF access is restricted to a small number of >>> trusted >>> users (even for read-only access), the incremental risk posed by >>> revealing more details about the modules is small. I imagine >>> that there >>> are use cases for providing (restricted) read-only NETCONF >>> access to a >>> wider, mostly untrusted population, in which case the >>> detailed module >>> version information provided by the YANG library could >>> constitute a >>> non-trivial additional risk. I'm not sure of a good, concise >>> way to >>> express this. >>> >>> > The library is intended for other protocols such as RESTCONF. >>> > >>> > Is there some specific text you want changed? >>> >>> I think there could be ambiguity about whether "server" >>> refers to the >>> NETCONF (or other management protocol) server process on the >>> device, or >>> to the overall capabilities of the device. If the YANG >>> library could >>> provide details that could reveal to an attacker the existence of >>> vulnerabilities in the underlying network device >>> capabilities, it might >>> be good to mention it, e.g., >>> >>> In addition to revealing the potential existence of >>> vulnerabilities >>> in the network management protocol server on a device, >>> the detailed >>> version information available in the module list could >>> help an >>> attacker to discover the existence of vulnerable code in the >>> implementation of the underlying network capabilities (or >>> other >>> functionality) of the device on which the management >>> server is >>> running. >>> >>> >> >> From nobody Thu Apr 7 21:26:46 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F266712D54B; Thu, 7 Apr 2016 21:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FR86xlGFJDDb; Thu, 7 Apr 2016 21:26:40 -0700 (PDT) Received: from BAY004-OMC1S8.hotmail.com (bay004-omc1s8.hotmail.com [65.54.190.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 004F612D571; Thu, 7 Apr 2016 21:26:39 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com ([65.54.190.60]) by BAY004-OMC1S8.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Thu, 7 Apr 2016 21:26:40 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/6kbJc+gGZfeom0xaAfgf7ID+ebujsqhN8k1JnXk6Zg=; b=BmUb/udKZAKka/IV6g4SmZo59NfugFnvAyL7wtYdwB8KCeOOwfVBno7Oc7NWRfNQEoWlWzt23RiuxoVFQ7DmX1lMv19hHVMvdRzVl2pp1SrokP+pi815gy9oVe3QW6rDx5aEwJ8zlqiGADCxivCVIyOF2VTjzEeOr8+ltaoRTJCLyImLLvunzLFpcdeydcfC/m/6KR0LKftMjSMC5GA8wGSCjWU5jtTpn8dSpR8GtPwOCpNW+GAlgsRiUlJaVlQWQyCL3PHLc40DfQ8DtfcJH5H6WDzpgUuQX+ww7rqOWGPjsf9x5kDJL4O7VvDQkc5LbbKtrAYyGyj5+xjpnsZs5A== Received: from SN1NAM02FT023.eop-nam02.prod.protection.outlook.com (10.152.72.58) by SN1NAM02HT176.eop-nam02.prod.protection.outlook.com (10.152.72.72) with Microsoft SMTP Server (TLS) id 15.1.453.6; Fri, 8 Apr 2016 04:26:38 +0000 Received: from CY1PR17MB0425.namprd17.prod.outlook.com (10.152.72.53) by SN1NAM02FT023.mail.protection.outlook.com (10.152.72.156) with Microsoft SMTP Server (TLS) id 15.1.453.6 via Frontend Transport; Fri, 8 Apr 2016 04:26:38 +0000 Received: from CY1PR17MB0425.namprd17.prod.outlook.com ([10.163.253.19]) by CY1PR17MB0425.namprd17.prod.outlook.com ([10.163.253.19]) with mapi id 15.01.0453.027; Fri, 8 Apr 2016 04:26:38 +0000 From: Charlie Kaufman To: "secdir@ietf.org" , 'The IESG' , "draft-ietf-tls-falsestart.all@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-tls-falsestart-01 Thread-Index: AQHRkU5CJXLqCw+EvEKL+VeVjBl9tw== Date: Fri, 8 Apr 2016 04:26:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=softfail (sender IP is 25.152.72.53) smtp.mailfrom=outlook.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=outlook.com; received-spf: SoftFail (protection.outlook.com: domain of transitioning outlook.com discourages use of 25.152.72.53 as permitted sender) x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [17cI8gL6vifuppG16dERS0DiiiXigim9] x-eopattributedmessage: 0 x-forefront-antispam-report: CIP:25.152.72.53; IPV:NLI; CTRY:GB; EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1NAM02HT176; H:CY1PR17MB0425.namprd17.prod.outlook.com; FPR:; SPF:SoftFail; MLV:ovrnspm; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 9bd7d8e3-d888-4b7d-c73d-08d35f65fa12 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5061506196)(5061507196); SRVR:SN1NAM02HT176; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:SN1NAM02HT176; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM02HT176; x-forefront-prvs: 0906E83A25 Content-Type: multipart/alternative; boundary="_000_CY1PR17MB0425B0C73C8904BAD68E6B81DF910CY1PR17MB0425namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2016 04:26:38.0460 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM02HT176 X-OriginalArrivalTime: 08 Apr 2016 04:26:40.0080 (UTC) FILETIME=[D8C63500:01D1914E] Archived-At: Subject: [secdir] Secdir review of draft-ietf-tls-falsestart-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 04:26:42 -0000 --_000_CY1PR17MB0425B0C73C8904BAD68E6B81DF910CY1PR17MB0425namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This document specifies a performance enhancement to TLS that under certain= circumstances could weaken security. Much of the document covers criteria = for when it is "safe" to implement this optimization. It would be an option= al behavior in TLS clients and requires no changes to TLS servers (except s= ee below). This I-D is proposed to be an Experimental RFC. This enhancement has been proposed before, but rejected because of the poss= ible security exposures. Nevertheless, because it can be implemented unilat= erally in the client, I would be surprised if some implementations were not= doing it. The performance benefit is the savings of a network round trip, = which is generally small but it could make a human detectable difference in= the rate at which interactive content loads, and this could be seen as a c= ompetitive advantage. The advantage of having such a document published is that people considerin= g making this change could easily learn the security dangers of doing it an= d make an informed decision. Some nits: Section 3 talks about determining whether a TLS server is "false start comp= atible". I believe any server that correctly implements TLS (i.e., followin= g the specification) would be false start compatible. That does not imply t= hat all would be, and it would be useful to do some testing to see whether = most implementations in fact are. Publishing this as an experimental RFC is= likely to encourage such an effort. Section 2 paragraph 1 says that TLS requires two full protocol rounds befor= e the handshake is complete. While technically this is true, it overstates = the benefit of this enhancement because TLS rides atop TCP which has its ow= n protocol round before it starts carrying application payloads. So this en= hancement reduces that TLS startup time from three round trips to two rathe= r than the more dramatic two to one. --_000_CY1PR17MB0425B0C73C8904BAD68E6B81DF910CY1PR17MB0425namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

This document specifies a performance enhancement to TLS that under cert= ain circumstances could weaken security. Much of the document covers criter= ia for when it is "safe" to implement this optimization. It would= be an optional behavior in TLS clients and requires no changes to TLS servers (except see below). This I-D is propose= d to be an Experimental RFC.


This enhancement has been proposed before, but rejected because of the p= ossible security exposures. Nevertheless, because it can be implemented uni= laterally in the client, I would be surprised if some implementations were = not doing it. The performance benefit is the savings of a network round trip, which is generally small but it co= uld make a human detectable difference in the rate at which interactive con= tent loads, and this could be seen as a competitive advantage.


The advantage of having such a document published is that people conside= ring making this change could easily learn the security dangers of doing it= and make an informed decision.


Some nits:


Section 3 talks about determining whether a TLS server is "false st= art compatible". I believe any server that correctly implements TLS (i= .e., following the specification) would be false start compatible. That doe= s not imply that all would be, and it would be useful to do some testing to see whether most implementations in fact a= re. Publishing this as an experimental RFC is likely to encourage such an e= ffort.


Section 2 paragraph 1 says that TLS requires two full protocol rounds be= fore the handshake is complete. While technically this is true, it overstat= es the benefit of this enhancement because TLS rides atop TCP which has its= own protocol round before it starts carrying application payloads. So this enhancement reduces that TLS startu= p time from three round trips to two rather than the more dramatic two to o= ne.


--_000_CY1PR17MB0425B0C73C8904BAD68E6B81DF910CY1PR17MB0425namp_-- From nobody Sat Apr 9 07:22:25 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6425F12D19A; Sat, 9 Apr 2016 07:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BPZChr1X7Pg; Sat, 9 Apr 2016 07:22:18 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D41E12D096; Sat, 9 Apr 2016 07:22:18 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id D001718BA38EE; Sat, 9 Apr 2016 14:22:12 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u39EMFSr018166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 9 Apr 2016 14:22:15 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u39EMDXI017868 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 9 Apr 2016 16:22:14 +0200 Received: from FR711WXCHMBA02.zeu.alcatel-lucent.com ([169.254.2.90]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Sat, 9 Apr 2016 16:22:13 +0200 From: "Murray, Rob (Nokia - GB)" To: EXT Vincent Roca Thread-Topic: Secdir review of draft-ietf-cdni-control-triggers-11 Thread-Index: AQHRdiVIwOmzDCWgCk67ArY5AP/E6Z9lmUqAgBxAEgA= Date: Sat, 9 Apr 2016 14:22:13 +0000 Message-ID: References: <252883D7-E325-4B9A-A978-FEACE5B40143@alcatel-lucent.com> <61B94AAC-920E-4909-9680-6FF212E8901D@inria.fr> In-Reply-To: <61B94AAC-920E-4909-9680-6FF212E8901D@inria.fr> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_CD009C877BB844A09D0E5C6BD1903BBEalcatellucentcom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-cdni-control-triggers@tools.ietf.org" , "cdni@ietf.org" , IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-cdni-control-triggers-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 14:22:20 -0000 --_000_CD009C877BB844A09D0E5C6BD1903BBEalcatellucentcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIFZpbmNlbnQsIEknbGwgbWFrZSB0aG9zZSBtb2RzIGluIHRoZSBuZXh0IHVwZGF0ZS4N Cg0KRnJvbTogRVhUIFZpbmNlbnQgUm9jYSA8dmluY2VudC5yb2NhQGlucmlhLmZyPG1haWx0bzp2 aW5jZW50LnJvY2FAaW5yaWEuZnI+Pg0KRGF0ZTogVHVlc2RheSwgMjIgTWFyY2ggMjAxNiBhdCAx NDo1Nw0KVG86IFJvYiBNdXJyYXkgPHJvYi5tdXJyYXlAbm9raWEuY29tPG1haWx0bzpyb2IubXVy cmF5QG5va2lhLmNvbT4+DQpDYzogVmluY2VudCBSb2NhIDx2aW5jZW50LnJvY2FAaW5yaWEuZnI8 bWFpbHRvOnZpbmNlbnQucm9jYUBpbnJpYS5mcj4+LCBJRVNHIDxpZXNnQGlldGYub3JnPG1haWx0 bzppZXNnQGlldGYub3JnPj4sICJzZWNkaXJAaWV0Zi5vcmc8bWFpbHRvOnNlY2RpckBpZXRmLm9y Zz4iIDxzZWNkaXJAaWV0Zi5vcmc8bWFpbHRvOnNlY2RpckBpZXRmLm9yZz4+LCAiZHJhZnQtaWV0 Zi1jZG5pLWNvbnRyb2wtdHJpZ2dlcnNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYt Y2RuaS1jb250cm9sLXRyaWdnZXJzQHRvb2xzLmlldGYub3JnPiIgPGRyYWZ0LWlldGYtY2RuaS1j b250cm9sLXRyaWdnZXJzQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWNkbmktY29u dHJvbC10cmlnZ2Vyc0B0b29scy5pZXRmLm9yZz4+LCAiY2RuaUBpZXRmLm9yZzxtYWlsdG86Y2Ru aUBpZXRmLm9yZz4iIDxjZG5pQGlldGYub3JnPG1haWx0bzpjZG5pQGlldGYub3JnPj4NClN1Ympl Y3Q6IFJlOiBTZWNkaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtY2RuaS1jb250cm9sLXRyaWdnZXJz LTExDQoNCkhpIFJvYiwNCg0KSSd2ZSBqdXN0IHBvc3RlZCBhICItMTIiIG9mIHRoZSBDRE5JIFRy aWdnZXJzIGRyYWZ0LCBob3BlZnVsbHkgYWRkcmVzc2luZyB0aGVzZSBjb21tZW50cy4gUmVzcG9u c2VzIGlubGluZSBiZWxvdy4NCg0KSSBzZWUgeW91J3ZlIGFkZGVkIHNlY3Rpb24gMi4yLjEgdG8g Y2xhcmlmeSBtYW55IGFyY2hpdGVjdHVyYWwgYXNwZWN0cy4gVGhhdCdzIHF1aXRlIHVzZWZ1bC4N Cg0KDQpUaGVyZSBhcmUgc2V2ZXJhbCB0b3BpY3MgSeKAmWQgbGlrZSB0byBkaXNjdXNzOg0KDQox LSBDb25jZXJuaW5nIHRoZSB1c2Ugb2YgVExTIHRvIGNhcnJ5IENJL1QgdHJhZmZpYywgSSBzZWUg aXQgaXMgbWFuZGF0b3J5DQp0byBpbXBsZW1lbnQsIGJ1dCBzdGlsbCBvcHRpb25hbCB0byB1c2Ug KDFzdCBzZW50ZW5jZSBvZiBTZWN0aW9uIDguMSkuIElzDQppdCBzdGlsbCByZWFzb25hYmxlIGlu IGN1cnJlbnQgSW50ZXJuZXQ/IEF0IGEgbWluaW11bSBJIHdvdWxkIGV4cGVjdCBhDQrCqyBNVVNU IHN1cHBvcnQgwrsgLyDCqyBTSE9VTEQgdXNlIMK7Lg0KDQpTZWN0aW9uIDguMSBnb2VzIG9uIHRv IHNheSAuLi4NCg0KIFsgLi4uIGRlc2NyaXB0aW9uIG9mIGJlbmVmaXRzIG9mIEhUVFBTIC4uLiBd DQoNCiBJbiBhbiBlbnZpcm9ubWVudCB3aGVyZSBhbnkgc3VjaCBwcm90ZWN0aW9uIGlzIHJlcXVp cmVkLCBtdXR1YWxseQ0KIGF1dGhlbnRpY2F0ZWQgZW5jcnlwdGVkIHRyYW5zcG9ydCBNVVNUIGJl IHVzZWQgdG8gZW5zdXJlDQogY29uZmlkZW50aWFsaXR5IG9mIHRoZSBDSS9UIGluZm9ybWF0aW9u LiBUbyB0aGF0IGVuZCwgVExTIE1VU1QgYmUNCiB1c2VkIGJ5IENJL1QsIGluY2x1ZGluZyBhdXRo ZW50aWNhdGlvbiBvZiB0aGUgcmVtb3RlIGVuZC4NCg0KLi4uIHRoZSBJbnRlcm5ldCBpcyBjbGVh cmx5IGFuIGVudmlyb25tZW50IHdoZXJlIHN1Y2ggcHJvdGVjdGlvbiBpcw0KcmVxdWlyZWQsIGFu ZCBpdCdsbCBvZnRlbiBiZSB1c2VkIGZvciB0aGVzZSBpbnRlcmZhY2VzIC0gd2UgY291bGQgc3Rh dGUNCnRoYXQgZXhwbGljaXRseSwgd291bGQgdGhhdCBhZGRyZXNzIHRoZSBjb25jZXJuPw0KDQpC dXQsIENJL1QgY291bGQgYWxzbyBiZSBkZXBsb3llZCB0byBydW4gb3ZlciBhIFZQTiBvciBwcml2 YXRlIG5ldHdvcmsNCmJldHdlZW4gdHdvIGludGVyY29ubmVjdGVkIENETnMsIGluIHN1Y2ggYW4g ZW52aXJvbm1lbnQgSFRUUFMgdHJhbnNwb3J0DQp3b3VsZCBub3QgaGF2ZSB0aGUgc2FtZSBiZW5l Zml0cy4NCg0KWWVzLCB0aGF04oCZcyBteSBwb2ludC4gU2F5IGV4cGxpY2l0bHkgdGhhdCBJbnRl cm5ldCBpcyBhbiBleGFtcGxlIG9mIGVudmlyb25tZW50IHdoZXJlDQpzdWNoIGEgcHJvdGVjdGlv biBpcyBtYW5kYXRvcnkuDQoNCkluICItMTIiIEkndmUgYWxpZ25lZCB0aGUgdGV4dCBhYm92ZSB3 aXRoIHRoZSB0ZXh0IHVzZWQgaW4gdGhlIGNkbmktbWV0YWRhdGEgZHJhZnQ6DQoNCiBUTFMgTVVT VCBiZSB1c2VkIGJ5IHRoZSBzZXJ2ZXItc2lkZSAoZENETikgYW5kIHRoZSBjbGllbnQtc2lkZSAo dUNETikgb2YNCiB0aGUgQ0kvVCBpbnRlcmZhY2UsIGluY2x1ZGluZyBhdXRoZW50aWNhdGlvbiBv ZiB0aGUgcmVtb3RlIGVuZCwgdW5sZXNzDQogYWx0ZXJuYXRlIG1ldGhvZHMgYXJlIHVzZWQgZm9y IGVuc3VyaW5nIHRoZSBjb25maWRlbnRpYWxpdHkgb2YgdGhlDQogaW5mb3JtYXRpb24gaW4gdGhl IENJL1QgaW50ZXJmYWNlIHJlcXVlc3RzIGFuZCByZXNwb25zZXMgKHN1Y2ggYXMgc2V0dGluZw0K IHVwIGFuIElQc2VjIHR1bm5lbCBiZXR3ZWVuIHRoZSB0d28gQ0ROcyBvciB1c2luZyBhIHBoeXNp Y2FsbHkgc2VjdXJlZA0KIGludGVybmFsIG5ldHdvcmsgYmV0d2VlbiB0d28gQ0ROcyB0aGF0IGFy ZSBvd25lZCBieSB0aGUgc2FtZSBjb3Jwb3JhdGUNCiBlbnRpdHkpLg0KDQpJIHRoaW5rIHRoYXQg Y292ZXJzIGl0IGJldHRlciAoPykuDQoNClRoaXMgaXMgbXVjaCBiZXR0ZXIuIEp1c3QgYSBtaW5v ciBjb21tZW50OiAiLi4uIGZvciBpbnN1cmluZyB0aGUgc2VjdXJpdHkiIGluc3RlYWQgb2YNCiIu Li4gZm9yIGVuc3VyaW5nIHRoZSBjb25maWRlbnRpYWxpdHkiLCBzaW5jZSBjb25maWRlbnRpYWxp dHkgaXMgb25seSBvbmUgYXNwZWN0IG9mIHNlY3VyaXR5Lg0KDQoNCjItIFNlY3Rpb24gOC4xLCBw bGVhc2UgY2hlY2sgdGhlIHBhcmFncmFwaCDCqyBOb3RlIHRoYXQgaW4gYSDCqyBkaWFtb25kIMK7 DQpjb25maWd1cmF0aW9uIFvigKZdIMK7LiBUaGlzIHBhcmFncmFwaCBpcyByYXRoZXIgY29uZnVz aW5nIHRvIG1lLiBDb25mdXNpb24NCmNvbWVzIGZyb206DQotIHRoZSBsYWNrIG9mIGRlc2NyaXB0 aW9uIG9mIHRoZSDCqyBkaWFtb25kIGNvbmZpZ3VyYXRpb24gwrsuIEkgdW5kZXJzdGFuZA0KdGhl cmUgaXMgb25lIGRDRE4gb24gdG9wIGFuZCBtdWx0aXBsZSB1Q0ROIGRpcmVjdGx5IGNvbm5lY3Rl ZCBiZWxvdywgYW0gSQ0KcmlnaHQ/DQoNClllcywgdGhhdCdzIHJpZ2h0LiBUaGUgZHJhZnQgc2F5 czoNCg0KIE5vdGUgdGhhdCBpbiBhICJkaWFtb25kIiBjb25maWd1cmF0aW9uLCB3aGVyZSBvbmUg dUNETidzIGNvbnRlbnQgY2FuDQogYmUgYWNxdWlyZWQgdmlhIG1vcmUgdGhhbiBvbmUgZGlyZWN0 bHktY29ubmVjdGVkIHVDRE4sDQoNCldvdWxkIHRoZSBmb2xsb3dpbmcgcmVhcnJhbmdlbWVudCBo ZWxwPyAuLi4NCg0KIEEgImRpYW1vbmQiIGNvbmZpZ3VyYXRpb24gaXMgb25lIHdoZXJlIGEgZENE TiBjYW4gYWNxdWlyZSBhIHVDRE4ncw0KIGNvbnRlbnQgdmlhIG1vcmUgdGhhbiBvbmUgZGlyZWN0 bHktY29ubmVjdGVkIHVDRE4uIE5vdGUgdGhhdA0KIGluIGEgZGlhbW9uZCBjb25maWd1cmF0aW9u IFvigKZdDQoNClllcywgSSBwcmVmZXIgdGhpcyB2ZXJzaW9uLiBIb3dldmVyLCBjYW4gdGhlIHNh bWUgwqsgdUNETuKAmXMgY29udGVudCDCuyBiZQ0KYXZhaWxhYmxlIGF0IHNldmVyYWwgdUNETnMg aW4gdGhpcyBkaWFtb25kIGNvbmZpZ3VyYXRpb24/IFNhaWQgZGlmZmVyZW50bHksDQp3aGF0IGFi b3V0IHRoZSBmb2xsb3dpbmcgdGV4dDoNCg0KQSDCqyBkaWFtb25kIMK7IGNvbmZpZ3VyYXRpb24g aXMgb25lIHdoZXJlIGEgZENETiBjYW4gYWNxdWlyZSBhIGdpdmVuDQpjb250ZW50IHZpYSBtb3Jl IHRoYW4gb25lIGRpcmVjdGx5LWNvbm5lY3RlZCB1Q0ROLiBOb3RlIHRoYXQgW+KApl0NCg0KWWVz LCBtb3JlIHRoYW4gb25lIHVDRE4gd2lsbCBoYXZlIHRoZSBzYW1lIGNvbnRlbnQgLSBidXQgdGhl IGltcG9ydGFudCBwb2ludCBpcyB0aGF0IHVsdGltYXRlbHkgdGhleSB3aWxsIGFsbCBoYXZlIGFj cXVpcmVkIGl0IGZyb20gdGhlIHNhbWUgdUNETiwgYW5kIHRoYXQgdUNETiBvd25zIHRoZSBtZXRh ZGF0YS4NCg0KSSd2ZSB0cmllZCB0byBwcm92aWRlIGEgYmV0dGVyIGludHJvL2V4cGxhbmF0aW9u IGluIG5ldyBzZWN0aW9uIDIuMi4xICJNdWx0aXBsZSBpbnRlcmNvbm5lY3RlZCBDRE5zIi4gSG9w ZWZ1bGx5IHRoYXQgbWFrZXMgaXQgYSBiaXQgY2xlYXJlcj8NCg0KWWVzLCBhcyBzYWlkIGFib3Zl LCBzZWN0aW9uIDIuMi4xIGlzIHJhdGhlciB1c2VmdWwuDQpKdXN0IGEgY29tbWVudCBmb3IgdGhp cyBzZWN0aW9uIDIuMi4xLCB0aGlyZCBwYXJhZ3JhcGgsIGxhc3Qgc2VudGVuY2UuIFlvdSBtZW50 aW9uDQpib3RoICJpbnRlcm1lZGlhdGUgQ0ROIiBhbmQganVzdCBhZnRlciAiaW50ZXJtZWRpYXRl IHVDRE4iLiBUaGlzIGlzIGEgYml0IGNvbmZ1c2luZy4NCg0KQW5vdGhlciBkZXRhaWw6IGluIHNl Y29uZCBwYXJhZ3JhcGggeW91IG1lbnRpb24gIiJpbnRlcm1lZGlhdGUiIENETiIgd2l0aCBleHRy YSAiICINCmFyb3VuZCBpbnRlcm1lZGlhdGUuIFBsZWFzZSBoYXJtb25pemUuDQoNCg0KMy0gV2l0 aCB0aGlzIMKrIGRpYW1vbmQgY29uZmlndXJhdGlvbiDCuywgc2luY2Ugc2V2ZXJhbCB1Q0ROIGNh biBhY3QgdXBvbiB0aGUNCnNhbWUgY29udGVudCwgd2hhdCBoYXBwZW5zIGlmIHRoZXkgYmVoYXZl IGluIGEgbm9uIGNvb3JkaW5hdGVkIG1hbm5lciAoaS5lLiwNCmluIHRoZSBnZW5lcmFsIGNhc2Up PyBGb3IgaW5zdGFuY2UgbGV04oCZcyBpbWFnaW5lIG9uZSBvZiB0aGVtIGFza3MgdGhlIGRDRE4N CnRvIGRlbGV0ZSB0aGUgY29udGVudCBvciBjYW5jZWwgdGhlIGluaXRpYWwgY29tbWFuZC4gV2hh dCBoYXBwZW5zIGlmIGFub3RoZXINCnVDRE4gdGhlbiBhc2tzIHRoZSBkQ0ROIHRvIGludmFsaWRh dGUgdGhpcyBjb250ZW50LCBwcm92aWRpbmcgdGhlIFVSTCBvZiB0aGUNClRyaWdnZXIgU3RhdHVz IFJlc291cmNlIHdoaWNoIChpZiBJIHVuZGVyc3RhbmQgY29ycmVjdGx5KSBpcyBubyBsb25nZXIg dmFsaWQ/DQpUaGlzIMKrIGRpYW1vbmQgY29uZmlndXJhdGlvbiDCuyBjYW4gYmUgYSBsaXR0bGUg Yml0IHRyaWNreSBhbmQgbm8gY2xlYXINCmd1aWRlbGluZSBpcyBwcm92aWRlZCBpbiB0aGUgZG9j dW1lbnQuDQoNCkEgdHJpZ2dlciBzdGF0dXMgcmVzb3VyY2UgYmVsb25ncyB0byBvbmUgdUNETiBh bmQgY2Fubm90IGJlIGFjY2Vzc2VkIG9yDQptYW5pcHVsYXRlZCBieSBhbnkgb3RoZXIgQ0ROLCBz ZWN0aW9uIDMgcGFyYSAzIHNheXM6DQoNCiBUcmlnZ2VyIFN0YXR1cyBSZXNvdXJjZXMgYmVsb25n aW5nIHRvIGEgdUNETiBNVVNUIE5PVA0KIGJlIHZpc2libGUgdG8gYW55IG90aGVyIENETi4gVGhl IGRDRE4gY291bGQsIGZvciBleGFtcGxlLCBhY2hpZXZlDQogdGhpcyBieSBvZmZlcmluZyBkaWZm ZXJlbnQgY29sbGVjdGlvbiBVUkxzIHRvIGVhY2ggdUNETiwgYW5kL29yIGJ5DQogZmlsdGVyaW5n IHRoZSByZXNwb25zZSBiYXNlZCBvbiB0aGUgdUNETiB3aXRoIHdoaWNoIHRoZSBIVFRQIGNsaWVu dA0KIGlzIGFzc29jaWF0ZWQuDQoNCkkgc2Vl4oCmIEhvd2V2ZXIsIGlmIG11bHRpcGxlIHVDRE5z IGNhbiBhY3Qgb24gdGhlIHNhbWUgY29udGVudCAod2hhdCBpcyBzYWlkKSwNCmV2ZW4gaWYgZWFj aCB1Q0ROIHVzZXMgYSBkaWZmZXJlbnQgVVJMLCB3aWxsIHNpbXVsdGFuZW91cyBDSS9UIGNvbW1h bmRzIGZvcg0KdGhlIHNhbWUgY29udGVudCBiZSBtYW5hZ2VkIGNvcnJlY3RseT8gVGhpcyBpcyBu b3Qgc2FpZCBpbiBzZWN0aW9uIDMNCnBhcmFncmFwaCAzIGVpdGhlciBhbmQgdGhpcyBpcyBhIGtl eSBwb2ludC4NCg0KU29ycnksIEknZCBtaXNzZWQgeW91ciBwb2ludC4NCg0KSW50ZXJhY3Rpb25z IGNhbiBiZSBpbmVmZmljaWVudCwgYnV0IGFyZSBvdGhlcndpc2UgaGFybWxlc3MgYmVjYXVzZSB0 aGUgc3Ryb25nZXN0IG9mICJpbnZhbGlkYXRlIiBvciAicHVyZ2UiIHdpbGwgd2luLCBhbmQgY29u dGVudCBjYW4gYWx3YXlzIGJlIHJlLWFjcXVpcmVkIGlmIGl0J3Mgc3RpbGwgYXZhaWxhYmxlIGZy b20gYW55IHVDRE4uDQoNCkkndmUgZ2l2ZW4gc29tZSBleGFtcGxlcyBpbiBuZXcgc2VjdGlvbiAy LjIuMSAiTXVsdGlwbGUgaW50ZXJjb25uZWN0ZWQgQ0ROcyIsIGFuZCBhZGRlZCBhIHBvaW50ZXIg dG8gdGhhdCBmcm9tIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uLg0KDQpPbmNl IGFnYWluLCB0aGUgZXhhbXBsZXMgb2Ygc2VjdGlvbiAyLjIuMSBhbnN3ZXIgbXkgY29tbWVudHMu IFRoYW5rcy4NCg0KDQpDb250ZW50IGFsd2F5cyBvcmlnaW5hdGVzIGZyb20gb25lIHVDRE4sIGJ1 dCBpbiBhIGRpYW1vbmQgY29uZmlncmF0aW9uIHRoZXJlDQptYXkgYmUgbXVsdGlwbGUgcm91dGVz ICh2aWEgb3RoZXIgQ0ROcykgdG8gYSBnaXZlbiBkQ0ROLg0KDQpUaGUgbW9zdCBjb21tb24gc2Nl bmFyaW8gbWF5IHdlbGwgYmUgdGhhdCB0aGUgdUNETiB3aWxsIGluaXRpYXRlIGFsbCBvZiB0aGUN CkNJL1QgY29tbWFuZHMgcmVsYXRlZCB0byBpdHMgY29udGVudCwgYW5kIHRob3NlIGNvbW1hbmRz IHdpbGwgc2ltcGx5IGJlDQpmb3J3YXJkZWQgYnkgaW50ZXJtZWRpYXRlIENETnMuDQoNCkJ1dCwg dGhlcmUncyBub3RoaW5nIHRvIHN0b3AgYW4gaW50ZXJtZWRpYXRlIENETiBpbml0aWF0aW5nIG9y IG1vZGlmeWluZw0KQ0kvVCBjb21tYW5kcyAtIGFuZCBzb21lIG1vZGlmaWNhdGlvbnMgb2YgdGhl IGNvbW1hbmQgd2lsbCBiZSBuZWNlc3NhcnkNCihmb3IgZXhhbXBsZSwgbWV0YWRhdGEgVVJMcyB3 aWxsIG5lZWQgdG8gYmUgY2hhbmdlZCkuDQoNCkJ5IGFuYWx5c2lzIG9mIGxvZyBmaWxlcyBpdCB3 aWxsIHByb2JhYmx5IGJlIHBvc3NpYmxlIHRvIHdvcmsgb3V0IHdoaWNoDQp1Q0ROIGFuIGluZGl2 aWR1YWwgY2FjaGUgaW4gdGhlIGRDRE4gYWNxdWlyZWQgZWFjaCBjYWNoZWQgcmVzb3VyY2UgZnJv bS4NCkJ1dCB0aGUgY2FjaGUgaXMgbm90IHJlcXVpcmVkIHRvIGtlZXAgYSBsaXZlIHJlY29yZCBv ZiB0aGF0LCBhbmQgaXQNCnByb2JhYmx5IHdvbid0LiBJbiB0aGF0IGNhc2UsIHdoZW4gaXQgcmVj ZWl2ZXMgYSBDSS9UIGNvbW1hbmQgdG8gaW52YWxpZGF0ZQ0Kb3IgcHVyZ2UgY29udGVudCwgdGhl IGRDRE4gc2hvdWxkIGFwcGx5IHRoYXQgY29tbWFuZCB0byBhbnkgY29udGVudCBpdA0KbWF5IGhh dmUgYWNxdWlyZWQgZnJvbSB0aGUgdUNETiBpdCBnb3QgdGhlIENJL1QgY29tbWFuZCBmcm9tLg0K DQpTbyB0aGVyZSBpcyBzY29wZSBmb3IgYSBtYWxpY2lvdXMgaW50ZXJtZWRpYXRlIENETiB0byBj YXVzZSBleHRyYSBwcm9jZXNzaW5nDQphbmQgYWNxdWlzaXRpb24gYnkgYSBkQ0ROIChhbmQgdGhh dCdzIG1lbnRpb25lZCBpbiBzZWN0aW9uIDgpLiBCdXQgYQ0KbWFsaWNpb3VzIENETiBpcyBsaWtl bHkgdG8gZmluZCBpdHNlbGYgcmVtb3ZlZCBmcm9tIHRoZSBDRE4gZmVkZXJhdGlvbiBmYWlybHkN CnF1aWNrbHkgLSB0aGVyZSB3aWxsIG5lY2Vzc2FyaWx5IGJlIGEgbGV2ZWwgb2YgdHJ1c3QgYmV0 d2VlbiBpbnRlcmNvbm5lY3RlZA0KQ0ROcy4NCg0KV291bGQgaXQgaGVscCB0byBzcGVsbCBvdXQg c29tZSBvZiB0aGF0IGluIHRoZSBkcmFmdD8gKFRoZSBzYW1lIG9yIHZlcnkNCnNpbWlsYXIgdGV4 dCBoYXMgYmVlbiB1c2VkIGluIHNldmVyYWwgb2YgdGhlIENETkkgZHJhZnRzLikNCg0KWWVzLCB0 aGlzIHBhcmFncmFwaCBpcyB3b3J0aCBiZWluZyBkZXRhaWxlZCBhIGxpdHRsZSBiaXQuDQoNCklu IHlvdXIgZXhwbGFuYXRpb25zIHlvdSBtZW50aW9uIGludGVybWVkaWF0ZSBDRE5zIHdoaWxlIG9y aWdpbmFsIHRleHQgb25seQ0KbWVudGlvbnMgZGlyZWN0bHkgY29ubmVjdGVkIHVDRE5zLiBUaGUg bm90aW9uIG9mIMKrIGludGVybWVkaWF0ZSBDRE4gwrsgaXMNCm9ubHkgZGlzY3Vzc2VkIGluIHNl Y3Rpb25zIDIuMyBhbmQgNC44LiBTaW5jZSBtYWxpY2lvdXMgaW50ZXJtZWRpYXRlIENETnMgYXJl DQpwYXJ0IG9mIGEgdmFsaWQgYXR0YWNrIG1vZGVsLCBpdCBpcyB3b3J0aCB0byBleHBsYWluIGl0 IChvciBnaXZlIGEgcmVmZXJlbmNlIHRvIGFub3RoZXINCmRvY3VtZW50KS4NCg0KV2hlbiBhIGNv bnRlbnQgb3duZXIsIHRoZSBvcmlnaW4sIGRlbGVnYXRlcyBkZWxpdmVyeSB0byBhIENETiBpdCBp cyB0cnVzdGluZyB0aGF0IENETiB0byBkZWxpdmVyIHRoZSByaWdodCBjb250ZW50IG9uIGl0cyBi ZWhhbGYuIEEgbWFsaWNpb3VzIENETiBjb3VsZCBkZWxpdmVyIGFueXRoaW5nIGluc3RlYWQsIGJ1 dCBpdCB3b3VsZCBzb29uIGxvc2UgdGhlIHRydXN0IG9mIHRoZSBvcmlnaW4uDQoNCkNETi1pbnRl cmNvbm5lY3Rpb24gc2ltcGx5IGV4dGVuZHMgdGhhdCB0cnVzdCB0byB0aGUgZnVydGhlci1kb3du c3RyZWFtIENETnMgYWN0aW5nIG9uIGJlaGFsZiBvZiB0aGUgb3JpZ2luYWwuDQoNClNvIGVzdGFi bGlzaG1lbnQvZW5mb3JjZW1lbnQgb2YgdGhlIHRydXN0IHJlbGF0aW9uc2hpcCBpdHNlbGYsIHRo ZSBjb250cmFjdCBiZXR3ZWVuIHRoZSBvcmlnaW4gYW5kIHRoZSBDRE4sIGlzIG91dHNpZGUgdGhl IHNjb3BlIG9mIENETkkgYW5kIGluIHRoZSBsYW5kIG9mIGNvbW1lcmNpYWwgYWdyZWVtZW50cy4N Cg0KU3VyZSwgSSBhZ3JlZS4NCg0KDQpJJ3ZlIGFkZGVkIGEgbm90ZSBvbiB0aGF0IGluIHRoZSBp bnRybyB0byB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbi4NCg0KVGhhdCdzIHBl cmZlY3QuDQoNClRvIGNvbmNsdWRlIHRoZSBkb2N1bWVudCBpcyBva2F5IGZyb20gbXkgcG9pbnQg b2Ygdmlldy4NCg0KVGhhbmtzIGZvciB5b3VyIGRldGFpbGVkIGFuc3dlcnMuDQpDaGVlcnMsDQoN CiAgIFZpbmNlbnQNCg== --_000_CD009C877BB844A09D0E5C6BD1903BBEalcatellucentcom_ Content-Type: text/html; charset="utf-8" Content-ID: <11CB9F58BEF5BD498E6DBAA0C9214C51@exchange.lucent.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PlRoYW5rcyBWaW5jZW50LCBJJ2xsIG1ha2UgdGhvc2UgbW9kcyBpbiB0aGUgbmV4dCB1cGRh dGUuPC9kaXY+DQo8ZGl2Pg0KPGRpdiBpZD0iTUFDX09VVExPT0tfU0lHTkFUVVJFIj48L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xL X1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9u dC1zaXplOjEycHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006 IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAw aW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNi NWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDog M3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+RVhUIFZp bmNlbnQgUm9jYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZpbmNlbnQucm9jYUBpbnJpYS5mciI+dmlu Y2VudC5yb2NhQGlucmlhLmZyPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6 Ym9sZCI+RGF0ZTogPC9zcGFuPlR1ZXNkYXksIDIyIE1hcmNoIDIwMTYgYXQgMTQ6NTc8YnI+DQo8 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5Sb2IgTXVycmF5ICZsdDs8 YSBocmVmPSJtYWlsdG86cm9iLm11cnJheUBub2tpYS5jb20iPnJvYi5tdXJyYXlAbm9raWEuY29t PC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj5W aW5jZW50IFJvY2EgJmx0OzxhIGhyZWY9Im1haWx0bzp2aW5jZW50LnJvY2FAaW5yaWEuZnIiPnZp bmNlbnQucm9jYUBpbnJpYS5mcjwvYT4mZ3Q7LCBJRVNHICZsdDs8YSBocmVmPSJtYWlsdG86aWVz Z0BpZXRmLm9yZyI+aWVzZ0BpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86 c2VjZGlyQGlldGYub3JnIj5zZWNkaXJAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86c2VjZGlyQGlldGYub3JnIj5zZWNkaXJAaWV0Zi5vcmc8L2E+Jmd0OywNCiAmcXVvdDs8 YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1jZG5pLWNvbnRyb2wtdHJpZ2dlcnNAdG9vbHMuaWV0 Zi5vcmciPmRyYWZ0LWlldGYtY2RuaS1jb250cm9sLXRyaWdnZXJzQHRvb2xzLmlldGYub3JnPC9h PiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtY2RuaS1jb250cm9sLXRyaWdn ZXJzQHRvb2xzLmlldGYub3JnIj5kcmFmdC1pZXRmLWNkbmktY29udHJvbC10cmlnZ2Vyc0B0b29s cy5pZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86Y2RuaUBpZXRmLm9yZyI+ Y2RuaUBpZXRmLm9yZzwvYT4mcXVvdDsNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNkbmlAaWV0Zi5v cmciPmNkbmlAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFNlY2RpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1jZG5p LWNvbnRyb2wtdHJpZ2dlcnMtMTE8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTog c3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4N CkhpIFJvYiwNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPkkndmUganVzdCBw b3N0ZWQgYSAmcXVvdDstMTImcXVvdDsgb2YgdGhlIENETkkgVHJpZ2dlcnMgZHJhZnQsIGhvcGVm dWxseSBhZGRyZXNzaW5nIHRoZXNlIGNvbW1lbnRzLiBSZXNwb25zZXMgaW5saW5lIGJlbG93Ljxi ciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2Pkkgc2VlIHlvdSd2ZSBhZGRlZCBzZWN0aW9uIDIuMi4xIHRvIGNsYXJpZnkgbWFueSBhcmNo aXRlY3R1cmFsIGFzcGVjdHMuIFRoYXQncyBxdWl0ZSB1c2VmdWwuPC9kaXY+DQo8ZGl2PjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIg Y2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ VGhlcmUgYXJlIHNldmVyYWwgdG9waWNzIEnigJlkIGxpa2UgdG8gZGlzY3Vzczo8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQoxLSBDb25jZXJuaW5nIHRoZSB1c2Ugb2YgVExTIHRvIGNhcnJ5 IENJL1QgdHJhZmZpYywgSSBzZWUgaXQgaXMgbWFuZGF0b3J5PGJyIGNsYXNzPSIiPg0KdG8gaW1w bGVtZW50LCBidXQgc3RpbGwgb3B0aW9uYWwgdG8gdXNlICgxc3Qgc2VudGVuY2Ugb2YgU2VjdGlv biA4LjEpLiBJczxiciBjbGFzcz0iIj4NCml0IHN0aWxsIHJlYXNvbmFibGUgaW4gY3VycmVudCBJ bnRlcm5ldD8gQXQgYSBtaW5pbXVtIEkgd291bGQgZXhwZWN0IGE8YnIgY2xhc3M9IiI+DQrCqyBN VVNUIHN1cHBvcnQgwrsgLyDCqyBTSE9VTEQgdXNlIMK7LjxiciBjbGFzcz0iIj4NCjwvYmxvY2tx dW90ZT4NCjxiciBjbGFzcz0iIj4NClNlY3Rpb24gOC4xIGdvZXMgb24gdG8gc2F5IC4uLjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwO1sgLi4uIGRlc2NyaXB0aW9uIG9mIGJlbmVm aXRzIG9mIEhUVFBTIC4uLiBdPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7SW4g YW4gZW52aXJvbm1lbnQgd2hlcmUgYW55IHN1Y2ggcHJvdGVjdGlvbiBpcyByZXF1aXJlZCwgbXV0 dWFsbHk8YnIgY2xhc3M9IiI+DQombmJzcDthdXRoZW50aWNhdGVkIGVuY3J5cHRlZCB0cmFuc3Bv cnQgTVVTVCBiZSB1c2VkIHRvIGVuc3VyZTxiciBjbGFzcz0iIj4NCiZuYnNwO2NvbmZpZGVudGlh bGl0eSBvZiB0aGUgQ0kvVCBpbmZvcm1hdGlvbi4gVG8gdGhhdCBlbmQsIFRMUyBNVVNUIGJlPGJy IGNsYXNzPSIiPg0KJm5ic3A7dXNlZCBieSBDSS9ULCBpbmNsdWRpbmcgYXV0aGVudGljYXRpb24g b2YgdGhlIHJlbW90ZSBlbmQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KLi4uIHRoZSBJ bnRlcm5ldCBpcyBjbGVhcmx5IGFuIGVudmlyb25tZW50IHdoZXJlIHN1Y2ggcHJvdGVjdGlvbiBp czxiciBjbGFzcz0iIj4NCnJlcXVpcmVkLCBhbmQgaXQnbGwgb2Z0ZW4gYmUgdXNlZCBmb3IgdGhl c2UgaW50ZXJmYWNlcyAtIHdlIGNvdWxkIHN0YXRlPGJyIGNsYXNzPSIiPg0KdGhhdCBleHBsaWNp dGx5LCB3b3VsZCB0aGF0IGFkZHJlc3MgdGhlIGNvbmNlcm4/PGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KQnV0LCBDSS9UIGNvdWxkIGFsc28gYmUgZGVwbG95ZWQgdG8gcnVuIG92ZXIgYSBW UE4gb3IgcHJpdmF0ZSBuZXR3b3JrPGJyIGNsYXNzPSIiPg0KYmV0d2VlbiB0d28gaW50ZXJjb25u ZWN0ZWQgQ0ROcywgaW4gc3VjaCBhbiBlbnZpcm9ubWVudCBIVFRQUyB0cmFuc3BvcnQ8YnIgY2xh c3M9IiI+DQp3b3VsZCBub3QgaGF2ZSB0aGUgc2FtZSBiZW5lZml0cy48YnIgY2xhc3M9IiI+DQo8 L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpZZXMsIHRoYXTigJlzIG15IHBvaW50LiBTYXkg ZXhwbGljaXRseSB0aGF0IEludGVybmV0IGlzIGFuIGV4YW1wbGUgb2YgZW52aXJvbm1lbnQgd2hl cmU8YnIgY2xhc3M9IiI+DQpzdWNoIGEgcHJvdGVjdGlvbiBpcyBtYW5kYXRvcnkuPGJyIGNsYXNz PSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KSW4gJnF1b3Q7LTEyJnF1b3Q7IEkn dmUgYWxpZ25lZCB0aGUgdGV4dCBhYm92ZSB3aXRoIHRoZSB0ZXh0IHVzZWQgaW4gdGhlIGNkbmkt bWV0YWRhdGEgZHJhZnQ6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7VExTIE1V U1QgYmUgdXNlZCBieSB0aGUgc2VydmVyLXNpZGUgKGRDRE4pIGFuZCB0aGUgY2xpZW50LXNpZGUg KHVDRE4pIG9mPGJyIGNsYXNzPSIiPg0KJm5ic3A7dGhlIENJL1QgaW50ZXJmYWNlLCBpbmNsdWRp bmcgYXV0aGVudGljYXRpb24gb2YgdGhlIHJlbW90ZSBlbmQsIHVubGVzczxiciBjbGFzcz0iIj4N CiZuYnNwO2FsdGVybmF0ZSBtZXRob2RzIGFyZSB1c2VkIGZvciBlbnN1cmluZyB0aGUgY29uZmlk ZW50aWFsaXR5IG9mIHRoZTxiciBjbGFzcz0iIj4NCiZuYnNwO2luZm9ybWF0aW9uIGluIHRoZSBD SS9UIGludGVyZmFjZSByZXF1ZXN0cyBhbmQgcmVzcG9uc2VzIChzdWNoIGFzIHNldHRpbmc8YnIg Y2xhc3M9IiI+DQombmJzcDt1cCBhbiBJUHNlYyB0dW5uZWwgYmV0d2VlbiB0aGUgdHdvIENETnMg b3IgdXNpbmcgYSBwaHlzaWNhbGx5IHNlY3VyZWQ8YnIgY2xhc3M9IiI+DQombmJzcDtpbnRlcm5h bCBuZXR3b3JrIGJldHdlZW4gdHdvIENETnMgdGhhdCBhcmUgb3duZWQgYnkgdGhlIHNhbWUgY29y cG9yYXRlPGJyIGNsYXNzPSIiPg0KJm5ic3A7ZW50aXR5KS48YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQpJIHRoaW5rIHRoYXQgY292ZXJzIGl0IGJldHRlciAoPykuPGJyIGNsYXNzPSIiPg0K PC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+VGhpcyBpcyBt dWNoIGJldHRlci4gSnVzdCBhIG1pbm9yIGNvbW1lbnQ6ICZxdW90Oy4uLiBmb3IgaW5zdXJpbmcg dGhlIHNlY3VyaXR5JnF1b3Q7IGluc3RlYWQgb2Y8L2Rpdj4NCjxkaXY+JnF1b3Q7Li4uIGZvciBl bnN1cmluZyB0aGUgY29uZmlkZW50aWFsaXR5JnF1b3Q7LCBzaW5jZSBjb25maWRlbnRpYWxpdHkg aXMgb25seSBvbmUgYXNwZWN0IG9mIHNlY3VyaXR5LjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjItIFNlY3Rp b24gOC4xLCBwbGVhc2UgY2hlY2sgdGhlIHBhcmFncmFwaCDCqyBOb3RlIHRoYXQgaW4gYSDCqyBk aWFtb25kIMK7PGJyIGNsYXNzPSIiPg0KY29uZmlndXJhdGlvbiBb4oCmXSDCuy4gVGhpcyBwYXJh Z3JhcGggaXMgcmF0aGVyIGNvbmZ1c2luZyB0byBtZS4gQ29uZnVzaW9uPGJyIGNsYXNzPSIiPg0K Y29tZXMgZnJvbTo8YnIgY2xhc3M9IiI+DQotIHRoZSBsYWNrIG9mIGRlc2NyaXB0aW9uIG9mIHRo ZSDCqyBkaWFtb25kIGNvbmZpZ3VyYXRpb24gwrsuIEkgdW5kZXJzdGFuZDxiciBjbGFzcz0iIj4N CnRoZXJlIGlzIG9uZSBkQ0ROIG9uIHRvcCBhbmQgbXVsdGlwbGUgdUNETiBkaXJlY3RseSBjb25u ZWN0ZWQgYmVsb3csIGFtIEk8YnIgY2xhc3M9IiI+DQpyaWdodD88YnIgY2xhc3M9IiI+DQo8L2Js b2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpZZXMsIHRoYXQncyByaWdodC4gVGhlIGRyYWZ0IHNh eXM6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Tm90ZSB0aGF0IGluIGEgJnF1 b3Q7ZGlhbW9uZCZxdW90OyBjb25maWd1cmF0aW9uLCB3aGVyZSBvbmUgdUNETidzIGNvbnRlbnQg Y2FuPGJyIGNsYXNzPSIiPg0KJm5ic3A7YmUgYWNxdWlyZWQgdmlhIG1vcmUgdGhhbiBvbmUgZGly ZWN0bHktY29ubmVjdGVkIHVDRE4sPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KV291bGQg dGhlIGZvbGxvd2luZyByZWFycmFuZ2VtZW50IGhlbHA/IC4uLjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCiZuYnNwO0EgJnF1b3Q7ZGlhbW9uZCZxdW90OyBjb25maWd1cmF0aW9uIGlzIG9u ZSB3aGVyZSBhIGRDRE4gY2FuIGFjcXVpcmUgYSB1Q0ROJ3M8YnIgY2xhc3M9IiI+DQombmJzcDtj b250ZW50IHZpYSBtb3JlIHRoYW4gb25lIGRpcmVjdGx5LWNvbm5lY3RlZCB1Q0ROLiBOb3RlIHRo YXQ8YnIgY2xhc3M9IiI+DQombmJzcDtpbiBhIGRpYW1vbmQgY29uZmlndXJhdGlvbiBb4oCmXTxi ciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NClllcywgSSBwcmVmZXIg dGhpcyB2ZXJzaW9uLiBIb3dldmVyLCBjYW4gdGhlIHNhbWUgwqsgdUNETuKAmXMgY29udGVudCDC uyBiZTxiciBjbGFzcz0iIj4NCmF2YWlsYWJsZSBhdCBzZXZlcmFsIHVDRE5zIGluIHRoaXMgZGlh bW9uZCBjb25maWd1cmF0aW9uPyBTYWlkIGRpZmZlcmVudGx5LDxiciBjbGFzcz0iIj4NCndoYXQg YWJvdXQgdGhlIGZvbGxvd2luZyB0ZXh0OjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxz cGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOiBwcmU7Ij48L3Nw YW4+QSDCqyBkaWFtb25kIMK7IGNvbmZpZ3VyYXRpb24gaXMgb25lIHdoZXJlIGEgZENETiBjYW4g YWNxdWlyZSBhIGdpdmVuPGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFu IiBzdHlsZT0id2hpdGUtc3BhY2U6IHByZTsiPjwvc3Bhbj5jb250ZW50IHZpYSBtb3JlIHRoYW4g b25lIGRpcmVjdGx5LWNvbm5lY3RlZCB1Q0ROLiBOb3RlIHRoYXQgW+KApl08YnIgY2xhc3M9IiI+ DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpZZXMsIG1vcmUgdGhhbiBvbmUgdUNETiB3 aWxsIGhhdmUgdGhlIHNhbWUgY29udGVudCAtIGJ1dCB0aGUgaW1wb3J0YW50IHBvaW50IGlzIHRo YXQgdWx0aW1hdGVseSB0aGV5IHdpbGwgYWxsIGhhdmUgYWNxdWlyZWQgaXQgZnJvbSB0aGUgc2Ft ZSB1Q0ROLCBhbmQgdGhhdCB1Q0ROIG93bnMgdGhlIG1ldGFkYXRhLjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCkkndmUgdHJpZWQgdG8gcHJvdmlkZSBhIGJldHRlciBpbnRyby9leHBsYW5h dGlvbiBpbiBuZXcgc2VjdGlvbiAyLjIuMSAmcXVvdDtNdWx0aXBsZSBpbnRlcmNvbm5lY3RlZCBD RE5zJnF1b3Q7LiBIb3BlZnVsbHkgdGhhdCBtYWtlcyBpdCBhIGJpdCBjbGVhcmVyPzxiciBjbGFz cz0iIj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2Plll cywgYXMgc2FpZCBhYm92ZSwgc2VjdGlvbiAyLjIuMSBpcyByYXRoZXIgdXNlZnVsLjwvZGl2Pg0K PGRpdj5KdXN0IGEgY29tbWVudCBmb3IgdGhpcyBzZWN0aW9uIDIuMi4xLCB0aGlyZCBwYXJhZ3Jh cGgsIGxhc3Qgc2VudGVuY2UuIFlvdSBtZW50aW9uPC9kaXY+DQo8ZGl2PmJvdGggJnF1b3Q7aW50 ZXJtZWRpYXRlIENETiZxdW90OyBhbmQganVzdCBhZnRlciAmcXVvdDtpbnRlcm1lZGlhdGUgdUNE TiZxdW90Oy4gVGhpcyBpcyBhIGJpdCBjb25mdXNpbmcuPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdj5Bbm90aGVyIGRldGFpbDogaW4gc2Vjb25kIHBhcmFncmFwaCB5b3Ug bWVudGlvbiAmcXVvdDsmcXVvdDtpbnRlcm1lZGlhdGUmcXVvdDsgQ0ROJnF1b3Q7IHdpdGggZXh0 cmEgJnF1b3Q7ICZxdW90OzwvZGl2Pg0KPGRpdj5hcm91bmQgaW50ZXJtZWRpYXRlLiBQbGVhc2Ug aGFybW9uaXplLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xh c3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4zLSBXaXRoIHRoaXMgwqsg ZGlhbW9uZCBjb25maWd1cmF0aW9uIMK7LCBzaW5jZSBzZXZlcmFsIHVDRE4gY2FuIGFjdCB1cG9u IHRoZTxiciBjbGFzcz0iIj4NCnNhbWUgY29udGVudCwgd2hhdCBoYXBwZW5zIGlmIHRoZXkgYmVo YXZlIGluIGEgbm9uIGNvb3JkaW5hdGVkIG1hbm5lciAoaS5lLiw8YnIgY2xhc3M9IiI+DQppbiB0 aGUgZ2VuZXJhbCBjYXNlKT8gRm9yIGluc3RhbmNlIGxldOKAmXMgaW1hZ2luZSBvbmUgb2YgdGhl bSBhc2tzIHRoZSBkQ0ROPGJyIGNsYXNzPSIiPg0KdG8gZGVsZXRlIHRoZSBjb250ZW50IG9yIGNh bmNlbCB0aGUgaW5pdGlhbCBjb21tYW5kLiBXaGF0IGhhcHBlbnMgaWYgYW5vdGhlcjxiciBjbGFz cz0iIj4NCnVDRE4gdGhlbiBhc2tzIHRoZSBkQ0ROIHRvIGludmFsaWRhdGUgdGhpcyBjb250ZW50 LCBwcm92aWRpbmcgdGhlIFVSTCBvZiB0aGU8YnIgY2xhc3M9IiI+DQpUcmlnZ2VyIFN0YXR1cyBS ZXNvdXJjZSB3aGljaCAoaWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSkgaXMgbm8gbG9uZ2VyIHZh bGlkPzxiciBjbGFzcz0iIj4NClRoaXMgwqsgZGlhbW9uZCBjb25maWd1cmF0aW9uIMK7IGNhbiBi ZSBhIGxpdHRsZSBiaXQgdHJpY2t5IGFuZCBubyBjbGVhcjxiciBjbGFzcz0iIj4NCmd1aWRlbGlu ZSBpcyBwcm92aWRlZCBpbiB0aGUgZG9jdW1lbnQuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3Rl Pg0KPGJyIGNsYXNzPSIiPg0KQSB0cmlnZ2VyIHN0YXR1cyByZXNvdXJjZSBiZWxvbmdzIHRvIG9u ZSB1Q0ROIGFuZCBjYW5ub3QgYmUgYWNjZXNzZWQgb3I8YnIgY2xhc3M9IiI+DQptYW5pcHVsYXRl ZCBieSBhbnkgb3RoZXIgQ0ROLCBzZWN0aW9uIDMgcGFyYSAzIHNheXM6PGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KJm5ic3A7VHJpZ2dlciBTdGF0dXMgUmVzb3VyY2VzIGJlbG9uZ2luZyB0 byBhIHVDRE4gTVVTVCBOT1Q8YnIgY2xhc3M9IiI+DQombmJzcDtiZSB2aXNpYmxlIHRvIGFueSBv dGhlciBDRE4uIFRoZSBkQ0ROIGNvdWxkLCBmb3IgZXhhbXBsZSwgYWNoaWV2ZTxiciBjbGFzcz0i Ij4NCiZuYnNwO3RoaXMgYnkgb2ZmZXJpbmcgZGlmZmVyZW50IGNvbGxlY3Rpb24gVVJMcyB0byBl YWNoIHVDRE4sIGFuZC9vciBieTxiciBjbGFzcz0iIj4NCiZuYnNwO2ZpbHRlcmluZyB0aGUgcmVz cG9uc2UgYmFzZWQgb24gdGhlIHVDRE4gd2l0aCB3aGljaCB0aGUgSFRUUCBjbGllbnQ8YnIgY2xh c3M9IiI+DQombmJzcDtpcyBhc3NvY2lhdGVkLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4N CjxiciBjbGFzcz0iIj4NCkkgc2Vl4oCmIEhvd2V2ZXIsIGlmIG11bHRpcGxlIHVDRE5zIGNhbiBh Y3Qgb24gdGhlIHNhbWUgY29udGVudCAod2hhdCBpcyBzYWlkKSw8YnIgY2xhc3M9IiI+DQpldmVu IGlmIGVhY2ggdUNETiB1c2VzIGEgZGlmZmVyZW50IFVSTCwgd2lsbCBzaW11bHRhbmVvdXMgQ0kv VCBjb21tYW5kcyBmb3I8YnIgY2xhc3M9IiI+DQp0aGUgc2FtZSBjb250ZW50IGJlIG1hbmFnZWQg Y29ycmVjdGx5PyBUaGlzIGlzIG5vdCBzYWlkIGluIHNlY3Rpb24gMzxiciBjbGFzcz0iIj4NCnBh cmFncmFwaCAzIGVpdGhlciBhbmQgdGhpcyBpcyBhIGtleSBwb2ludC48YnIgY2xhc3M9IiI+DQo8 L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpTb3JyeSwgSSdkIG1pc3NlZCB5b3VyIHBvaW50 LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkludGVyYWN0aW9ucyBjYW4gYmUgaW5lZmZp Y2llbnQsIGJ1dCBhcmUgb3RoZXJ3aXNlIGhhcm1sZXNzIGJlY2F1c2UgdGhlIHN0cm9uZ2VzdCBv ZiAmcXVvdDtpbnZhbGlkYXRlJnF1b3Q7IG9yICZxdW90O3B1cmdlJnF1b3Q7IHdpbGwgd2luLCBh bmQgY29udGVudCBjYW4gYWx3YXlzIGJlIHJlLWFjcXVpcmVkIGlmIGl0J3Mgc3RpbGwgYXZhaWxh YmxlIGZyb20gYW55IHVDRE4uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSSd2ZSBnaXZl biBzb21lIGV4YW1wbGVzIGluIG5ldyBzZWN0aW9uIDIuMi4xICZxdW90O011bHRpcGxlIGludGVy Y29ubmVjdGVkIENETnMmcXVvdDssIGFuZCBhZGRlZCBhIHBvaW50ZXIgdG8gdGhhdCBmcm9tIHRo ZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uLjxiciBjbGFzcz0iIj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2Pk9uY2UgYWdhaW4sIHRoZSBl eGFtcGxlcyBvZiBzZWN0aW9uIDIuMi4xIGFuc3dlciBteSBjb21tZW50cy4gVGhhbmtzLjwvZGl2 Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5Db250ZW50IGFsd2F5cyBvcmlnaW5h dGVzIGZyb20gb25lIHVDRE4sIGJ1dCBpbiBhIGRpYW1vbmQgY29uZmlncmF0aW9uIHRoZXJlPGJy IGNsYXNzPSIiPg0KbWF5IGJlIG11bHRpcGxlIHJvdXRlcyAodmlhIG90aGVyIENETnMpIHRvIGEg Z2l2ZW4gZENETi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGUgbW9zdCBjb21tb24g c2NlbmFyaW8gbWF5IHdlbGwgYmUgdGhhdCB0aGUgdUNETiB3aWxsIGluaXRpYXRlIGFsbCBvZiB0 aGU8YnIgY2xhc3M9IiI+DQpDSS9UIGNvbW1hbmRzIHJlbGF0ZWQgdG8gaXRzIGNvbnRlbnQsIGFu ZCB0aG9zZSBjb21tYW5kcyB3aWxsIHNpbXBseSBiZTxiciBjbGFzcz0iIj4NCmZvcndhcmRlZCBi eSBpbnRlcm1lZGlhdGUgQ0ROcy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpCdXQsIHRo ZXJlJ3Mgbm90aGluZyB0byBzdG9wIGFuIGludGVybWVkaWF0ZSBDRE4gaW5pdGlhdGluZyBvciBt b2RpZnlpbmc8YnIgY2xhc3M9IiI+DQpDSS9UIGNvbW1hbmRzIC0gYW5kIHNvbWUgbW9kaWZpY2F0 aW9ucyBvZiB0aGUgY29tbWFuZCB3aWxsIGJlIG5lY2Vzc2FyeTxiciBjbGFzcz0iIj4NCihmb3Ig ZXhhbXBsZSwgbWV0YWRhdGEgVVJMcyB3aWxsIG5lZWQgdG8gYmUgY2hhbmdlZCkuPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KQnkgYW5hbHlzaXMgb2YgbG9nIGZpbGVzIGl0IHdpbGwgcHJv YmFibHkgYmUgcG9zc2libGUgdG8gd29yayBvdXQgd2hpY2g8YnIgY2xhc3M9IiI+DQp1Q0ROIGFu IGluZGl2aWR1YWwgY2FjaGUgaW4gdGhlIGRDRE4gYWNxdWlyZWQgZWFjaCBjYWNoZWQgcmVzb3Vy Y2UgZnJvbS48YnIgY2xhc3M9IiI+DQpCdXQgdGhlIGNhY2hlIGlzIG5vdCByZXF1aXJlZCB0byBr ZWVwIGEgbGl2ZSByZWNvcmQgb2YgdGhhdCwgYW5kIGl0PGJyIGNsYXNzPSIiPg0KcHJvYmFibHkg d29uJ3QuIEluIHRoYXQgY2FzZSwgd2hlbiBpdCByZWNlaXZlcyBhIENJL1QgY29tbWFuZCB0byBp bnZhbGlkYXRlPGJyIGNsYXNzPSIiPg0Kb3IgcHVyZ2UgY29udGVudCwgdGhlIGRDRE4gc2hvdWxk IGFwcGx5IHRoYXQgY29tbWFuZCB0byBhbnkgY29udGVudCBpdDxiciBjbGFzcz0iIj4NCm1heSBo YXZlIGFjcXVpcmVkIGZyb20gdGhlIHVDRE4gaXQgZ290IHRoZSBDSS9UIGNvbW1hbmQgZnJvbS48 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpTbyB0aGVyZSBpcyBzY29wZSBmb3IgYSBtYWxp Y2lvdXMgaW50ZXJtZWRpYXRlIENETiB0byBjYXVzZSBleHRyYSBwcm9jZXNzaW5nPGJyIGNsYXNz PSIiPg0KYW5kIGFjcXVpc2l0aW9uIGJ5IGEgZENETiAoYW5kIHRoYXQncyBtZW50aW9uZWQgaW4g c2VjdGlvbiA4KS4gQnV0IGE8YnIgY2xhc3M9IiI+DQptYWxpY2lvdXMgQ0ROIGlzIGxpa2VseSB0 byBmaW5kIGl0c2VsZiByZW1vdmVkIGZyb20gdGhlIENETiBmZWRlcmF0aW9uIGZhaXJseTxiciBj bGFzcz0iIj4NCnF1aWNrbHkgLSB0aGVyZSB3aWxsIG5lY2Vzc2FyaWx5IGJlIGEgbGV2ZWwgb2Yg dHJ1c3QgYmV0d2VlbiBpbnRlcmNvbm5lY3RlZDxiciBjbGFzcz0iIj4NCkNETnMuPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KV291bGQgaXQgaGVscCB0byBzcGVsbCBvdXQgc29tZSBvZiB0 aGF0IGluIHRoZSBkcmFmdD8gKFRoZSBzYW1lIG9yIHZlcnk8YnIgY2xhc3M9IiI+DQpzaW1pbGFy IHRleHQgaGFzIGJlZW4gdXNlZCBpbiBzZXZlcmFsIG9mIHRoZSBDRE5JIGRyYWZ0cy4pPGJyIGNs YXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KWWVzLCB0aGlzIHBhcmFncmFw aCBpcyB3b3J0aCBiZWluZyBkZXRhaWxlZCBhIGxpdHRsZSBiaXQuPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KSW4geW91ciBleHBsYW5hdGlvbnMgeW91IG1lbnRpb24gaW50ZXJtZWRpYXRl IENETnMgd2hpbGUgb3JpZ2luYWwgdGV4dCBvbmx5PGJyIGNsYXNzPSIiPg0KbWVudGlvbnMgZGly ZWN0bHkgY29ubmVjdGVkIHVDRE5zLiBUaGUgbm90aW9uIG9mIMKrIGludGVybWVkaWF0ZSBDRE4g wrsgaXM8YnIgY2xhc3M9IiI+DQpvbmx5IGRpc2N1c3NlZCBpbiBzZWN0aW9ucyAyLjMgYW5kIDQu OC4gU2luY2UgbWFsaWNpb3VzIGludGVybWVkaWF0ZSBDRE5zIGFyZTxiciBjbGFzcz0iIj4NCnBh cnQgb2YgYSB2YWxpZCBhdHRhY2sgbW9kZWwsIGl0IGlzIHdvcnRoIHRvIGV4cGxhaW4gaXQgKG9y IGdpdmUgYSByZWZlcmVuY2UgdG8gYW5vdGhlcjxiciBjbGFzcz0iIj4NCmRvY3VtZW50KS48YnIg Y2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpXaGVuIGEgY29udGVudCBv d25lciwgdGhlIG9yaWdpbiwgZGVsZWdhdGVzIGRlbGl2ZXJ5IHRvIGEgQ0ROIGl0IGlzIHRydXN0 aW5nIHRoYXQgQ0ROIHRvIGRlbGl2ZXIgdGhlIHJpZ2h0IGNvbnRlbnQgb24gaXRzIGJlaGFsZi4g QSBtYWxpY2lvdXMgQ0ROIGNvdWxkIGRlbGl2ZXIgYW55dGhpbmcgaW5zdGVhZCwgYnV0IGl0IHdv dWxkIHNvb24gbG9zZSB0aGUgdHJ1c3Qgb2YgdGhlIG9yaWdpbi48YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpDRE4taW50ZXJjb25uZWN0aW9uIHNpbXBseSBleHRlbmRzIHRoYXQgdHJ1c3Qg dG8gdGhlIGZ1cnRoZXItZG93bnN0cmVhbSBDRE5zIGFjdGluZyBvbiBiZWhhbGYgb2YgdGhlIG9y aWdpbmFsLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClNvIGVzdGFibGlzaG1lbnQvZW5m b3JjZW1lbnQgb2YgdGhlIHRydXN0IHJlbGF0aW9uc2hpcCBpdHNlbGYsIHRoZSBjb250cmFjdCBi ZXR3ZWVuIHRoZSBvcmlnaW4gYW5kIHRoZSBDRE4sIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIENE TkkgYW5kIGluIHRoZSBsYW5kIG9mIGNvbW1lcmNpYWwgYWdyZWVtZW50cy48YnIgY2xhc3M9IiI+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5TdXJlLCBJ IGFncmVlLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPkkndmUgYWRkZWQgYSBub3RlIG9uIHRo YXQgaW4gdGhlIGludHJvIHRvIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uLjxi ciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2PlRoYXQncyBwZXJmZWN0LjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGIgY2xhc3M9IiI+VG8gY29uY2x1ZGUgdGhlIGRvY3VtZW50IGlzIG9rYXkgZnJvbSBt eSBwb2ludCBvZiB2aWV3LjwvYj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoYW5rcyBmb3IgeW91ciBkZXRhaWxlZCBhbnN3ZXJzLjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj5DaGVlcnMsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7VmluY2VudDwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CD009C877BB844A09D0E5C6BD1903BBEalcatellucentcom_-- From nobody Sun Apr 10 04:54:21 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69AC12D096 for ; Sun, 10 Apr 2016 04:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEdK_s_VE3Bk for ; Sun, 10 Apr 2016 04:54:13 -0700 (PDT) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B18412B03D for ; Sun, 10 Apr 2016 04:54:13 -0700 (PDT) Received: by mail-qg0-x232.google.com with SMTP id c6so124399485qga.1 for ; Sun, 10 Apr 2016 04:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=77Mus8RfAkLENS88V+IVdzrxd/kyM9+nv5sD22behEA=; b=X0GtnjLn4Qv7G8as68S2C01gTuHPgehZNhgPUDY5nQ5DXp7AxrM4TPz7omMZJKH/Y/ 8nIFvkstvSWxqC73gjd/xQVxBPXphzkKtR8fNctPN14OQOJVUPTIzkDhm4bwur7d2gOE N5CKSNH0bCLjyMKLYhA83iMkU2KqNXYJYjQzA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=77Mus8RfAkLENS88V+IVdzrxd/kyM9+nv5sD22behEA=; b=WQbZQCgjv68N2VGelklY9F0oGylqAGljIfk7sNv46cDuWSvr92iXl4df4VI53WkWy5 tItquuH8nPQSX3/UKcRSFa54cDFH5qvfdR62svnLUgiEIMr6ZO8srP/8xxNmB/c0rzZ6 XrGc2Ao67Uy1oX6hyS/LXC0cGzEy+EVEloaVSUCeg+c/O+vDQxhLEHg96jrYJdOj+vgT ROTklPnP5OROmfYamyoeYZfqqce/IWSnFWDGQBHe59+U4iJdV3NmTOl9dxb9JGqiSy9o PbtP8BJRoVuFBERTH+gnJ+IFuiRccZDJhHg6Hap5Ydq553Yb36WGlzBTPmANQOynmPs5 wfvg== X-Gm-Message-State: AD7BkJLYcDmg2twn3PM1TDtz3swOPKGIHYhG6fwgurrHLVa+qaxkpM1r92R235ruSPV+2g== X-Received: by 10.140.28.117 with SMTP id 108mr21984851qgy.40.1460289252624; Sun, 10 Apr 2016 04:54:12 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:8934:95dd:bb20:272c? ([2001:67c:370:176:8934:95dd:bb20:272c]) by smtp.gmail.com with ESMTPSA id l126sm9099945qhb.30.2016.04.10.04.54.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 10 Apr 2016 04:54:12 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: Date: Sun, 10 Apr 2016 08:54:08 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2A372E02-DC5C-4791-91D8-20D4949D6383@sn3rd.com> References: To: Samu Varjonen X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-hip-rfc6253-bis.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-hip-rfc6253-bis X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2016 11:54:16 -0000 Thanks for the reminder: > On Feb 12, 2016, at 08:47, Samu Varjonen = wrote: >> Nits: >>=20 >> nit 1: I read this a couple of times: >> CERT parameters with the same Cert group number >> in the group field indicate a logical grouping. >> Isn=E2=80=99t it that the same group # is in the Cert group field:? >> CERT parameters with the same number >> in the Cert group field indicate a logical grouping. >=20 > Is this about missing CERT word in the group field? Or did I = misunderstand this question? Yeah this is completely editorial; I think =E2=80=9CCert=E2=80=9D is = just in the wrong place. Might be wrong. spt= From nobody Sun Apr 10 15:51:45 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F47C12D188; Sun, 10 Apr 2016 15:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6u8u75lHUtw; Sun, 10 Apr 2016 15:51:38 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6965812D185; Sun, 10 Apr 2016 15:51:38 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id s79so188978971oie.1; Sun, 10 Apr 2016 15:51:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=B+7nvTFmE4Euu/mMEUHh2P4AI3qZlRbJdrHl+rmgt3U=; b=NIlRXH6IeO2DMnImVeyJ1lQUAFRLnupBs75Zeah93nTpsV99R8RusNLTbYuJ+gQOzR N7bAAeZXvgrDXbrA1CRvOmcNhYPcSZx2a4NtqEXGVi487ZC9hhHPV36bsGufkSQwYdT+ FYo9o1kmMXPegsoZG3y6Zd7PbaD3W6pypcKP+T24f3Ab5VD2huOfOx4TtdSzqHNImbbq +c2ktiKAPmkc3VldrmVc/JPtv61WzDH3x64nq8HlzWy5SgK1ABxRl3rhHhzOO80za33T 9l87taXmPx32ba8xA2qIem/pTSdOYNyDjbFpfAtWWcV+ZLjFpFhATypqTO3oTOI92W4q 1SYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=B+7nvTFmE4Euu/mMEUHh2P4AI3qZlRbJdrHl+rmgt3U=; b=Igz7ko6/5O2MOwU/8eQvmTWTE9kHyVsUPr8iiJ0rQHs7vPCD0t6ezwbRHdBMTLDlYQ yd8SpmViD0CdlVoPjlsDAnRAsr1XCVfYX0Z5xS3niXLYP3my/5qrg7WYKouwWxwyKohb uoI2cUcXrP6jGAqFbFppLbi5nIDpEvlqzky1/8cOkNaqkjB0r2w1A3nrbF+SFbNOCj5y 5snJUv/+GZQ/fDPfGGw924K1tXZKZFuumSNRwO6niqQYAZQ7HNV8SWyoRC/M9YxRiSOG JbIGbxdFSocx+Ck8iunYM3OuNwv9ysoqs6eIgLvJDNnGICBx3xh6W4lkEyO48mojf19T 9N8g== X-Gm-Message-State: AD7BkJJ5tM3rGIAvRU6bulFKUa+suO6J2pTLtW3iali/aHT3bgYlIz5fVFv4+7uPewDkSw== X-Received: by 10.202.208.131 with SMTP id h125mr8641082oig.87.1460328697878; Sun, 10 Apr 2016 15:51:37 -0700 (PDT) Received: from Chriss-Air.attlocal.net ([2602:306:838b:1c40:94d7:17ff:a442:78f2]) by smtp.googlemail.com with ESMTPSA id 38sm3624689otu.34.2016.04.10.15.51.36 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 10 Apr 2016 15:51:37 -0700 (PDT) To: Michael Richardson , Nancy Cam-Winget References: <5702F8DE.8000809@gmail.com> <439.1459896488@obiwan.sandelman.ca> From: Chris Lonvick Message-ID: <570AD8F8.1060204@gmail.com> Date: Sun, 10 Apr 2016 17:51:36 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <439.1459896488@obiwan.sandelman.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-roll-applicability-ami.all@ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-roll-applicability-ami-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2016 22:51:40 -0000 Hi Michael, On 4/5/16 5:48 PM, Michael Richardson wrote: > > Some very small nits that the authors may want to consider: > > - the terms DODAG, DIO, and DAO are not expanded anywhere. (Yeah, I > > know I could go look them up... ;-) > > They are common terms from RFC6550 which is our core document. > Would it work to say that they are from RFC6550 and rfc7102? > > I'm thinking it would be a lot easier to just expand them the first time they're used in the document. That's how all the other acronyms are treated. Regards, Chris From nobody Sun Apr 10 22:47:57 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4275C12E547; Sun, 10 Apr 2016 22:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDbnBliIpXi2; Sun, 10 Apr 2016 22:47:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF08512E546; Sun, 10 Apr 2016 22:47:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHD19103; Mon, 11 Apr 2016 05:47:49 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 11 Apr 2016 06:47:48 +0100 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.36]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0235.001; Mon, 11 Apr 2016 13:47:40 +0800 From: "Xialiang (Frank)" To: "iesg@ietf.org" , "secdir@ietf.org" , "draft-alakuijala-brotli.all@tools.ietf.org" Thread-Topic: secdir review of draft-alakuijala-brotli-08 Thread-Index: AdGTthpEGuVvRaAtQJGDUJWf2eunBw== Date: Mon, 11 Apr 2016 05:47:40 +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.46.118.22] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12AF2C416SZXEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.570B3A85.0037, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.36, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f24ef62e69fc6be5a6408a62c5de0973 Archived-At: Subject: [secdir] secdir review of draft-alakuijala-brotli-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 05:47:54 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F12AF2C416SZXEMA502MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This document defines a lossless compressed data format that compresses dat= a using a combination of the LZ77 algorithm and Huffman coding, with effici= ency comparable to the best currently available general-purpose compression= methods. The document appears in reasonably good shape. In general, this document specify a new compressed data format which is use= d in the end points of a connection, which is not directly subject to netwo= rk security issues. In other words, the compressed contents can be protecte= d by all the existing security technologies (i.e., encryption, authenticati= on/authorization, anti-attack, etc) if necessary. The main security concern= is about how the bad (or faked) compressed data will attack the end system= , such as: buffer overflow and resource consumption! Some of the concerns a= re covered in the "Security Considerations" section. But there are still several security issues (TBDs) missing in the document = that need to be addressed before publication. Below is a series of my comments, questions for your consideration. Discussion: Section 2 Right now, your compressed data format is mainly used for the http (see in = the IANA section). Have you considered whether it can also be applied to IP= compression? Comments: Section 11 In the security considerations section, there are still some serious securi= ty issues not mentioned: 1. Resource consumption to the system containing a decompressor implementat= ion: decompressing the invalid compressed data can make the decompressor sy= stem's resource (cpu, memory, storage) to be consumed greatly, how to prote= ct against this possible attack? 2. Resource consumption or buffer overflow to the system containing a compr= essor implementation: correspondingly, when a network proxy get some conten= ts and need to compress them using this format, how to protect against the = possible attacks when compressing the invalid (or faked) contents? Thank you. B.R. Frank --_000_C02846B1344F344EB4FAA6FA7AF481F12AF2C416SZXEMA502MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

 

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

 

 

This document defines a loss= less compressed data format that compresses data using a combination of the= LZ77 algorithm and Huffman coding, with efficiency comparable to the best = currently available general-purpose compression methods.

 

 

The document appears in reas= onably good shape.

 

In general, this document sp= ecify a new compressed data format which is used in the end points of a con= nection, which is not directly subject to network security issues. In other= words, the compressed contents can be protected by all the existing security technologies (i.e., encryption, = authentication/authorization, anti-attack, etc) if necessary. The main secu= rity concern is about how the bad (or faked) compressed data will attack th= e end system, such as: buffer overflow and resource consumption! Some of the concerns are covered in the <= span lang=3D"EN-US" style=3D"font-family:"Courier New"">“Security Considerations” section.

 

But there are still several = security issues (TBDs) missing in the document that need to be addressed be= fore publication.

 

 

Below is a series of my comm= ents, questions for your consideration.

 

 

Discussion: Section 2

Right now, your compressed d= ata format is mainly used for the http (see in the IANA section). Have you = considered whether it can also be applied to IP compression?

 

 

 

Comments: Section 11

In the security consideratio= ns section, there are still some serious security issues not mentioned:

1. Resource consumption to t= he system containing a decompressor implementation: decompressing the inval= id compressed data can make the decompressor system’s resource (cpu, memory, storage) to be consumed greatly, how to protect aga= inst this possible attack?

2. Resource consumption or b= uffer overflow to the system containing a compressor implementation: corres= pondingly, when a network proxy get some contents and need to compress them= using this format, how to protect against the possible attacks when compressing the invalid (or faked) contents?

 

 

 

Thank you.=

 

B.R.

Frank

 

--_000_C02846B1344F344EB4FAA6FA7AF481F12AF2C416SZXEMA502MBSchi_-- From nobody Mon Apr 11 08:19:40 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65EAF12F04C; Mon, 11 Apr 2016 08:19:39 -0700 (PDT) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZhQOSr93ama; Mon, 11 Apr 2016 08:19:37 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id D8DB612F04B; Mon, 11 Apr 2016 08:19:37 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 53F35F991; Mon, 11 Apr 2016 11:19:35 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id F2E7E20143; Mon, 11 Apr 2016 11:19:34 -0400 (EDT) From: Daniel Kahn Gillmor To: "Xialiang \(Frank\)" , "iesg\@ietf.org" , "secdir\@ietf.org" , "draft-alakuijala-brotli.all\@tools.ietf.org" In-Reply-To: References: User-Agent: Notmuch/0.21+124~gbf604e9 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Mon, 11 Apr 2016 11:19:34 -0400 Message-ID: <87bn5guq9l.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [secdir] secdir review of draft-alakuijala-brotli-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 15:19:39 -0000 On Mon 2016-04-11 01:47:40 -0400, "Xialiang (Frank)" wrote: > This document defines a lossless compressed data format that > compresses data using a combination of the LZ77 algorithm and Huffman > coding, with efficiency comparable to the best currently available > general-purpose compression methods. [...] > In general, this document specify a new compressed data format which > is used in the end points of a connection, which is not directly > subject to network security issues. In other words, the compressed > contents can be protected by all the existing security technologies > (i.e., encryption, authentication/authorization, anti-attack, etc) if > necessary. The main security concern is about how the bad (or faked) > compressed data will attack the end system, such as: buffer overflow > and resource consumption! Some of the concerns are covered in the > "Security Considerations" section. This list of security concerns doesn't cover a popular recent abuse of compression algorithms, which is an attacker getting to repeatedly mix arbitrary (attacker-supplied) data with secret data (passwords, cookies) that gets sent over an encrypted channel. An attacker who can do this and observe the length of the ciphertext can potentially reconstruct the secret data. See for example: https://en.wikipedia.org/wiki/CRIME If this compression algorithm is resistant to this attack (which i doubt), it should be stated so in the draft. If it is not resistant to the attack, then the draft should at least make note of the issue and pointedly suggest that applications compressing sensitive data before encrypted transport MUST NOT mix sensitive data with non-sensitive (potentially-attacker-supplied) data in the same compression stream. Or would separating sensitve/non-sensitive data in one stream into distinct meta-blocks be sufficient? i don't understand the encryption scheme well enough to know. Either way, the authors of the draft are likely in the best position to make that clear. Regards, --dkg From nobody Mon Apr 11 09:51:30 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9B6912DCB9 for ; Mon, 11 Apr 2016 09:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51SNtw2xn4XL for ; Mon, 11 Apr 2016 09:51:28 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B3FE12D941 for ; Mon, 11 Apr 2016 09:51:28 -0700 (PDT) Received: by mail-qg0-x22b.google.com with SMTP id j35so149233706qge.0 for ; Mon, 11 Apr 2016 09:51:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=K1XolAlQ5PM2s4t2CWNP+R3P1Dgm17po3jTZN3iMvbU=; b=TMjGUGduxq0jeZJmtYebbCheSBqErHEN5lPEFfKTvD6c22n2ZjMy0lg/NImPRz6RRg lG6TtfSj+7vllr+KETFGxOQzfrlx8HM2mCzoeUIac3pPCnEOA4dOcIQ7MshhFUDH85OI CdeW1LuRIFk0cuvuH9MXmtLn86yjRZvCsk8Z4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=K1XolAlQ5PM2s4t2CWNP+R3P1Dgm17po3jTZN3iMvbU=; b=GKlcBXzjw5g4os2XXwtrtprpbiDiCdQIC3QgurBeTg3D+sS7LFrShHesAXWDJc4SXy 6jW1TkcEtzD7zrm3hgjCxlZc9Dhjyh40BamA9QH9adfr7Rm9jGMj2HEILZycIBkqfLY4 Q45uQBHhUFz40aWgRaVnmLNA3p2SfPn7jSlDAY4fG6JrvFVZkjRRUvRo3X49wjErXHfX twe35KEedrEqMQJWbP2aZOe1iAvMLFsKKNMfFWlwneI3If0/1sYegpYG+CjmiAJ11oc4 2M8B6ONEBDBf5VfElyVA5+Ayl1NFWPBgUGn3Z8XJU8XY6TZjxD35AFmdY2rU2ZZ1LGA2 TVeQ== X-Gm-Message-State: AD7BkJIUwc+M4m/PzwvJeBcRDArbPm96xRS8L5q9ut47M3jOHvbCs9ymifi7dcKlzkQNHg== X-Received: by 10.140.86.112 with SMTP id o103mr31318486qgd.9.1460393487393; Mon, 11 Apr 2016 09:51:27 -0700 (PDT) Received: from [5.5.33.55] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id j185sm3541126qke.40.2016.04.11.09.51.25 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 11 Apr 2016 09:51:26 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <0C91ECA5-3412-4CEC-9A05-AEEAFCFC176D@sn3rd.com> Date: Mon, 11 Apr 2016 13:51:18 -0300 To: secdir@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [secdir] use .all@ietf.org X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 16:51:29 -0000 Before I go off and update the secdir wiki (assuming I can): Right now it says to use =E2=80=8B.all@tools.ietf.org in a = couple of places and we should really be using = =E2=80=8B.all@ietf.org spt= From nobody Mon Apr 11 16:12:51 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754D912F5CB for ; Mon, 11 Apr 2016 16:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqyPnzsR40qi for ; Mon, 11 Apr 2016 16:12:47 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F15012F5C5 for ; Mon, 11 Apr 2016 16:12:47 -0700 (PDT) X-AuditID: 12074422-c07ff70000007b1b-fa-570c2f6e97db Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id CD.E4.31515.E6F2C075; Mon, 11 Apr 2016 19:12:46 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u3BNCjdP002951; Mon, 11 Apr 2016 19:12:46 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u3BNCgI2012811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Apr 2016 19:12:45 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u3BNCgFK017435; Mon, 11 Apr 2016 19:12:42 -0400 (EDT) Date: Mon, 11 Apr 2016 19:12:41 -0400 (EDT) From: Benjamin Kaduk To: Sean Turner In-Reply-To: <0C91ECA5-3412-4CEC-9A05-AEEAFCFC176D@sn3rd.com> Message-ID: References: <0C91ECA5-3412-4CEC-9A05-AEEAFCFC176D@sn3rd.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1495984584-1460416361=:26829" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42IR4hTV1s3T5wk32N8pY3FlVSOzxYeFD1kc mDyWLPnJ5HHwIGMAUxSXTUpqTmZZapG+XQJXRsuiFewFm1krHi5ew9TAuJeli5GTQ0LAROLJ 37mMXYxcHEICbUwSX39vZ4NwNjJKPLk5BypziEli8a/JrBBOA6NE37ozTCD9LALaEjdeLGIH sdkEVCRmvtnIBmKLCChINB19ANTAwcEsICyx76gTSFhYwEhi4edWZhCbU8BWYtL5LWBjeAUc JWb1ngU7SUjARmL94wtgI0UFdCRW75/CAlEjKHFy5hMwm1kgUKJ55xrGCYwCs5CkZiFJQdjq Egc+XYSytSXu32xjW8DIsopRNiW3Sjc3MTOnODVZtzg5MS8vtUjXVC83s0QvNaV0EyMogNld lHYwTvzndYhRgINRiYf3xWWucCHWxLLiytxDjJIcTEqivHlCPOFCfEn5KZUZicUZ8UWlOanF hxglOJiVRHhX6QHleFMSK6tSi/JhUtIcLErivEGRx8KEBNITS1KzU1MLUotgsjIcHEoSvDdB GgWLUtNTK9Iyc0oQ0kwcnCDDeYCGnwUbXlyQmFucmQ6RP8Woy7Hgx+21TEIsefl5qVLivA91 gYoEQIoySvPg5oATz24m1VeM4kBvCfMeAaniASYtuEmvgJYwAS159o8TZElJIkJKqoFRbc9F jpVHt3os9g3flaD+6ZjukTey00u+8Z9V8Vid29z6MDzSbt1fZYbamrrMpqTM06ELdKYvNzvG wTBzd6j2cUmGOpe7gdUvc2fcvyNdrfWzfja/wqqcT8nB7stk/nWbzP0RUvnZhlEqSmH3lVnr BFXm9bMtPRj2OezAZM10yxuhIn+eXlmjxFKckWioxVxUnAgAY/zIlRcDAAA= Archived-At: Cc: secdir@ietf.org Subject: Re: [secdir] use .all@ietf.org X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 23:12:49 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1495984584-1460416361=:26829 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Mon, 11 Apr 2016, Sean Turner wrote: > Before I go off and update the secdir wiki (assuming I can): > > Right now it says to use =E2=80=8B.all@tools.ietf.org in a cou= ple of > places and we should really be using =E2=80=8B.all@ietf.org I believe that is correct (not that I am a particular authority on the matter). -Ben ---559023410-1495984584-1460416361=:26829-- From nobody Tue Apr 12 04:32:03 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 094E512E8C6 for ; Tue, 12 Apr 2016 04:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNkr5QWtWr8g for ; Tue, 12 Apr 2016 04:31:59 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B68212E53B for ; Tue, 12 Apr 2016 04:31:58 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u3CBVtvC016390 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Apr 2016 14:31:55 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u3CBVtrn008478; Tue, 12 Apr 2016 14:31:55 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22284.56491.78790.777571@fireball.acr.fi> Date: Tue, 12 Apr 2016 14:31:55 +0300 From: Tero Kivinen To: Sean Turner In-Reply-To: <0C91ECA5-3412-4CEC-9A05-AEEAFCFC176D@sn3rd.com> References: <0C91ECA5-3412-4CEC-9A05-AEEAFCFC176D@sn3rd.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: Cc: secdir@ietf.org Subject: [secdir] use .all@ietf.org X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 11:32:01 -0000 Sean Turner writes: > Before I go off and update the secdir wiki (assuming I can): >=20 > Right now it says to use =E2=80=8B.all@tools.ietf.org in a= couple > of places and we should really be using =E2=80=8B.all@ietf= .org=20 As far as I know both of them are working, so it might be better to use the ietf.org version. So feel free to fix the wiki. --=20 kivinen@iki.fi From nobody Tue Apr 12 08:13:59 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16CFD12EF27 for ; Tue, 12 Apr 2016 08:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kq7NDys2YQbS for ; Tue, 12 Apr 2016 08:13:57 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id C258B12EF20 for ; Tue, 12 Apr 2016 08:13:57 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 8534FF24013; Tue, 12 Apr 2016 11:13:57 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id gVkbHFkICAqw; Tue, 12 Apr 2016 10:58:49 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 0B115F2403B; Tue, 12 Apr 2016 11:13:45 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <22284.56491.78790.777571@fireball.acr.fi> Date: Tue, 12 Apr 2016 11:13:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8D729C09-BF3E-4F53-885D-E7915D951920@vigilsec.com> References: <0C91ECA5-3412-4CEC-9A05-AEEAFCFC176D@sn3rd.com> <22284.56491.78790.777571@fireball.acr.fi> To: Tero Kivinen Kivinen X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IETF SecDir Subject: Re: [secdir] use .all@ietf.org X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 15:13:59 -0000 the tools.ietf.org name now forwards to the ietf.org name. We will = eventually remove the one from tools. Russ On Apr 12, 2016, at 7:31 AM, Tero Kivinen wrote: > Sean Turner writes: >> Before I go off and update the secdir wiki (assuming I can): >>=20 >> Right now it says to use =E2=80=8B.all@tools.ietf.org in a = couple >> of places and we should really be using =E2=80=8B.all@ietf.o= rg=20 >=20 > As far as I know both of them are working, so it might be better to > use the ietf.org version. So feel free to fix the wiki. > --=20 > kivinen@iki.fi >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Tue Apr 12 09:16:21 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3594212D71D; Tue, 12 Apr 2016 09:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.046 X-Spam-Level: X-Spam-Status: No, score=-101.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_DYNAMIC_IPADDR=1.951, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=tobias.gondrom@gondrom.org header.d=gondrom.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id riH9rYpGIBnb; Tue, 12 Apr 2016 09:16:18 -0700 (PDT) Received: from lvps5-35-241-16.dedicated.hosteurope.de (www.gondrom.org [5.35.241.16]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F41512D953; Tue, 12 Apr 2016 09:16:17 -0700 (PDT) Received: from [192.168.43.211] (ip-109-43-3-20.web.vodafone.de [109.43.3.20]) by lvps5-35-241-16.dedicated.hosteurope.de (Postfix) with ESMTPSA id 05E2F63380; Tue, 12 Apr 2016 18:16:14 +0200 (CEST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=gy4hswCFIRqPBKPBnKsuTIiMo5XZoNLgI+lAJxWFsQKroj5xJKQe0CKbcsIjjC99dqq94mlvPTYOPeUQgNpSBqp48EKX8Erwy2rdGSz7tEWB4JTeLDHKLRFjnV6jte1u4y+oUf3k6tECJN6gjpn5QkhPfCxkubs1WQPlerobwcg=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Message-ID: <570D1F4D.6010306@gondrom.org> Date: Tue, 12 Apr 2016 18:16:13 +0200 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: dkg@fifthhorseman.net, frank.xialiang@huawei.com, iesg@ietf.org, secdir@ietf.org, draft-alakuijala-brotli.all@tools.ietf.org References: <87bn5guq9l.fsf@alice.fifthhorseman.net> In-Reply-To: <87bn5guq9l.fsf@alice.fifthhorseman.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] secdir review of draft-alakuijala-brotli-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 16:16:20 -0000 Dear Daniel, in my understanding this ID is _only_ about a compression, not about encryption. Therefore it is not even intended to be resistant to the attack you describe below. (for proper confidentiality the channel would need to be encrypted.) Best regards, Tobias On 11/04/16 17:19, Daniel Kahn Gillmor wrote: > On Mon 2016-04-11 01:47:40 -0400, "Xialiang (Frank)" wrote: >> This document defines a lossless compressed data format that >> compresses data using a combination of the LZ77 algorithm and Huffman >> coding, with efficiency comparable to the best currently available >> general-purpose compression methods. > [...] >> In general, this document specify a new compressed data format which >> is used in the end points of a connection, which is not directly >> subject to network security issues. In other words, the compressed >> contents can be protected by all the existing security technologies >> (i.e., encryption, authentication/authorization, anti-attack, etc) if >> necessary. The main security concern is about how the bad (or faked) >> compressed data will attack the end system, such as: buffer overflow >> and resource consumption! Some of the concerns are covered in the >> "Security Considerations" section. > This list of security concerns doesn't cover a popular recent abuse of > compression algorithms, which is an attacker getting to repeatedly mix > arbitrary (attacker-supplied) data with secret data (passwords, cookies) > that gets sent over an encrypted channel. An attacker who can do this > and observe the length of the ciphertext can potentially reconstruct the > secret data. > > See for example: > > https://en.wikipedia.org/wiki/CRIME > > If this compression algorithm is resistant to this attack (which i > doubt), it should be stated so in the draft. If it is not resistant to > the attack, then the draft should at least make note of the issue and > pointedly suggest that applications compressing sensitive data before > encrypted transport MUST NOT mix sensitive data with non-sensitive > (potentially-attacker-supplied) data in the same compression stream. Or > would separating sensitve/non-sensitive data in one stream into distinct > meta-blocks be sufficient? i don't understand the encryption scheme > well enough to know. Either way, the authors of the draft are likely in > the best position to make that clear. > > Regards, > > --dkg > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Tue Apr 12 09:49:52 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31E012D5F8; Tue, 12 Apr 2016 09:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.045 X-Spam-Level: X-Spam-Status: No, score=-101.045 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_DYNAMIC_IPADDR=1.951, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=tobias.gondrom@gondrom.org header.d=gondrom.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29KGgNh8538p; Tue, 12 Apr 2016 09:49:49 -0700 (PDT) Received: from lvps5-35-241-16.dedicated.hosteurope.de (www.gondrom.org [5.35.241.16]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BE9B12DAFB; Tue, 12 Apr 2016 09:49:49 -0700 (PDT) Received: from [192.168.43.211] (ip-109-43-3-20.web.vodafone.de [109.43.3.20]) by lvps5-35-241-16.dedicated.hosteurope.de (Postfix) with ESMTPSA id 5428063380; Tue, 12 Apr 2016 18:49:47 +0200 (CEST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=SHnkcsiVX7VxaglXwVs9xuRR2jKXTEI7W7mIRtSNyPiKQ65lNp8ILfiYuzKxUS0+zQPfqiuNEQWjEKOZ2lFOkjFpmMeK6nFB+y0g55mCcY4ctmR9LqhqPS8yp7LBJVLhia5HgvoejwekKn03t1VP0L8oigbOu8WBwM23a4DlIU0=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type; Message-ID: <570D272A.8090105@gondrom.org> Date: Tue, 12 Apr 2016 18:49:46 +0200 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: secdir@ietf.org, iesg@ietf.org Content-Type: multipart/alternative; boundary="------------090808070701090403000001" Archived-At: Cc: draft-ietf-bfd-seamless-use-case.all@ietf.org Subject: [secdir] secdir review of draft-ietf-bfd-seamless-use-case-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 16:49:51 -0000 This is a multi-part message in MIME format. --------------090808070701090403000001 Content-Type: text/plain; charset=utf-8; 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. The draft aims for informational and is about various use cases for Bidirectional Forwarding Detection (BFD) and various requirements. Note: Solutions to the identified uses cases and protocol specific enhancements are outside the scope of this document. If this document is seen as use case document only, it appears in good shape. However, it also includes a section 4 about requirements and it seems security requirements have not been considered among them. Maybe that is not intended or not necessary. I will leave that question up for the judgement by the WG. One main comment: 1. section 5: Security Considerations is empty as it states not to introduce any new protocols. In principle that is ok, as long as it is understood that the following proposed protocols for these use cases will need to answer to security considerations. However, as the document also speaks about requirements, it would have been nice to spell out specific security requirements that are to be considered from these use cases. Security requirements (from protection against malicious actors) should have been considered in section 4. Also the various use cases should be explored for whether they may expose a system to abuse. E.g. several requirements are stated as "MUST" (which btw. I am not sure is the proper use of RFC2119 definition). The question would be if a system will follow these requirements whether it would be exposed to additional security risks. E.g. Req#2 "MUST be able to establish a unidirectional BFD session without the bidirectional handshake", #3 "BFD session MUST be able to be established without the need for session negotiation". Overall I can see the request for these requirements. I would also like to see a discussion of their security implications and risks. nitbits: some of the language seems not so clean. Not outright wrong, but very hard to understand. Maybe some native speakers or the RFC editor can help clean this up: e.g. section 3.2 "All it takes is for the network entities to know what the discriminator values to be used for the session." I read this sentence a few times and not quite sure which words to add to match the intended meaning of the authors. ;-) Thank you and best regards. Tobias --------------090808070701090403000001 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 draft aims for informational and is about various use cases for Bidirectional Forwarding Detection (BFD) and various requirements.
Note: Solutions to the identified uses cases and protocol specific enhancements are outside the scope of this document.

If this document is seen as use case document only, it appears in good shape.
However, it also includes a section 4 about requirements and it seems security requirements have not been considered among them.
Maybe that is not intended or not necessary. I will leave that question up for the judgement by the WG. 

One main comment:
1. section 5: Security Considerations
is empty as it states not to introduce any new protocols. In principle that is ok, as long as it is understood that the following proposed protocols for these use cases will need to answer to security considerations.
However, as the document also speaks about requirements, it would have been nice to spell out specific security requirements that are to be considered from these use cases. Security requirements (from protection against malicious actors) should have been considered in section 4.
Also the various use cases should be explored for whether they may expose a system to abuse.
E.g. several requirements are stated as "MUST" (which btw. I am not sure is the proper use of RFC2119 definition). The question would be if a system will follow these requirements whether it would be exposed to additional security risks. E.g. Req#2 "MUST be able to establish a unidirectional BFD session without the bidirectional handshake", #3 "BFD session MUST be able to be established without the need for session negotiation". Overall I can see the request for these requirements. I would also like to see a discussion of their security implications and risks.


nitbits:
some of the language seems not so clean. Not outright wrong, but very hard to understand.
Maybe some native speakers or the RFC editor can help clean this up:
e.g. section 3.2 "All it takes is for the network entities to know what the discriminator values to be used for the session."
I read this sentence a few times and not quite sure which words to add to match the intended meaning of the authors. ;-)

Thank you and best regards.

Tobias
--------------090808070701090403000001-- From nobody Tue Apr 12 09:56:42 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98BAC12E15E; Tue, 12 Apr 2016 09:56:36 -0700 (PDT) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htKbF876Ee9h; Tue, 12 Apr 2016 09:56:35 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 90E6C12E1A6; Tue, 12 Apr 2016 09:56:34 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 772A5F991; Tue, 12 Apr 2016 12:56:33 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 1C6B0200B0; Tue, 12 Apr 2016 12:56:33 -0400 (EDT) From: Daniel Kahn Gillmor To: Tobias Gondrom , frank.xialiang@huawei.com, iesg@ietf.org, secdir@ietf.org, draft-alakuijala-brotli.all@ietf.org In-Reply-To: <570D1F4D.6010306@gondrom.org> References: <87bn5guq9l.fsf@alice.fifthhorseman.net> <570D1F4D.6010306@gondrom.org> User-Agent: Notmuch/0.21+128~g620f892 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Tue, 12 Apr 2016 12:56:32 -0400 Message-ID: <871t6abwan.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [secdir] secdir review of draft-alakuijala-brotli-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 16:56:36 -0000 On Tue 2016-04-12 12:16:13 -0400, Tobias Gondrom wrote: > in my understanding this ID is _only_ about a compression, not about > encryption. Therefore it is not even intended to be resistant to the > attack you describe below. (for proper confidentiality the channel > would need to be encrypted.) Agreed, but encryption specs are often _only_ about encryption, even though they're sometimes layered over a compression protocol. I think your argument implies that this warning doesn't belong in either Security Considerations section (of the compression-less encryption protocol, or of the encryption-less compression protocol), which makes me sad. Instead, i think we should make people considering either protocol aware of the risks of the combination. This doesn't have to be a huge edit, just a short paragraph in the security considerations. --dkg From nobody Thu Apr 14 04:25:40 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1EA12DA48 for ; Thu, 14 Apr 2016 04:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4-XvsNH8Jvs for ; Thu, 14 Apr 2016 04:25:36 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84B2A12D7DA for ; Thu, 14 Apr 2016 04:25:36 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u3EBPWiR024014 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 14 Apr 2016 14:25:32 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u3EBPWwk006870; Thu, 14 Apr 2016 14:25:32 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22287.32300.401231.331968@fireball.acr.fi> Date: Thu, 14 Apr 2016 14:25:32 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 11:25:39 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Tero Kivinen is next in the rotation. For telechat 2016-04-21 Reviewer LC end Draft Shaun Cooley T 2016-03-29 draft-ietf-pce-iro-update-06 Donald Eastlake TR2016-02-22 draft-ietf-dane-openpgpkey-09 Phillip Hallam-Baker T 2016-04-05 draft-ietf-pals-seamless-vccv-02 Steve Hanna T 2016-04-11 draft-ietf-pim-hierarchicaljoinattr-07 Jeffrey Hutzelman T 2015-12-04 draft-ietf-core-block-19 Leif Johansson T 2016-04-06 draft-ietf-p2psip-sip-18 Joe Salowey T 2016-03-09 draft-ietf-rtcweb-audio-codecs-for-interop-05 Carl Wallace T 2016-03-30 draft-schoenw-opsawg-copspr-historic-04 For telechat 2016-05-05 Donald Eastlake T 2016-04-13 draft-ietf-bess-multicast-damping-04 Shawn Emery T 2016-04-12 draft-ietf-bfd-seamless-base-09 Daniel Kahn Gillmor T 2016-04-12 draft-ietf-bfd-seamless-ip-04 Christian Huitema T 2016-04-13 draft-ietf-bess-pta-flags-02 Chris Inacio T 2016-04-26 draft-ietf-ospf-sbfd-discriminator-04 Benjamin Kaduk T 2016-04-21 draft-ietf-rtcweb-alpn-03 Scott Kelly T 2016-05-03 draft-ietf-i2rs-pub-sub-requirements-05 Eric Osterweil T 2016-01-05 draft-campbell-art-rfc5727-update-03 Yaron Sheffer T 2016-03-09 draft-ietf-v6ops-host-addr-availability-06 Sam Weiler T 2016-03-18 draft-ietf-avtext-sdes-hdr-ext-05 Tom Yu T 2016-03-24 draft-ietf-dime-drmp-05 Dacheng Zhang T 2016-03-28 draft-ietf-grow-route-leak-problem-definition-04 Last calls and special requests: Alan DeKok 2016-04-30 draft-bradner-rfc3979bis-08 Daniel Kahn Gillmor E 2016-02-01 draft-ietf-rtcweb-security-08 Hannes Tschofenig 2015-12-28 draft-ietf-hip-rfc5204-bis-07 Hannes Tschofenig E None draft-ietf-ntp-network-time-security-13 Hannes Tschofenig E None draft-ietf-ntp-cms-for-nts-message-06 Hannes Tschofenig E None draft-ietf-ntp-using-nts-for-ntp-04 Brian Weis E 2016-02-01 draft-ietf-cdni-uri-signing-07 Tom Yu R2016-04-25 draft-ietf-netconf-yang-library-05 -- kivinen@iki.fi From nobody Thu Apr 14 05:26:24 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B07112E3CF; Thu, 14 Apr 2016 05:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.045 X-Spam-Level: X-Spam-Status: No, score=-101.045 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_DYNAMIC_IPADDR=1.951, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=tobias.gondrom@gondrom.org header.d=gondrom.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIc6IrtkXEM4; Thu, 14 Apr 2016 05:26:21 -0700 (PDT) Received: from lvps5-35-241-16.dedicated.hosteurope.de (www.gondrom.org [5.35.241.16]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E1A412E3CE; Thu, 14 Apr 2016 05:26:21 -0700 (PDT) Received: from [192.168.43.211] (ip-109-43-1-24.web.vodafone.de [109.43.1.24]) by lvps5-35-241-16.dedicated.hosteurope.de (Postfix) with ESMTPSA id 4A6B2634BA; Thu, 14 Apr 2016 14:26:19 +0200 (CEST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=Sr4sFksnX7D/FSXb63sg/ajeS+i/sXieXUuCHgccYz+zjZ+qxR0N5A9HOLRfrWUDdmvCGipazZ3G9nF9dSqQ9q1KcMLjPTClz9o6SqCDw82MU3bQ6qKVTjNdCRAZXqFDfzS+6CdN1avcDzlS1rLy+hYZi72lrRQV28VTLTnmNNU=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type; Message-ID: <570F8C6A.3030807@gondrom.org> Date: Thu, 14 Apr 2016 14:26:18 +0200 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: dkg@fifthhorseman.net, frank.xialiang@huawei.com, iesg@ietf.org, secdir@ietf.org, draft-alakuijala-brotli.all@ietf.org References: <87bn5guq9l.fsf@alice.fifthhorseman.net> <570D1F4D.6010306@gondrom.org> <871t6abwan.fsf@alice.fifthhorseman.net> In-Reply-To: <871t6abwan.fsf@alice.fifthhorseman.net> Content-Type: multipart/alternative; boundary="------------070500020104070505060207" Archived-At: Subject: Re: [secdir] secdir review of draft-alakuijala-brotli-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 12:26:22 -0000 This is a multi-part message in MIME format. --------------070500020104070505060207 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 12/04/16 18:56, Daniel Kahn Gillmor wrote: > On Tue 2016-04-12 12:16:13 -0400, Tobias Gondrom wrote: >> in my understanding this ID is _only_ about a compression, not about >> encryption. Therefore it is not even intended to be resistant to the >> attack you describe below. (for proper confidentiality the channel >> would need to be encrypted.) > Agreed, but encryption specs are often _only_ about encryption, even > though they're sometimes layered over a compression protocol. > > I think your argument implies that this warning doesn't belong in either > Security Considerations section (of the compression-less encryption > protocol, or of the encryption-less compression protocol), which makes > me sad. > > Instead, i think we should make people considering either protocol aware > of the risks of the combination. This doesn't have to be a huge edit, > just a short paragraph in the security considerations. > > --dkg Just to be clear: This is just my own humble opinion, just one among many in the community. ;-) It is up to the WG and editors to decide. Cheers, Tobias --------------070500020104070505060207 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
On 12/04/16 18:56, Daniel Kahn Gillmor wrote:
On Tue 2016-04-12 12:16:13 -0400, Tobias Gondrom <tobias.gondrom@gondrom.org> wrote:

in my understanding this ID is _only_ about a compression, not about
encryption.  Therefore it is not even intended to be resistant to the
attack you describe below.  (for proper confidentiality the channel
would need to be encrypted.)

Agreed, but encryption specs are often _only_ about encryption, even
though they're sometimes layered over a compression protocol.

I think your argument implies that this warning doesn't belong in either
Security Considerations section (of the compression-less encryption
protocol, or of the encryption-less compression protocol), which makes
me sad.

Instead, i think we should make people considering either protocol aware
of the risks of the combination.  This doesn't have to be a huge edit,
just a short paragraph in the security considerations.

     --dkg

Just to be clear: This is just my own humble opinion, just one among many in the community. ;-)
It is up to the WG and editors to decide.

Cheers, Tobias

 --------------070500020104070505060207-- From nobody Fri Apr 15 03:24:03 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D7012D13C; Fri, 15 Apr 2016 03:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.221 X-Spam-Level: X-Spam-Status: No, score=-104.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LS9B1UqxtZ9v; Fri, 15 Apr 2016 03:24:00 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DE8712D67C; Fri, 15 Apr 2016 03:23:59 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-f0-5710c13c21d4 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 53.19.12926.C31C0175; Fri, 15 Apr 2016 12:23:57 +0200 (CEST) Received: from [131.160.126.87] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.3.248.2; Fri, 15 Apr 2016 12:23:51 +0200 To: Sean Turner , Samu Varjonen References: <2A372E02-DC5C-4791-91D8-20D4949D6383@sn3rd.com> From: Gonzalo Camarillo Message-ID: <5710C137.30305@ericsson.com> Date: Fri, 15 Apr 2016 13:23:51 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <2A372E02-DC5C-4791-91D8-20D4949D6383@sn3rd.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM2K7oq7tQYFwg3fnWSy+z7jLbDHjz0Rm i627P7FaXFnVyGzxYeFDFgdWj9V3pT2WLPnJ5HHwIKPHl8uf2QJYorhsUlJzMstSi/TtErgy vu/7yVowja2i+X4fawPjE5YuRk4OCQETiVUzpzBB2GISF+6tZ+ti5OIQEjjCKDHrwF1WCGcN o8TEqw1gVcICFhLP32xkA7FFBNwlJtx8xQRRtIJRonvBLXaQBLNAksS/KRvAbDaghi237oOt 4xXQlJi5eRFQAwcHi4CqxJv56SBhUYEYicYHp5ggSgQlTs6EuI5TwFZiZ+d7sHJmoNb1u/Qh pstLNG+dzQxiCwloSyx/1sIygVFwFpLuWQgds5B0LGBkXsUoWpxanJSbbmSsl1qUmVxcnJ+n l5dasokRGNoHt/xW3cF4+Y3jIUYBDkYlHt6EZoFwIdbEsuLK3EOMEhzMSiK8TPuAQrwpiZVV qUX58UWlOanFhxilOViUxHmzI/+FCQmkJ5akZqemFqQWwWSZODilGhj9ipyqZP+eDDXOnKEf cKuQe87dynNbJzI3lzU1m7jZNfTNujjxZo/wGhGrfw9vRca/ePnhk9wOcx+ePCnd+wcmRlzN +G8SUZTrZSU+haMn9jHjvBv5C689eiUWxTFLruL6kbzAH68uZLxV2Tkn12lmbpO/5NtFz059 2XhExXPBieTw7TMEGqcrsRRnJBpqMRcVJwIAmkHDN2kCAAA= Archived-At: Cc: draft-ietf-hip-rfc6253-bis.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-hip-rfc6253-bis X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 10:24:02 -0000 Hi Samu, could you please revise the draft accordingly? Thanks, Gonzalo On 10/04/2016 2:54 PM, Sean Turner wrote: > Thanks for the reminder: > >> On Feb 12, 2016, at 08:47, Samu Varjonen wrote: >>> Nits: >>> >>> nit 1: I read this a couple of times: >>> CERT parameters with the same Cert group number >>> in the group field indicate a logical grouping. >>> Isn’t it that the same group # is in the Cert group field:? >>> CERT parameters with the same number >>> in the Cert group field indicate a logical grouping. >> >> Is this about missing CERT word in the group field? Or did I misunderstand this question? > > Yeah this is completely editorial; I think “Cert” is just in the wrong place. Might be wrong. > > spt > From nobody Sun Apr 17 04:41:29 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 072FE12D7E5; Sun, 17 Apr 2016 04:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJDjGiDKXgUB; Sun, 17 Apr 2016 04:41:03 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97BBF12D1BB; Sun, 17 Apr 2016 04:41:01 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 7A875D3A883DE; Sun, 17 Apr 2016 11:40:57 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u3HBexQs010078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 17 Apr 2016 11:40:59 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u3HBexiC028526 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 17 Apr 2016 13:40:59 +0200 Received: from FR711WXCHMBA02.zeu.alcatel-lucent.com ([169.254.2.90]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Sun, 17 Apr 2016 13:40:59 +0200 From: "Murray, Rob (Nokia - GB)" To: EXT Vincent Roca Thread-Topic: Secdir review of draft-ietf-cdni-control-triggers-11 Thread-Index: AQHRdiVIwOmzDCWgCk67ArY5AP/E6Z9lmUqAgBxAEgCADGWaAA== Date: Sun, 17 Apr 2016 11:40:58 +0000 Message-ID: References: <252883D7-E325-4B9A-A978-FEACE5B40143@alcatel-lucent.com> <61B94AAC-920E-4909-9680-6FF212E8901D@inria.fr> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_D04BAD9583284DB7B408C32DCEE268B2alcatellucentcom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-cdni-control-triggers@tools.ietf.org" , "cdni@ietf.org" , IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-cdni-control-triggers-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2016 11:41:20 -0000 --_000_D04BAD9583284DB7B408C32DCEE268B2alcatellucentcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RG9uZSBub3csIHRoZXNlIG1vZHMgYXJlIGluY2x1ZGVkIGluICItMTMiLiBUaGFuayB5b3UgZm9y IHlvdXIgaGVscC4NCg0KRnJvbTogUm9iIE11cnJheSA8cm9iLm11cnJheUBhbGNhdGVsLWx1Y2Vu dC5jb208bWFpbHRvOnJvYi5tdXJyYXlAYWxjYXRlbC1sdWNlbnQuY29tPj4NCkRhdGU6IFNhdHVy ZGF5LCA5IEFwcmlsIDIwMTYgYXQgMTU6MjINClRvOiBFWFQgVmluY2VudCBSb2NhIDx2aW5jZW50 LnJvY2FAaW5yaWEuZnI8bWFpbHRvOnZpbmNlbnQucm9jYUBpbnJpYS5mcj4+DQpDYzogSUVTRyA8 aWVzZ0BpZXRmLm9yZzxtYWlsdG86aWVzZ0BpZXRmLm9yZz4+LCAic2VjZGlyQGlldGYub3JnPG1h aWx0bzpzZWNkaXJAaWV0Zi5vcmc+IiA8c2VjZGlyQGlldGYub3JnPG1haWx0bzpzZWNkaXJAaWV0 Zi5vcmc+PiwgImRyYWZ0LWlldGYtY2RuaS1jb250cm9sLXRyaWdnZXJzQHRvb2xzLmlldGYub3Jn PG1haWx0bzpkcmFmdC1pZXRmLWNkbmktY29udHJvbC10cmlnZ2Vyc0B0b29scy5pZXRmLm9yZz4i IDxkcmFmdC1pZXRmLWNkbmktY29udHJvbC10cmlnZ2Vyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86 ZHJhZnQtaWV0Zi1jZG5pLWNvbnRyb2wtdHJpZ2dlcnNAdG9vbHMuaWV0Zi5vcmc+PiwgImNkbmlA aWV0Zi5vcmc8bWFpbHRvOmNkbmlAaWV0Zi5vcmc+IiA8Y2RuaUBpZXRmLm9yZzxtYWlsdG86Y2Ru aUBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogU2VjZGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLWNk bmktY29udHJvbC10cmlnZ2Vycy0xMQ0KDQpUaGFua3MgVmluY2VudCwgSSdsbCBtYWtlIHRob3Nl IG1vZHMgaW4gdGhlIG5leHQgdXBkYXRlLg0KDQpGcm9tOiBFWFQgVmluY2VudCBSb2NhIDx2aW5j ZW50LnJvY2FAaW5yaWEuZnI8bWFpbHRvOnZpbmNlbnQucm9jYUBpbnJpYS5mcj4+DQpEYXRlOiBU dWVzZGF5LCAyMiBNYXJjaCAyMDE2IGF0IDE0OjU3DQpUbzogUm9iIE11cnJheSA8cm9iLm11cnJh eUBub2tpYS5jb208bWFpbHRvOnJvYi5tdXJyYXlAbm9raWEuY29tPj4NCkNjOiBWaW5jZW50IFJv Y2EgPHZpbmNlbnQucm9jYUBpbnJpYS5mcjxtYWlsdG86dmluY2VudC5yb2NhQGlucmlhLmZyPj4s IElFU0cgPGllc2dAaWV0Zi5vcmc8bWFpbHRvOmllc2dAaWV0Zi5vcmc+PiwgInNlY2RpckBpZXRm Lm9yZzxtYWlsdG86c2VjZGlyQGlldGYub3JnPiIgPHNlY2RpckBpZXRmLm9yZzxtYWlsdG86c2Vj ZGlyQGlldGYub3JnPj4sICJkcmFmdC1pZXRmLWNkbmktY29udHJvbC10cmlnZ2Vyc0B0b29scy5p ZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1jZG5pLWNvbnRyb2wtdHJpZ2dlcnNAdG9vbHMuaWV0 Zi5vcmc+IiA8ZHJhZnQtaWV0Zi1jZG5pLWNvbnRyb2wtdHJpZ2dlcnNAdG9vbHMuaWV0Zi5vcmc8 bWFpbHRvOmRyYWZ0LWlldGYtY2RuaS1jb250cm9sLXRyaWdnZXJzQHRvb2xzLmlldGYub3JnPj4s ICJjZG5pQGlldGYub3JnPG1haWx0bzpjZG5pQGlldGYub3JnPiIgPGNkbmlAaWV0Zi5vcmc8bWFp bHRvOmNkbmlAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFNlY2RpciByZXZpZXcgb2YgZHJhZnQt aWV0Zi1jZG5pLWNvbnRyb2wtdHJpZ2dlcnMtMTENCg0KSGkgUm9iLA0KDQpJJ3ZlIGp1c3QgcG9z dGVkIGEgIi0xMiIgb2YgdGhlIENETkkgVHJpZ2dlcnMgZHJhZnQsIGhvcGVmdWxseSBhZGRyZXNz aW5nIHRoZXNlIGNvbW1lbnRzLiBSZXNwb25zZXMgaW5saW5lIGJlbG93Lg0KDQpJIHNlZSB5b3Un dmUgYWRkZWQgc2VjdGlvbiAyLjIuMSB0byBjbGFyaWZ5IG1hbnkgYXJjaGl0ZWN0dXJhbCBhc3Bl Y3RzLiBUaGF0J3MgcXVpdGUgdXNlZnVsLg0KDQoNClRoZXJlIGFyZSBzZXZlcmFsIHRvcGljcyBJ 4oCZZCBsaWtlIHRvIGRpc2N1c3M6DQoNCjEtIENvbmNlcm5pbmcgdGhlIHVzZSBvZiBUTFMgdG8g Y2FycnkgQ0kvVCB0cmFmZmljLCBJIHNlZSBpdCBpcyBtYW5kYXRvcnkNCnRvIGltcGxlbWVudCwg YnV0IHN0aWxsIG9wdGlvbmFsIHRvIHVzZSAoMXN0IHNlbnRlbmNlIG9mIFNlY3Rpb24gOC4xKS4g SXMNCml0IHN0aWxsIHJlYXNvbmFibGUgaW4gY3VycmVudCBJbnRlcm5ldD8gQXQgYSBtaW5pbXVt IEkgd291bGQgZXhwZWN0IGENCsKrIE1VU1Qgc3VwcG9ydCDCuyAvIMKrIFNIT1VMRCB1c2Ugwrsu DQoNClNlY3Rpb24gOC4xIGdvZXMgb24gdG8gc2F5IC4uLg0KDQogWyAuLi4gZGVzY3JpcHRpb24g b2YgYmVuZWZpdHMgb2YgSFRUUFMgLi4uIF0NCg0KIEluIGFuIGVudmlyb25tZW50IHdoZXJlIGFu eSBzdWNoIHByb3RlY3Rpb24gaXMgcmVxdWlyZWQsIG11dHVhbGx5DQogYXV0aGVudGljYXRlZCBl bmNyeXB0ZWQgdHJhbnNwb3J0IE1VU1QgYmUgdXNlZCB0byBlbnN1cmUNCiBjb25maWRlbnRpYWxp dHkgb2YgdGhlIENJL1QgaW5mb3JtYXRpb24uIFRvIHRoYXQgZW5kLCBUTFMgTVVTVCBiZQ0KIHVz ZWQgYnkgQ0kvVCwgaW5jbHVkaW5nIGF1dGhlbnRpY2F0aW9uIG9mIHRoZSByZW1vdGUgZW5kLg0K DQouLi4gdGhlIEludGVybmV0IGlzIGNsZWFybHkgYW4gZW52aXJvbm1lbnQgd2hlcmUgc3VjaCBw cm90ZWN0aW9uIGlzDQpyZXF1aXJlZCwgYW5kIGl0J2xsIG9mdGVuIGJlIHVzZWQgZm9yIHRoZXNl IGludGVyZmFjZXMgLSB3ZSBjb3VsZCBzdGF0ZQ0KdGhhdCBleHBsaWNpdGx5LCB3b3VsZCB0aGF0 IGFkZHJlc3MgdGhlIGNvbmNlcm4/DQoNCkJ1dCwgQ0kvVCBjb3VsZCBhbHNvIGJlIGRlcGxveWVk IHRvIHJ1biBvdmVyIGEgVlBOIG9yIHByaXZhdGUgbmV0d29yaw0KYmV0d2VlbiB0d28gaW50ZXJj b25uZWN0ZWQgQ0ROcywgaW4gc3VjaCBhbiBlbnZpcm9ubWVudCBIVFRQUyB0cmFuc3BvcnQNCndv dWxkIG5vdCBoYXZlIHRoZSBzYW1lIGJlbmVmaXRzLg0KDQpZZXMsIHRoYXTigJlzIG15IHBvaW50 LiBTYXkgZXhwbGljaXRseSB0aGF0IEludGVybmV0IGlzIGFuIGV4YW1wbGUgb2YgZW52aXJvbm1l bnQgd2hlcmUNCnN1Y2ggYSBwcm90ZWN0aW9uIGlzIG1hbmRhdG9yeS4NCg0KSW4gIi0xMiIgSSd2 ZSBhbGlnbmVkIHRoZSB0ZXh0IGFib3ZlIHdpdGggdGhlIHRleHQgdXNlZCBpbiB0aGUgY2RuaS1t ZXRhZGF0YSBkcmFmdDoNCg0KIFRMUyBNVVNUIGJlIHVzZWQgYnkgdGhlIHNlcnZlci1zaWRlIChk Q0ROKSBhbmQgdGhlIGNsaWVudC1zaWRlICh1Q0ROKSBvZg0KIHRoZSBDSS9UIGludGVyZmFjZSwg aW5jbHVkaW5nIGF1dGhlbnRpY2F0aW9uIG9mIHRoZSByZW1vdGUgZW5kLCB1bmxlc3MNCiBhbHRl cm5hdGUgbWV0aG9kcyBhcmUgdXNlZCBmb3IgZW5zdXJpbmcgdGhlIGNvbmZpZGVudGlhbGl0eSBv ZiB0aGUNCiBpbmZvcm1hdGlvbiBpbiB0aGUgQ0kvVCBpbnRlcmZhY2UgcmVxdWVzdHMgYW5kIHJl c3BvbnNlcyAoc3VjaCBhcyBzZXR0aW5nDQogdXAgYW4gSVBzZWMgdHVubmVsIGJldHdlZW4gdGhl IHR3byBDRE5zIG9yIHVzaW5nIGEgcGh5c2ljYWxseSBzZWN1cmVkDQogaW50ZXJuYWwgbmV0d29y ayBiZXR3ZWVuIHR3byBDRE5zIHRoYXQgYXJlIG93bmVkIGJ5IHRoZSBzYW1lIGNvcnBvcmF0ZQ0K IGVudGl0eSkuDQoNCkkgdGhpbmsgdGhhdCBjb3ZlcnMgaXQgYmV0dGVyICg/KS4NCg0KVGhpcyBp cyBtdWNoIGJldHRlci4gSnVzdCBhIG1pbm9yIGNvbW1lbnQ6ICIuLi4gZm9yIGluc3VyaW5nIHRo ZSBzZWN1cml0eSIgaW5zdGVhZCBvZg0KIi4uLiBmb3IgZW5zdXJpbmcgdGhlIGNvbmZpZGVudGlh bGl0eSIsIHNpbmNlIGNvbmZpZGVudGlhbGl0eSBpcyBvbmx5IG9uZSBhc3BlY3Qgb2Ygc2VjdXJp dHkuDQoNCg0KMi0gU2VjdGlvbiA4LjEsIHBsZWFzZSBjaGVjayB0aGUgcGFyYWdyYXBoIMKrIE5v dGUgdGhhdCBpbiBhIMKrIGRpYW1vbmQgwrsNCmNvbmZpZ3VyYXRpb24gW+KApl0gwrsuIFRoaXMg cGFyYWdyYXBoIGlzIHJhdGhlciBjb25mdXNpbmcgdG8gbWUuIENvbmZ1c2lvbg0KY29tZXMgZnJv bToNCi0gdGhlIGxhY2sgb2YgZGVzY3JpcHRpb24gb2YgdGhlIMKrIGRpYW1vbmQgY29uZmlndXJh dGlvbiDCuy4gSSB1bmRlcnN0YW5kDQp0aGVyZSBpcyBvbmUgZENETiBvbiB0b3AgYW5kIG11bHRp cGxlIHVDRE4gZGlyZWN0bHkgY29ubmVjdGVkIGJlbG93LCBhbSBJDQpyaWdodD8NCg0KWWVzLCB0 aGF0J3MgcmlnaHQuIFRoZSBkcmFmdCBzYXlzOg0KDQogTm90ZSB0aGF0IGluIGEgImRpYW1vbmQi IGNvbmZpZ3VyYXRpb24sIHdoZXJlIG9uZSB1Q0ROJ3MgY29udGVudCBjYW4NCiBiZSBhY3F1aXJl ZCB2aWEgbW9yZSB0aGFuIG9uZSBkaXJlY3RseS1jb25uZWN0ZWQgdUNETiwNCg0KV291bGQgdGhl IGZvbGxvd2luZyByZWFycmFuZ2VtZW50IGhlbHA/IC4uLg0KDQogQSAiZGlhbW9uZCIgY29uZmln dXJhdGlvbiBpcyBvbmUgd2hlcmUgYSBkQ0ROIGNhbiBhY3F1aXJlIGEgdUNETidzDQogY29udGVu dCB2aWEgbW9yZSB0aGFuIG9uZSBkaXJlY3RseS1jb25uZWN0ZWQgdUNETi4gTm90ZSB0aGF0DQog aW4gYSBkaWFtb25kIGNvbmZpZ3VyYXRpb24gW+KApl0NCg0KWWVzLCBJIHByZWZlciB0aGlzIHZl cnNpb24uIEhvd2V2ZXIsIGNhbiB0aGUgc2FtZSDCqyB1Q0RO4oCZcyBjb250ZW50IMK7IGJlDQph dmFpbGFibGUgYXQgc2V2ZXJhbCB1Q0ROcyBpbiB0aGlzIGRpYW1vbmQgY29uZmlndXJhdGlvbj8g U2FpZCBkaWZmZXJlbnRseSwNCndoYXQgYWJvdXQgdGhlIGZvbGxvd2luZyB0ZXh0Og0KDQpBIMKr IGRpYW1vbmQgwrsgY29uZmlndXJhdGlvbiBpcyBvbmUgd2hlcmUgYSBkQ0ROIGNhbiBhY3F1aXJl IGEgZ2l2ZW4NCmNvbnRlbnQgdmlhIG1vcmUgdGhhbiBvbmUgZGlyZWN0bHktY29ubmVjdGVkIHVD RE4uIE5vdGUgdGhhdCBb4oCmXQ0KDQpZZXMsIG1vcmUgdGhhbiBvbmUgdUNETiB3aWxsIGhhdmUg dGhlIHNhbWUgY29udGVudCAtIGJ1dCB0aGUgaW1wb3J0YW50IHBvaW50IGlzIHRoYXQgdWx0aW1h dGVseSB0aGV5IHdpbGwgYWxsIGhhdmUgYWNxdWlyZWQgaXQgZnJvbSB0aGUgc2FtZSB1Q0ROLCBh bmQgdGhhdCB1Q0ROIG93bnMgdGhlIG1ldGFkYXRhLg0KDQpJJ3ZlIHRyaWVkIHRvIHByb3ZpZGUg YSBiZXR0ZXIgaW50cm8vZXhwbGFuYXRpb24gaW4gbmV3IHNlY3Rpb24gMi4yLjEgIk11bHRpcGxl IGludGVyY29ubmVjdGVkIENETnMiLiBIb3BlZnVsbHkgdGhhdCBtYWtlcyBpdCBhIGJpdCBjbGVh cmVyPw0KDQpZZXMsIGFzIHNhaWQgYWJvdmUsIHNlY3Rpb24gMi4yLjEgaXMgcmF0aGVyIHVzZWZ1 bC4NCkp1c3QgYSBjb21tZW50IGZvciB0aGlzIHNlY3Rpb24gMi4yLjEsIHRoaXJkIHBhcmFncmFw aCwgbGFzdCBzZW50ZW5jZS4gWW91IG1lbnRpb24NCmJvdGggImludGVybWVkaWF0ZSBDRE4iIGFu ZCBqdXN0IGFmdGVyICJpbnRlcm1lZGlhdGUgdUNETiIuIFRoaXMgaXMgYSBiaXQgY29uZnVzaW5n Lg0KDQpBbm90aGVyIGRldGFpbDogaW4gc2Vjb25kIHBhcmFncmFwaCB5b3UgbWVudGlvbiAiImlu dGVybWVkaWF0ZSIgQ0ROIiB3aXRoIGV4dHJhICIgIg0KYXJvdW5kIGludGVybWVkaWF0ZS4gUGxl YXNlIGhhcm1vbml6ZS4NCg0KDQozLSBXaXRoIHRoaXMgwqsgZGlhbW9uZCBjb25maWd1cmF0aW9u IMK7LCBzaW5jZSBzZXZlcmFsIHVDRE4gY2FuIGFjdCB1cG9uIHRoZQ0Kc2FtZSBjb250ZW50LCB3 aGF0IGhhcHBlbnMgaWYgdGhleSBiZWhhdmUgaW4gYSBub24gY29vcmRpbmF0ZWQgbWFubmVyIChp LmUuLA0KaW4gdGhlIGdlbmVyYWwgY2FzZSk/IEZvciBpbnN0YW5jZSBsZXTigJlzIGltYWdpbmUg b25lIG9mIHRoZW0gYXNrcyB0aGUgZENETg0KdG8gZGVsZXRlIHRoZSBjb250ZW50IG9yIGNhbmNl bCB0aGUgaW5pdGlhbCBjb21tYW5kLiBXaGF0IGhhcHBlbnMgaWYgYW5vdGhlcg0KdUNETiB0aGVu IGFza3MgdGhlIGRDRE4gdG8gaW52YWxpZGF0ZSB0aGlzIGNvbnRlbnQsIHByb3ZpZGluZyB0aGUg VVJMIG9mIHRoZQ0KVHJpZ2dlciBTdGF0dXMgUmVzb3VyY2Ugd2hpY2ggKGlmIEkgdW5kZXJzdGFu ZCBjb3JyZWN0bHkpIGlzIG5vIGxvbmdlciB2YWxpZD8NClRoaXMgwqsgZGlhbW9uZCBjb25maWd1 cmF0aW9uIMK7IGNhbiBiZSBhIGxpdHRsZSBiaXQgdHJpY2t5IGFuZCBubyBjbGVhcg0KZ3VpZGVs aW5lIGlzIHByb3ZpZGVkIGluIHRoZSBkb2N1bWVudC4NCg0KQSB0cmlnZ2VyIHN0YXR1cyByZXNv dXJjZSBiZWxvbmdzIHRvIG9uZSB1Q0ROIGFuZCBjYW5ub3QgYmUgYWNjZXNzZWQgb3INCm1hbmlw dWxhdGVkIGJ5IGFueSBvdGhlciBDRE4sIHNlY3Rpb24gMyBwYXJhIDMgc2F5czoNCg0KIFRyaWdn ZXIgU3RhdHVzIFJlc291cmNlcyBiZWxvbmdpbmcgdG8gYSB1Q0ROIE1VU1QgTk9UDQogYmUgdmlz aWJsZSB0byBhbnkgb3RoZXIgQ0ROLiBUaGUgZENETiBjb3VsZCwgZm9yIGV4YW1wbGUsIGFjaGll dmUNCiB0aGlzIGJ5IG9mZmVyaW5nIGRpZmZlcmVudCBjb2xsZWN0aW9uIFVSTHMgdG8gZWFjaCB1 Q0ROLCBhbmQvb3IgYnkNCiBmaWx0ZXJpbmcgdGhlIHJlc3BvbnNlIGJhc2VkIG9uIHRoZSB1Q0RO IHdpdGggd2hpY2ggdGhlIEhUVFAgY2xpZW50DQogaXMgYXNzb2NpYXRlZC4NCg0KSSBzZWXigKYg SG93ZXZlciwgaWYgbXVsdGlwbGUgdUNETnMgY2FuIGFjdCBvbiB0aGUgc2FtZSBjb250ZW50ICh3 aGF0IGlzIHNhaWQpLA0KZXZlbiBpZiBlYWNoIHVDRE4gdXNlcyBhIGRpZmZlcmVudCBVUkwsIHdp bGwgc2ltdWx0YW5lb3VzIENJL1QgY29tbWFuZHMgZm9yDQp0aGUgc2FtZSBjb250ZW50IGJlIG1h bmFnZWQgY29ycmVjdGx5PyBUaGlzIGlzIG5vdCBzYWlkIGluIHNlY3Rpb24gMw0KcGFyYWdyYXBo IDMgZWl0aGVyIGFuZCB0aGlzIGlzIGEga2V5IHBvaW50Lg0KDQpTb3JyeSwgSSdkIG1pc3NlZCB5 b3VyIHBvaW50Lg0KDQpJbnRlcmFjdGlvbnMgY2FuIGJlIGluZWZmaWNpZW50LCBidXQgYXJlIG90 aGVyd2lzZSBoYXJtbGVzcyBiZWNhdXNlIHRoZSBzdHJvbmdlc3Qgb2YgImludmFsaWRhdGUiIG9y ICJwdXJnZSIgd2lsbCB3aW4sIGFuZCBjb250ZW50IGNhbiBhbHdheXMgYmUgcmUtYWNxdWlyZWQg aWYgaXQncyBzdGlsbCBhdmFpbGFibGUgZnJvbSBhbnkgdUNETi4NCg0KSSd2ZSBnaXZlbiBzb21l IGV4YW1wbGVzIGluIG5ldyBzZWN0aW9uIDIuMi4xICJNdWx0aXBsZSBpbnRlcmNvbm5lY3RlZCBD RE5zIiwgYW5kIGFkZGVkIGEgcG9pbnRlciB0byB0aGF0IGZyb20gdGhlIFNlY3VyaXR5IENvbnNp ZGVyYXRpb25zIHNlY3Rpb24uDQoNCk9uY2UgYWdhaW4sIHRoZSBleGFtcGxlcyBvZiBzZWN0aW9u IDIuMi4xIGFuc3dlciBteSBjb21tZW50cy4gVGhhbmtzLg0KDQoNCkNvbnRlbnQgYWx3YXlzIG9y aWdpbmF0ZXMgZnJvbSBvbmUgdUNETiwgYnV0IGluIGEgZGlhbW9uZCBjb25maWdyYXRpb24gdGhl cmUNCm1heSBiZSBtdWx0aXBsZSByb3V0ZXMgKHZpYSBvdGhlciBDRE5zKSB0byBhIGdpdmVuIGRD RE4uDQoNClRoZSBtb3N0IGNvbW1vbiBzY2VuYXJpbyBtYXkgd2VsbCBiZSB0aGF0IHRoZSB1Q0RO IHdpbGwgaW5pdGlhdGUgYWxsIG9mIHRoZQ0KQ0kvVCBjb21tYW5kcyByZWxhdGVkIHRvIGl0cyBj b250ZW50LCBhbmQgdGhvc2UgY29tbWFuZHMgd2lsbCBzaW1wbHkgYmUNCmZvcndhcmRlZCBieSBp bnRlcm1lZGlhdGUgQ0ROcy4NCg0KQnV0LCB0aGVyZSdzIG5vdGhpbmcgdG8gc3RvcCBhbiBpbnRl cm1lZGlhdGUgQ0ROIGluaXRpYXRpbmcgb3IgbW9kaWZ5aW5nDQpDSS9UIGNvbW1hbmRzIC0gYW5k IHNvbWUgbW9kaWZpY2F0aW9ucyBvZiB0aGUgY29tbWFuZCB3aWxsIGJlIG5lY2Vzc2FyeQ0KKGZv ciBleGFtcGxlLCBtZXRhZGF0YSBVUkxzIHdpbGwgbmVlZCB0byBiZSBjaGFuZ2VkKS4NCg0KQnkg YW5hbHlzaXMgb2YgbG9nIGZpbGVzIGl0IHdpbGwgcHJvYmFibHkgYmUgcG9zc2libGUgdG8gd29y ayBvdXQgd2hpY2gNCnVDRE4gYW4gaW5kaXZpZHVhbCBjYWNoZSBpbiB0aGUgZENETiBhY3F1aXJl ZCBlYWNoIGNhY2hlZCByZXNvdXJjZSBmcm9tLg0KQnV0IHRoZSBjYWNoZSBpcyBub3QgcmVxdWly ZWQgdG8ga2VlcCBhIGxpdmUgcmVjb3JkIG9mIHRoYXQsIGFuZCBpdA0KcHJvYmFibHkgd29uJ3Qu IEluIHRoYXQgY2FzZSwgd2hlbiBpdCByZWNlaXZlcyBhIENJL1QgY29tbWFuZCB0byBpbnZhbGlk YXRlDQpvciBwdXJnZSBjb250ZW50LCB0aGUgZENETiBzaG91bGQgYXBwbHkgdGhhdCBjb21tYW5k IHRvIGFueSBjb250ZW50IGl0DQptYXkgaGF2ZSBhY3F1aXJlZCBmcm9tIHRoZSB1Q0ROIGl0IGdv dCB0aGUgQ0kvVCBjb21tYW5kIGZyb20uDQoNClNvIHRoZXJlIGlzIHNjb3BlIGZvciBhIG1hbGlj aW91cyBpbnRlcm1lZGlhdGUgQ0ROIHRvIGNhdXNlIGV4dHJhIHByb2Nlc3NpbmcNCmFuZCBhY3F1 aXNpdGlvbiBieSBhIGRDRE4gKGFuZCB0aGF0J3MgbWVudGlvbmVkIGluIHNlY3Rpb24gOCkuIEJ1 dCBhDQptYWxpY2lvdXMgQ0ROIGlzIGxpa2VseSB0byBmaW5kIGl0c2VsZiByZW1vdmVkIGZyb20g dGhlIENETiBmZWRlcmF0aW9uIGZhaXJseQ0KcXVpY2tseSAtIHRoZXJlIHdpbGwgbmVjZXNzYXJp bHkgYmUgYSBsZXZlbCBvZiB0cnVzdCBiZXR3ZWVuIGludGVyY29ubmVjdGVkDQpDRE5zLg0KDQpX b3VsZCBpdCBoZWxwIHRvIHNwZWxsIG91dCBzb21lIG9mIHRoYXQgaW4gdGhlIGRyYWZ0PyAoVGhl IHNhbWUgb3IgdmVyeQ0Kc2ltaWxhciB0ZXh0IGhhcyBiZWVuIHVzZWQgaW4gc2V2ZXJhbCBvZiB0 aGUgQ0ROSSBkcmFmdHMuKQ0KDQpZZXMsIHRoaXMgcGFyYWdyYXBoIGlzIHdvcnRoIGJlaW5nIGRl dGFpbGVkIGEgbGl0dGxlIGJpdC4NCg0KSW4geW91ciBleHBsYW5hdGlvbnMgeW91IG1lbnRpb24g aW50ZXJtZWRpYXRlIENETnMgd2hpbGUgb3JpZ2luYWwgdGV4dCBvbmx5DQptZW50aW9ucyBkaXJl Y3RseSBjb25uZWN0ZWQgdUNETnMuIFRoZSBub3Rpb24gb2YgwqsgaW50ZXJtZWRpYXRlIENETiDC uyBpcw0Kb25seSBkaXNjdXNzZWQgaW4gc2VjdGlvbnMgMi4zIGFuZCA0LjguIFNpbmNlIG1hbGlj aW91cyBpbnRlcm1lZGlhdGUgQ0ROcyBhcmUNCnBhcnQgb2YgYSB2YWxpZCBhdHRhY2sgbW9kZWws IGl0IGlzIHdvcnRoIHRvIGV4cGxhaW4gaXQgKG9yIGdpdmUgYSByZWZlcmVuY2UgdG8gYW5vdGhl cg0KZG9jdW1lbnQpLg0KDQpXaGVuIGEgY29udGVudCBvd25lciwgdGhlIG9yaWdpbiwgZGVsZWdh dGVzIGRlbGl2ZXJ5IHRvIGEgQ0ROIGl0IGlzIHRydXN0aW5nIHRoYXQgQ0ROIHRvIGRlbGl2ZXIg dGhlIHJpZ2h0IGNvbnRlbnQgb24gaXRzIGJlaGFsZi4gQSBtYWxpY2lvdXMgQ0ROIGNvdWxkIGRl bGl2ZXIgYW55dGhpbmcgaW5zdGVhZCwgYnV0IGl0IHdvdWxkIHNvb24gbG9zZSB0aGUgdHJ1c3Qg b2YgdGhlIG9yaWdpbi4NCg0KQ0ROLWludGVyY29ubmVjdGlvbiBzaW1wbHkgZXh0ZW5kcyB0aGF0 IHRydXN0IHRvIHRoZSBmdXJ0aGVyLWRvd25zdHJlYW0gQ0ROcyBhY3Rpbmcgb24gYmVoYWxmIG9m IHRoZSBvcmlnaW5hbC4NCg0KU28gZXN0YWJsaXNobWVudC9lbmZvcmNlbWVudCBvZiB0aGUgdHJ1 c3QgcmVsYXRpb25zaGlwIGl0c2VsZiwgdGhlIGNvbnRyYWN0IGJldHdlZW4gdGhlIG9yaWdpbiBh bmQgdGhlIENETiwgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgQ0ROSSBhbmQgaW4gdGhlIGxhbmQg b2YgY29tbWVyY2lhbCBhZ3JlZW1lbnRzLg0KDQpTdXJlLCBJIGFncmVlLg0KDQoNCkkndmUgYWRk ZWQgYSBub3RlIG9uIHRoYXQgaW4gdGhlIGludHJvIHRvIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0 aW9ucyBzZWN0aW9uLg0KDQpUaGF0J3MgcGVyZmVjdC4NCg0KVG8gY29uY2x1ZGUgdGhlIGRvY3Vt ZW50IGlzIG9rYXkgZnJvbSBteSBwb2ludCBvZiB2aWV3Lg0KDQpUaGFua3MgZm9yIHlvdXIgZGV0 YWlsZWQgYW5zd2Vycy4NCkNoZWVycywNCg0KICAgVmluY2VudA0K --_000_D04BAD9583284DB7B408C32DCEE268B2alcatellucentcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PkRvbmUgbm93LCB0aGVzZSBtb2RzIGFyZSBpbmNsdWRlZCBpbiAmcXVvdDstMTMmcXVvdDsu IFRoYW5rIHlvdSBmb3IgeW91ciBoZWxwLjwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9Ik1BQ19PVVRM T09LX1NJR05BVFVSRSI+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMnB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9y OmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBu b25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdI VDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRp dW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s ZCI+RnJvbTogPC9zcGFuPlJvYiBNdXJyYXkgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2IubXVycmF5 QGFsY2F0ZWwtbHVjZW50LmNvbSI+cm9iLm11cnJheUBhbGNhdGVsLWx1Y2VudC5jb208L2E+Jmd0 Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+U2F0dXJk YXksIDkgQXByaWwgMjAxNiBhdCAxNToyMjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIj5UbzogPC9zcGFuPkVYVCBWaW5jZW50IFJvY2EgJmx0OzxhIGhyZWY9Im1haWx0bzp2aW5j ZW50LnJvY2FAaW5yaWEuZnIiPnZpbmNlbnQucm9jYUBpbnJpYS5mcjwvYT4mZ3Q7PGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+SUVTRyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmllc2dAaWV0Zi5vcmciPmllc2dAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJl Zj0ibWFpbHRvOnNlY2RpckBpZXRmLm9yZyI+c2VjZGlyQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnNlY2RpckBpZXRmLm9yZyI+c2VjZGlyQGlldGYub3JnPC9hPiZndDss ICZxdW90OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWNkbmktY29udHJvbC10cmlnZ2Vyc0B0 b29scy5pZXRmLm9yZyI+ZHJhZnQtaWV0Zi1jZG5pLWNvbnRyb2wtdHJpZ2dlcnNAdG9vbHMuaWV0 Zi5vcmc8L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWNkbmktY29u dHJvbC10cmlnZ2Vyc0B0b29scy5pZXRmLm9yZyI+ZHJhZnQtaWV0Zi1jZG5pLWNvbnRyb2wtdHJp Z2dlcnNAdG9vbHMuaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmNkbmlA aWV0Zi5vcmciPmNkbmlAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Y2Ru aUBpZXRmLm9yZyI+Y2RuaUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogU2VjZGlyIHJldmlldyBvZiBkcmFmdC1p ZXRmLWNkbmktY29udHJvbC10cmlnZ2Vycy0xMTxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJz cC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29s b3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2PlRoYW5rcyBWaW5jZW50LCBJJ2xsIG1h a2UgdGhvc2UgbW9kcyBpbiB0aGUgbmV4dCB1cGRhdGUuPC9kaXY+DQo8ZGl2Pg0KPGRpdiBpZD0i Ij48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3Bh biBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaTsgZm9udC1zaXplOjEycHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRF Ui1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkct Qk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRF Ui1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURE SU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3Nw YW4+RVhUIFZpbmNlbnQgUm9jYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZpbmNlbnQucm9jYUBpbnJp YS5mciI+dmluY2VudC5yb2NhQGlucmlhLmZyPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9u dC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPlR1ZXNkYXksIDIyIE1hcmNoIDIwMTYgYXQgMTQ6 NTc8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5Sb2IgTXVy cmF5ICZsdDs8YSBocmVmPSJtYWlsdG86cm9iLm11cnJheUBub2tpYS5jb20iPnJvYi5tdXJyYXlA bm9raWEuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6 IDwvc3Bhbj5WaW5jZW50IFJvY2EgJmx0OzxhIGhyZWY9Im1haWx0bzp2aW5jZW50LnJvY2FAaW5y aWEuZnIiPnZpbmNlbnQucm9jYUBpbnJpYS5mcjwvYT4mZ3Q7LCBJRVNHICZsdDs8YSBocmVmPSJt YWlsdG86aWVzZ0BpZXRmLm9yZyI+aWVzZ0BpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVm PSJtYWlsdG86c2VjZGlyQGlldGYub3JnIj5zZWNkaXJAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86c2VjZGlyQGlldGYub3JnIj5zZWNkaXJAaWV0Zi5vcmc8L2E+Jmd0OywN CiAmcXVvdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1jZG5pLWNvbnRyb2wtdHJpZ2dlcnNA dG9vbHMuaWV0Zi5vcmciPmRyYWZ0LWlldGYtY2RuaS1jb250cm9sLXRyaWdnZXJzQHRvb2xzLmll dGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtY2RuaS1jb250 cm9sLXRyaWdnZXJzQHRvb2xzLmlldGYub3JnIj5kcmFmdC1pZXRmLWNkbmktY29udHJvbC10cmln Z2Vyc0B0b29scy5pZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86Y2RuaUBp ZXRmLm9yZyI+Y2RuaUBpZXRmLm9yZzwvYT4mcXVvdDsNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNk bmlAaWV0Zi5vcmciPmNkbmlAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFNlY2RpciByZXZpZXcgb2YgZHJhZnQt aWV0Zi1jZG5pLWNvbnRyb2wtdHJpZ2dlcnMtMTE8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5i c3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBj bGFzcz0iIj4NCkhpIFJvYiwNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPkkn dmUganVzdCBwb3N0ZWQgYSAmcXVvdDstMTImcXVvdDsgb2YgdGhlIENETkkgVHJpZ2dlcnMgZHJh ZnQsIGhvcGVmdWxseSBhZGRyZXNzaW5nIHRoZXNlIGNvbW1lbnRzLiBSZXNwb25zZXMgaW5saW5l IGJlbG93LjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2Pkkgc2VlIHlvdSd2ZSBhZGRlZCBzZWN0aW9uIDIuMi4xIHRvIGNsYXJpZnkg bWFueSBhcmNoaXRlY3R1cmFsIGFzcGVjdHMuIFRoYXQncyBxdWl0ZSB1c2VmdWwuPC9kaXY+DQo8 ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIg Y2xhc3M9IiI+VGhlcmUgYXJlIHNldmVyYWwgdG9waWNzIEnigJlkIGxpa2UgdG8gZGlzY3Vzczo8 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQoxLSBDb25jZXJuaW5nIHRoZSB1c2Ugb2YgVExT IHRvIGNhcnJ5IENJL1QgdHJhZmZpYywgSSBzZWUgaXQgaXMgbWFuZGF0b3J5PGJyIGNsYXNzPSIi Pg0KdG8gaW1wbGVtZW50LCBidXQgc3RpbGwgb3B0aW9uYWwgdG8gdXNlICgxc3Qgc2VudGVuY2Ug b2YgU2VjdGlvbiA4LjEpLiBJczxiciBjbGFzcz0iIj4NCml0IHN0aWxsIHJlYXNvbmFibGUgaW4g Y3VycmVudCBJbnRlcm5ldD8gQXQgYSBtaW5pbXVtIEkgd291bGQgZXhwZWN0IGE8YnIgY2xhc3M9 IiI+DQrCqyBNVVNUIHN1cHBvcnQgwrsgLyDCqyBTSE9VTEQgdXNlIMK7LjxiciBjbGFzcz0iIj4N CjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NClNlY3Rpb24gOC4xIGdvZXMgb24gdG8gc2F5 IC4uLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwO1sgLi4uIGRlc2NyaXB0aW9u IG9mIGJlbmVmaXRzIG9mIEhUVFBTIC4uLiBdPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K Jm5ic3A7SW4gYW4gZW52aXJvbm1lbnQgd2hlcmUgYW55IHN1Y2ggcHJvdGVjdGlvbiBpcyByZXF1 aXJlZCwgbXV0dWFsbHk8YnIgY2xhc3M9IiI+DQombmJzcDthdXRoZW50aWNhdGVkIGVuY3J5cHRl ZCB0cmFuc3BvcnQgTVVTVCBiZSB1c2VkIHRvIGVuc3VyZTxiciBjbGFzcz0iIj4NCiZuYnNwO2Nv bmZpZGVudGlhbGl0eSBvZiB0aGUgQ0kvVCBpbmZvcm1hdGlvbi4gVG8gdGhhdCBlbmQsIFRMUyBN VVNUIGJlPGJyIGNsYXNzPSIiPg0KJm5ic3A7dXNlZCBieSBDSS9ULCBpbmNsdWRpbmcgYXV0aGVu dGljYXRpb24gb2YgdGhlIHJlbW90ZSBlbmQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K Li4uIHRoZSBJbnRlcm5ldCBpcyBjbGVhcmx5IGFuIGVudmlyb25tZW50IHdoZXJlIHN1Y2ggcHJv dGVjdGlvbiBpczxiciBjbGFzcz0iIj4NCnJlcXVpcmVkLCBhbmQgaXQnbGwgb2Z0ZW4gYmUgdXNl ZCBmb3IgdGhlc2UgaW50ZXJmYWNlcyAtIHdlIGNvdWxkIHN0YXRlPGJyIGNsYXNzPSIiPg0KdGhh dCBleHBsaWNpdGx5LCB3b3VsZCB0aGF0IGFkZHJlc3MgdGhlIGNvbmNlcm4/PGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KQnV0LCBDSS9UIGNvdWxkIGFsc28gYmUgZGVwbG95ZWQgdG8gcnVu IG92ZXIgYSBWUE4gb3IgcHJpdmF0ZSBuZXR3b3JrPGJyIGNsYXNzPSIiPg0KYmV0d2VlbiB0d28g aW50ZXJjb25uZWN0ZWQgQ0ROcywgaW4gc3VjaCBhbiBlbnZpcm9ubWVudCBIVFRQUyB0cmFuc3Bv cnQ8YnIgY2xhc3M9IiI+DQp3b3VsZCBub3QgaGF2ZSB0aGUgc2FtZSBiZW5lZml0cy48YnIgY2xh c3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpZZXMsIHRoYXTigJlzIG15IHBv aW50LiBTYXkgZXhwbGljaXRseSB0aGF0IEludGVybmV0IGlzIGFuIGV4YW1wbGUgb2YgZW52aXJv bm1lbnQgd2hlcmU8YnIgY2xhc3M9IiI+DQpzdWNoIGEgcHJvdGVjdGlvbiBpcyBtYW5kYXRvcnku PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KSW4gJnF1b3Q7LTEy JnF1b3Q7IEkndmUgYWxpZ25lZCB0aGUgdGV4dCBhYm92ZSB3aXRoIHRoZSB0ZXh0IHVzZWQgaW4g dGhlIGNkbmktbWV0YWRhdGEgZHJhZnQ6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5i c3A7VExTIE1VU1QgYmUgdXNlZCBieSB0aGUgc2VydmVyLXNpZGUgKGRDRE4pIGFuZCB0aGUgY2xp ZW50LXNpZGUgKHVDRE4pIG9mPGJyIGNsYXNzPSIiPg0KJm5ic3A7dGhlIENJL1QgaW50ZXJmYWNl LCBpbmNsdWRpbmcgYXV0aGVudGljYXRpb24gb2YgdGhlIHJlbW90ZSBlbmQsIHVubGVzczxiciBj bGFzcz0iIj4NCiZuYnNwO2FsdGVybmF0ZSBtZXRob2RzIGFyZSB1c2VkIGZvciBlbnN1cmluZyB0 aGUgY29uZmlkZW50aWFsaXR5IG9mIHRoZTxiciBjbGFzcz0iIj4NCiZuYnNwO2luZm9ybWF0aW9u IGluIHRoZSBDSS9UIGludGVyZmFjZSByZXF1ZXN0cyBhbmQgcmVzcG9uc2VzIChzdWNoIGFzIHNl dHRpbmc8YnIgY2xhc3M9IiI+DQombmJzcDt1cCBhbiBJUHNlYyB0dW5uZWwgYmV0d2VlbiB0aGUg dHdvIENETnMgb3IgdXNpbmcgYSBwaHlzaWNhbGx5IHNlY3VyZWQ8YnIgY2xhc3M9IiI+DQombmJz cDtpbnRlcm5hbCBuZXR3b3JrIGJldHdlZW4gdHdvIENETnMgdGhhdCBhcmUgb3duZWQgYnkgdGhl IHNhbWUgY29ycG9yYXRlPGJyIGNsYXNzPSIiPg0KJm5ic3A7ZW50aXR5KS48YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQpJIHRoaW5rIHRoYXQgY292ZXJzIGl0IGJldHRlciAoPykuPGJyIGNs YXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+ VGhpcyBpcyBtdWNoIGJldHRlci4gSnVzdCBhIG1pbm9yIGNvbW1lbnQ6ICZxdW90Oy4uLiBmb3Ig aW5zdXJpbmcgdGhlIHNlY3VyaXR5JnF1b3Q7IGluc3RlYWQgb2Y8L2Rpdj4NCjxkaXY+JnF1b3Q7 Li4uIGZvciBlbnN1cmluZyB0aGUgY29uZmlkZW50aWFsaXR5JnF1b3Q7LCBzaW5jZSBjb25maWRl bnRpYWxpdHkgaXMgb25seSBvbmUgYXNwZWN0IG9mIHNlY3VyaXR5LjwvZGl2Pg0KPGRpdj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIi PjItIFNlY3Rpb24gOC4xLCBwbGVhc2UgY2hlY2sgdGhlIHBhcmFncmFwaCDCqyBOb3RlIHRoYXQg aW4gYSDCqyBkaWFtb25kIMK7PGJyIGNsYXNzPSIiPg0KY29uZmlndXJhdGlvbiBb4oCmXSDCuy4g VGhpcyBwYXJhZ3JhcGggaXMgcmF0aGVyIGNvbmZ1c2luZyB0byBtZS4gQ29uZnVzaW9uPGJyIGNs YXNzPSIiPg0KY29tZXMgZnJvbTo8YnIgY2xhc3M9IiI+DQotIHRoZSBsYWNrIG9mIGRlc2NyaXB0 aW9uIG9mIHRoZSDCqyBkaWFtb25kIGNvbmZpZ3VyYXRpb24gwrsuIEkgdW5kZXJzdGFuZDxiciBj bGFzcz0iIj4NCnRoZXJlIGlzIG9uZSBkQ0ROIG9uIHRvcCBhbmQgbXVsdGlwbGUgdUNETiBkaXJl Y3RseSBjb25uZWN0ZWQgYmVsb3csIGFtIEk8YnIgY2xhc3M9IiI+DQpyaWdodD88YnIgY2xhc3M9 IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpZZXMsIHRoYXQncyByaWdodC4gVGhl IGRyYWZ0IHNheXM6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Tm90ZSB0aGF0 IGluIGEgJnF1b3Q7ZGlhbW9uZCZxdW90OyBjb25maWd1cmF0aW9uLCB3aGVyZSBvbmUgdUNETidz IGNvbnRlbnQgY2FuPGJyIGNsYXNzPSIiPg0KJm5ic3A7YmUgYWNxdWlyZWQgdmlhIG1vcmUgdGhh biBvbmUgZGlyZWN0bHktY29ubmVjdGVkIHVDRE4sPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KV291bGQgdGhlIGZvbGxvd2luZyByZWFycmFuZ2VtZW50IGhlbHA/IC4uLjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCiZuYnNwO0EgJnF1b3Q7ZGlhbW9uZCZxdW90OyBjb25maWd1cmF0 aW9uIGlzIG9uZSB3aGVyZSBhIGRDRE4gY2FuIGFjcXVpcmUgYSB1Q0ROJ3M8YnIgY2xhc3M9IiI+ DQombmJzcDtjb250ZW50IHZpYSBtb3JlIHRoYW4gb25lIGRpcmVjdGx5LWNvbm5lY3RlZCB1Q0RO LiBOb3RlIHRoYXQ8YnIgY2xhc3M9IiI+DQombmJzcDtpbiBhIGRpYW1vbmQgY29uZmlndXJhdGlv biBb4oCmXTxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NClllcywg SSBwcmVmZXIgdGhpcyB2ZXJzaW9uLiBIb3dldmVyLCBjYW4gdGhlIHNhbWUgwqsgdUNETuKAmXMg Y29udGVudCDCuyBiZTxiciBjbGFzcz0iIj4NCmF2YWlsYWJsZSBhdCBzZXZlcmFsIHVDRE5zIGlu IHRoaXMgZGlhbW9uZCBjb25maWd1cmF0aW9uPyBTYWlkIGRpZmZlcmVudGx5LDxiciBjbGFzcz0i Ij4NCndoYXQgYWJvdXQgdGhlIGZvbGxvd2luZyB0ZXh0OjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOiBw cmU7Ij48L3NwYW4+QSDCqyBkaWFtb25kIMK7IGNvbmZpZ3VyYXRpb24gaXMgb25lIHdoZXJlIGEg ZENETiBjYW4gYWNxdWlyZSBhIGdpdmVuPGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IkFwcGxl LXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6IHByZTsiPjwvc3Bhbj5jb250ZW50IHZpYSBt b3JlIHRoYW4gb25lIGRpcmVjdGx5LWNvbm5lY3RlZCB1Q0ROLiBOb3RlIHRoYXQgW+KApl08YnIg Y2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpZZXMsIG1vcmUgdGhhbiBv bmUgdUNETiB3aWxsIGhhdmUgdGhlIHNhbWUgY29udGVudCAtIGJ1dCB0aGUgaW1wb3J0YW50IHBv aW50IGlzIHRoYXQgdWx0aW1hdGVseSB0aGV5IHdpbGwgYWxsIGhhdmUgYWNxdWlyZWQgaXQgZnJv bSB0aGUgc2FtZSB1Q0ROLCBhbmQgdGhhdCB1Q0ROIG93bnMgdGhlIG1ldGFkYXRhLjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCkkndmUgdHJpZWQgdG8gcHJvdmlkZSBhIGJldHRlciBpbnRy by9leHBsYW5hdGlvbiBpbiBuZXcgc2VjdGlvbiAyLjIuMSAmcXVvdDtNdWx0aXBsZSBpbnRlcmNv bm5lY3RlZCBDRE5zJnF1b3Q7LiBIb3BlZnVsbHkgdGhhdCBtYWtlcyBpdCBhIGJpdCBjbGVhcmVy PzxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2PlllcywgYXMgc2FpZCBhYm92ZSwgc2VjdGlvbiAyLjIuMSBpcyByYXRoZXIgdXNlZnVs LjwvZGl2Pg0KPGRpdj5KdXN0IGEgY29tbWVudCBmb3IgdGhpcyBzZWN0aW9uIDIuMi4xLCB0aGly ZCBwYXJhZ3JhcGgsIGxhc3Qgc2VudGVuY2UuIFlvdSBtZW50aW9uPC9kaXY+DQo8ZGl2PmJvdGgg JnF1b3Q7aW50ZXJtZWRpYXRlIENETiZxdW90OyBhbmQganVzdCBhZnRlciAmcXVvdDtpbnRlcm1l ZGlhdGUgdUNETiZxdW90Oy4gVGhpcyBpcyBhIGJpdCBjb25mdXNpbmcuPC9kaXY+DQo8ZGl2Pjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5Bbm90aGVyIGRldGFpbDogaW4gc2Vjb25kIHBhcmFn cmFwaCB5b3UgbWVudGlvbiAmcXVvdDsmcXVvdDtpbnRlcm1lZGlhdGUmcXVvdDsgQ0ROJnF1b3Q7 IHdpdGggZXh0cmEgJnF1b3Q7ICZxdW90OzwvZGl2Pg0KPGRpdj5hcm91bmQgaW50ZXJtZWRpYXRl LiBQbGVhc2UgaGFybW9uaXplLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4zLSBXaXRo IHRoaXMgwqsgZGlhbW9uZCBjb25maWd1cmF0aW9uIMK7LCBzaW5jZSBzZXZlcmFsIHVDRE4gY2Fu IGFjdCB1cG9uIHRoZTxiciBjbGFzcz0iIj4NCnNhbWUgY29udGVudCwgd2hhdCBoYXBwZW5zIGlm IHRoZXkgYmVoYXZlIGluIGEgbm9uIGNvb3JkaW5hdGVkIG1hbm5lciAoaS5lLiw8YnIgY2xhc3M9 IiI+DQppbiB0aGUgZ2VuZXJhbCBjYXNlKT8gRm9yIGluc3RhbmNlIGxldOKAmXMgaW1hZ2luZSBv bmUgb2YgdGhlbSBhc2tzIHRoZSBkQ0ROPGJyIGNsYXNzPSIiPg0KdG8gZGVsZXRlIHRoZSBjb250 ZW50IG9yIGNhbmNlbCB0aGUgaW5pdGlhbCBjb21tYW5kLiBXaGF0IGhhcHBlbnMgaWYgYW5vdGhl cjxiciBjbGFzcz0iIj4NCnVDRE4gdGhlbiBhc2tzIHRoZSBkQ0ROIHRvIGludmFsaWRhdGUgdGhp cyBjb250ZW50LCBwcm92aWRpbmcgdGhlIFVSTCBvZiB0aGU8YnIgY2xhc3M9IiI+DQpUcmlnZ2Vy IFN0YXR1cyBSZXNvdXJjZSB3aGljaCAoaWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSkgaXMgbm8g bG9uZ2VyIHZhbGlkPzxiciBjbGFzcz0iIj4NClRoaXMgwqsgZGlhbW9uZCBjb25maWd1cmF0aW9u IMK7IGNhbiBiZSBhIGxpdHRsZSBiaXQgdHJpY2t5IGFuZCBubyBjbGVhcjxiciBjbGFzcz0iIj4N Cmd1aWRlbGluZSBpcyBwcm92aWRlZCBpbiB0aGUgZG9jdW1lbnQuPGJyIGNsYXNzPSIiPg0KPC9i bG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KQSB0cmlnZ2VyIHN0YXR1cyByZXNvdXJjZSBiZWxv bmdzIHRvIG9uZSB1Q0ROIGFuZCBjYW5ub3QgYmUgYWNjZXNzZWQgb3I8YnIgY2xhc3M9IiI+DQpt YW5pcHVsYXRlZCBieSBhbnkgb3RoZXIgQ0ROLCBzZWN0aW9uIDMgcGFyYSAzIHNheXM6PGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7VHJpZ2dlciBTdGF0dXMgUmVzb3VyY2VzIGJl bG9uZ2luZyB0byBhIHVDRE4gTVVTVCBOT1Q8YnIgY2xhc3M9IiI+DQombmJzcDtiZSB2aXNpYmxl IHRvIGFueSBvdGhlciBDRE4uIFRoZSBkQ0ROIGNvdWxkLCBmb3IgZXhhbXBsZSwgYWNoaWV2ZTxi ciBjbGFzcz0iIj4NCiZuYnNwO3RoaXMgYnkgb2ZmZXJpbmcgZGlmZmVyZW50IGNvbGxlY3Rpb24g VVJMcyB0byBlYWNoIHVDRE4sIGFuZC9vciBieTxiciBjbGFzcz0iIj4NCiZuYnNwO2ZpbHRlcmlu ZyB0aGUgcmVzcG9uc2UgYmFzZWQgb24gdGhlIHVDRE4gd2l0aCB3aGljaCB0aGUgSFRUUCBjbGll bnQ8YnIgY2xhc3M9IiI+DQombmJzcDtpcyBhc3NvY2lhdGVkLjxiciBjbGFzcz0iIj4NCjwvYmxv Y2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCkkgc2Vl4oCmIEhvd2V2ZXIsIGlmIG11bHRpcGxlIHVD RE5zIGNhbiBhY3Qgb24gdGhlIHNhbWUgY29udGVudCAod2hhdCBpcyBzYWlkKSw8YnIgY2xhc3M9 IiI+DQpldmVuIGlmIGVhY2ggdUNETiB1c2VzIGEgZGlmZmVyZW50IFVSTCwgd2lsbCBzaW11bHRh bmVvdXMgQ0kvVCBjb21tYW5kcyBmb3I8YnIgY2xhc3M9IiI+DQp0aGUgc2FtZSBjb250ZW50IGJl IG1hbmFnZWQgY29ycmVjdGx5PyBUaGlzIGlzIG5vdCBzYWlkIGluIHNlY3Rpb24gMzxiciBjbGFz cz0iIj4NCnBhcmFncmFwaCAzIGVpdGhlciBhbmQgdGhpcyBpcyBhIGtleSBwb2ludC48YnIgY2xh c3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpTb3JyeSwgSSdkIG1pc3NlZCB5 b3VyIHBvaW50LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkludGVyYWN0aW9ucyBjYW4g YmUgaW5lZmZpY2llbnQsIGJ1dCBhcmUgb3RoZXJ3aXNlIGhhcm1sZXNzIGJlY2F1c2UgdGhlIHN0 cm9uZ2VzdCBvZiAmcXVvdDtpbnZhbGlkYXRlJnF1b3Q7IG9yICZxdW90O3B1cmdlJnF1b3Q7IHdp bGwgd2luLCBhbmQgY29udGVudCBjYW4gYWx3YXlzIGJlIHJlLWFjcXVpcmVkIGlmIGl0J3Mgc3Rp bGwgYXZhaWxhYmxlIGZyb20gYW55IHVDRE4uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K SSd2ZSBnaXZlbiBzb21lIGV4YW1wbGVzIGluIG5ldyBzZWN0aW9uIDIuMi4xICZxdW90O011bHRp cGxlIGludGVyY29ubmVjdGVkIENETnMmcXVvdDssIGFuZCBhZGRlZCBhIHBvaW50ZXIgdG8gdGhh dCBmcm9tIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uLjxiciBjbGFzcz0iIj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2Pk9uY2UgYWdh aW4sIHRoZSBleGFtcGxlcyBvZiBzZWN0aW9uIDIuMi4xIGFuc3dlciBteSBjb21tZW50cy4gVGhh bmtzLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIg Y2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5Db250ZW50IGFsd2F5 cyBvcmlnaW5hdGVzIGZyb20gb25lIHVDRE4sIGJ1dCBpbiBhIGRpYW1vbmQgY29uZmlncmF0aW9u IHRoZXJlPGJyIGNsYXNzPSIiPg0KbWF5IGJlIG11bHRpcGxlIHJvdXRlcyAodmlhIG90aGVyIENE TnMpIHRvIGEgZ2l2ZW4gZENETi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGUgbW9z dCBjb21tb24gc2NlbmFyaW8gbWF5IHdlbGwgYmUgdGhhdCB0aGUgdUNETiB3aWxsIGluaXRpYXRl IGFsbCBvZiB0aGU8YnIgY2xhc3M9IiI+DQpDSS9UIGNvbW1hbmRzIHJlbGF0ZWQgdG8gaXRzIGNv bnRlbnQsIGFuZCB0aG9zZSBjb21tYW5kcyB3aWxsIHNpbXBseSBiZTxiciBjbGFzcz0iIj4NCmZv cndhcmRlZCBieSBpbnRlcm1lZGlhdGUgQ0ROcy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQpCdXQsIHRoZXJlJ3Mgbm90aGluZyB0byBzdG9wIGFuIGludGVybWVkaWF0ZSBDRE4gaW5pdGlh dGluZyBvciBtb2RpZnlpbmc8YnIgY2xhc3M9IiI+DQpDSS9UIGNvbW1hbmRzIC0gYW5kIHNvbWUg bW9kaWZpY2F0aW9ucyBvZiB0aGUgY29tbWFuZCB3aWxsIGJlIG5lY2Vzc2FyeTxiciBjbGFzcz0i Ij4NCihmb3IgZXhhbXBsZSwgbWV0YWRhdGEgVVJMcyB3aWxsIG5lZWQgdG8gYmUgY2hhbmdlZCku PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQnkgYW5hbHlzaXMgb2YgbG9nIGZpbGVzIGl0 IHdpbGwgcHJvYmFibHkgYmUgcG9zc2libGUgdG8gd29yayBvdXQgd2hpY2g8YnIgY2xhc3M9IiI+ DQp1Q0ROIGFuIGluZGl2aWR1YWwgY2FjaGUgaW4gdGhlIGRDRE4gYWNxdWlyZWQgZWFjaCBjYWNo ZWQgcmVzb3VyY2UgZnJvbS48YnIgY2xhc3M9IiI+DQpCdXQgdGhlIGNhY2hlIGlzIG5vdCByZXF1 aXJlZCB0byBrZWVwIGEgbGl2ZSByZWNvcmQgb2YgdGhhdCwgYW5kIGl0PGJyIGNsYXNzPSIiPg0K cHJvYmFibHkgd29uJ3QuIEluIHRoYXQgY2FzZSwgd2hlbiBpdCByZWNlaXZlcyBhIENJL1QgY29t bWFuZCB0byBpbnZhbGlkYXRlPGJyIGNsYXNzPSIiPg0Kb3IgcHVyZ2UgY29udGVudCwgdGhlIGRD RE4gc2hvdWxkIGFwcGx5IHRoYXQgY29tbWFuZCB0byBhbnkgY29udGVudCBpdDxiciBjbGFzcz0i Ij4NCm1heSBoYXZlIGFjcXVpcmVkIGZyb20gdGhlIHVDRE4gaXQgZ290IHRoZSBDSS9UIGNvbW1h bmQgZnJvbS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpTbyB0aGVyZSBpcyBzY29wZSBm b3IgYSBtYWxpY2lvdXMgaW50ZXJtZWRpYXRlIENETiB0byBjYXVzZSBleHRyYSBwcm9jZXNzaW5n PGJyIGNsYXNzPSIiPg0KYW5kIGFjcXVpc2l0aW9uIGJ5IGEgZENETiAoYW5kIHRoYXQncyBtZW50 aW9uZWQgaW4gc2VjdGlvbiA4KS4gQnV0IGE8YnIgY2xhc3M9IiI+DQptYWxpY2lvdXMgQ0ROIGlz IGxpa2VseSB0byBmaW5kIGl0c2VsZiByZW1vdmVkIGZyb20gdGhlIENETiBmZWRlcmF0aW9uIGZh aXJseTxiciBjbGFzcz0iIj4NCnF1aWNrbHkgLSB0aGVyZSB3aWxsIG5lY2Vzc2FyaWx5IGJlIGEg bGV2ZWwgb2YgdHJ1c3QgYmV0d2VlbiBpbnRlcmNvbm5lY3RlZDxiciBjbGFzcz0iIj4NCkNETnMu PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KV291bGQgaXQgaGVscCB0byBzcGVsbCBvdXQg c29tZSBvZiB0aGF0IGluIHRoZSBkcmFmdD8gKFRoZSBzYW1lIG9yIHZlcnk8YnIgY2xhc3M9IiI+ DQpzaW1pbGFyIHRleHQgaGFzIGJlZW4gdXNlZCBpbiBzZXZlcmFsIG9mIHRoZSBDRE5JIGRyYWZ0 cy4pPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KWWVzLCB0aGlz IHBhcmFncmFwaCBpcyB3b3J0aCBiZWluZyBkZXRhaWxlZCBhIGxpdHRsZSBiaXQuPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KSW4geW91ciBleHBsYW5hdGlvbnMgeW91IG1lbnRpb24gaW50 ZXJtZWRpYXRlIENETnMgd2hpbGUgb3JpZ2luYWwgdGV4dCBvbmx5PGJyIGNsYXNzPSIiPg0KbWVu dGlvbnMgZGlyZWN0bHkgY29ubmVjdGVkIHVDRE5zLiBUaGUgbm90aW9uIG9mIMKrIGludGVybWVk aWF0ZSBDRE4gwrsgaXM8YnIgY2xhc3M9IiI+DQpvbmx5IGRpc2N1c3NlZCBpbiBzZWN0aW9ucyAy LjMgYW5kIDQuOC4gU2luY2UgbWFsaWNpb3VzIGludGVybWVkaWF0ZSBDRE5zIGFyZTxiciBjbGFz cz0iIj4NCnBhcnQgb2YgYSB2YWxpZCBhdHRhY2sgbW9kZWwsIGl0IGlzIHdvcnRoIHRvIGV4cGxh aW4gaXQgKG9yIGdpdmUgYSByZWZlcmVuY2UgdG8gYW5vdGhlcjxiciBjbGFzcz0iIj4NCmRvY3Vt ZW50KS48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpXaGVuIGEg Y29udGVudCBvd25lciwgdGhlIG9yaWdpbiwgZGVsZWdhdGVzIGRlbGl2ZXJ5IHRvIGEgQ0ROIGl0 IGlzIHRydXN0aW5nIHRoYXQgQ0ROIHRvIGRlbGl2ZXIgdGhlIHJpZ2h0IGNvbnRlbnQgb24gaXRz IGJlaGFsZi4gQSBtYWxpY2lvdXMgQ0ROIGNvdWxkIGRlbGl2ZXIgYW55dGhpbmcgaW5zdGVhZCwg YnV0IGl0IHdvdWxkIHNvb24gbG9zZSB0aGUgdHJ1c3Qgb2YgdGhlIG9yaWdpbi48YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpDRE4taW50ZXJjb25uZWN0aW9uIHNpbXBseSBleHRlbmRzIHRo YXQgdHJ1c3QgdG8gdGhlIGZ1cnRoZXItZG93bnN0cmVhbSBDRE5zIGFjdGluZyBvbiBiZWhhbGYg b2YgdGhlIG9yaWdpbmFsLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClNvIGVzdGFibGlz aG1lbnQvZW5mb3JjZW1lbnQgb2YgdGhlIHRydXN0IHJlbGF0aW9uc2hpcCBpdHNlbGYsIHRoZSBj b250cmFjdCBiZXR3ZWVuIHRoZSBvcmlnaW4gYW5kIHRoZSBDRE4sIGlzIG91dHNpZGUgdGhlIHNj b3BlIG9mIENETkkgYW5kIGluIHRoZSBsYW5kIG9mIGNvbW1lcmNpYWwgYWdyZWVtZW50cy48YnIg Y2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp dj5TdXJlLCBJIGFncmVlLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxiciBj bGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPkkndmUgYWRkZWQgYSBu b3RlIG9uIHRoYXQgaW4gdGhlIGludHJvIHRvIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBz ZWN0aW9uLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2PlRoYXQncyBwZXJmZWN0LjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGIgY2xhc3M9IiI+VG8gY29uY2x1ZGUgdGhlIGRvY3VtZW50IGlzIG9r YXkgZnJvbSBteSBwb2ludCBvZiB2aWV3LjwvYj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoYW5rcyBmb3IgeW91ciBkZXRhaWxlZCBh bnN3ZXJzLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5DaGVlcnMsPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7VmluY2Vu dDwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_D04BAD9583284DB7B408C32DCEE268B2alcatellucentcom_-- From nobody Sun Apr 17 04:45:24 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2576312DA63; Sun, 17 Apr 2016 04:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jNy635Fxda4; Sun, 17 Apr 2016 04:45:21 -0700 (PDT) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by ietfa.amsl.com (Postfix) with ESMTP id BA43512DAAB; Sun, 17 Apr 2016 04:45:21 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [198.74.231.63]) by cyrus.watson.org (Postfix) with ESMTPS id 2125546B2E; Sun, 17 Apr 2016 07:45:21 -0400 (EDT) Received: from fledge.watson.org (weiler@localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.15.2/8.15.2) with ESMTP id u3HBjKf5014289; Sun, 17 Apr 2016 07:45:20 -0400 (EDT) (envelope-from weiler+ietf@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.15.2/8.15.2/Submit) with ESMTP id u3HBjKVX014286; Sun, 17 Apr 2016 07:45:20 -0400 (EDT) (envelope-from weiler+ietf@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Sun, 17 Apr 2016 07:45:20 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org, iesg@ietf.org, draft-ietf-avtext-sdes-hdr-ext.all@ietf.org Message-ID: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (fledge.watson.org [127.0.0.1]); Sun, 17 Apr 2016 07:45:20 -0400 (EDT) Archived-At: Subject: [secdir] secdir review of draft-ietf-avtext-sdes-hdr-ext X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2016 11:45:23 -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. I am mostly satisfied with this document's security analysis. I am worried that implementors will weasel their way around the "SHOULD"s, but the appropriate "SHOULD"s are in the doc. The doc says "...there SHOULD be strong integrity protection and source authentication of the header extensions" -- I would like to also see specific citation(s). (e.g. "Use X for integrity protection." "Use X for authenticity.") It would be nice to see some discussion of whether these headers increase the utility of RTP as a DOS vector - either by enabling a reflector attack or by triggering heavy computation on a receiving host. I suspect that there's not much to see here, particularly if there really is integrity protection, but it would be nice to see the analysis. Editorial comment: For the RTP-naive reader, I suggest adding an early mention that SDES is (normally) a special packet type within RTP. Specifically: it would be helpful for Section 1 to also say "RTP has a special packet type for Source Description (SDES) items." From nobody Mon Apr 18 02:33:46 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E0112DAB8; Mon, 18 Apr 2016 02:33:29 -0700 (PDT) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCNDakvgwtYt; Mon, 18 Apr 2016 02:33:27 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9A8312DAAB; Mon, 18 Apr 2016 02:33:26 -0700 (PDT) X-AuditID: c1b4fb3a-f795d6d000004243-f6-5714a9e54df3 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A1.8D.16963.5E9A4175; Mon, 18 Apr 2016 11:33:25 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.3.248.2; Mon, 18 Apr 2016 11:33:12 +0200 To: Samuel Weiler , , , , "avtext@ietf.org" References: From: Magnus Westerlund Message-ID: <5714A9D6.4010602@ericsson.com> Date: Mon, 18 Apr 2016 11:33:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUyM2K7t+7TlSLhBlM7xCw+3rvBajFjygFm ixl/JjJbfFj4kMViwuvpTA6sHkuW/GTyWNqwmz2AKYrLJiU1J7MstUjfLoErY+6u7ywF29Qq DiyezNrAeF+ui5GTQ0LAROLmi6MsELaYxIV769m6GLk4hASOMErMu/GIHcJZziixbP0SdpAq YQEbibP3roIlRASWMUpMWf8ALCEk4CxxYPsOsFFsAhYSN380soHYvALaEq2z2lhBbBYBVYnr r16C1YsKxEg0PjjFBFEjKHFy5hOwXk4BF4nJD04A1XNwMAvYSzzYWgYSZhaQl2jeOpsZYpW2 RENTB+sERoFZSLpnIXTMQtKxgJF5FaNocWpxcW66kZFealFmcnFxfp5eXmrJJkZg0B7c8ttq B+PB546HGAU4GJV4eBPYRcKFWBPLiitzDzFKcDArifC6rwAK8aYkVlalFuXHF5XmpBYfYpTm YFES582J/BcmJJCeWJKanZpakFoEk2Xi4JRqYHRZ31D2NfhIeZTZrK8cS/qmfJ88YUVpuExg 9+m23tM3RKZs7Pzr+PxgVORKvlPbtd6e5L7Sei/05qyJodO2eO6tqqkJLxXW4P/Q+2+i0/Kd 61SS9DI7lRQ7VJ0k6o1MzR+f2y0Q8N3044wMqUuHE8z1e2YzX7uupxPMfcJU9DCb/PwUwbKj t5RYijMSDbWYi4oTAQeWrVBWAgAA Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-avtext-sdes-hdr-ext X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 09:33:29 -0000 Hi Samuel, (CC the WG) Thanks for the review. Den 2016-04-17 kl. 13:45, skrev Samuel Weiler: > 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 am mostly satisfied with this document's security analysis. I am > worried that implementors will weasel their way around the "SHOULD"s, > but the appropriate "SHOULD"s are in the doc. > > The doc says "...there SHOULD be strong integrity protection and source > authentication of the header extensions" -- I would like to also see > specific citation(s). (e.g. "Use X for integrity protection." "Use X > for authenticity.") So I will claim that the common problem that exists with minor RTP extension and RTP payload formats (see RFC 7202) do apply here, we should at least reference RFC 7201 for the options in the security consideration section. I will edit our source and likely push out such a change quite soon so that it is in place in good time before the IESG call. Unless our AD objects. I propose to add the below to end of the last paragraph. "For information regarding options for securing RTP, see [RFC7201]." And add RFC7201 as an informative reference. > > It would be nice to see some discussion of whether these headers > increase the utility of RTP as a DOS vector - either by enabling a > reflector attack or by triggering heavy computation on a receiving > host. I suspect that there's not much to see here, particularly if > there really is integrity protection, but it would be nice to see the > analysis. Yes, this is a reasonable thing to consider. I suggest that we add the below paragraph before the last paragraph in the Security Consideration. The general RTP header extension mechanism does not itself contain any functionality that is a significant risk for a denial of service attack, nor from processing or storage requirements. This specific extension for SDES items, could potentially be a risk. If the received SDES item and its content causes the receiver to perform larger amount of processing, create significant storage structures, or emit more network traffic such a risk do exist. The CNAME SDES item is only a minor risk as reception of a CNAME item will create an association between the stream carrying the SDES item and other RTP streams with the same SDES item. As this can result in time synchronizing the media streams some additional processing may result. However, the applications media quality appear will be likely more affected of the wrongly or changing association, than from the impact caused by the additional processing. > > > Editorial comment: > > For the RTP-naive reader, I suggest adding an early mention that SDES > is (normally) a special packet type within RTP. Specifically: it > would be helpful for Section 1 to also say "RTP has a special packet > type for Source Description (SDES) items." I guess what you are intersted is an expansion of the following text: OLD: This specification defines an RTP header extension [RFC3550][RFC5285] that can carry RTCP source description (SDES) items. By including selected SDES items in a header extension the determination of relationship and synchronization context for new RTP streams (SSRCs) in an RTP session can be optimized. Which relationship and what information depends on the SDES items carried. This becomes a complement to using only RTCP for SDES Item delivery. NEW (Second sentence): This specification defines an RTP header extension [RFC3550][RFC5285] that can carry RTCP source description (SDES) items. Normally the SDES items are carried in their own RTCP packet type. By including selected SDES items in a header extension the determination of relationship and synchronization context for new RTP streams (SSRCs) in an RTP session can be optimized. Which relationship and what information depends on the SDES items carried. This becomes a complement to using only RTCP for SDES Item delivery. Does this addresses the editorial issue? Any feedback on the proposed changes? Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Apr 18 02:49:13 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E96D12D8B9; Mon, 18 Apr 2016 02:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-8OZbx-48CU; Mon, 18 Apr 2016 02:48:58 -0700 (PDT) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by ietfa.amsl.com (Postfix) with ESMTP id C050E12D803; Mon, 18 Apr 2016 02:48:58 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [198.74.231.63]) by cyrus.watson.org (Postfix) with ESMTPS id E102946B35; Mon, 18 Apr 2016 05:48:57 -0400 (EDT) Received: from fledge.watson.org (weiler@localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.15.2/8.15.2) with ESMTP id u3I9mvmG010755; Mon, 18 Apr 2016 05:48:57 -0400 (EDT) (envelope-from weiler+ietf@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.15.2/8.15.2/Submit) with ESMTP id u3I9mvIi010751; Mon, 18 Apr 2016 05:48:57 -0400 (EDT) (envelope-from weiler+ietf@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 18 Apr 2016 05:48:56 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: Magnus Westerlund In-Reply-To: <5714A9D6.4010602@ericsson.com> Message-ID: References: <5714A9D6.4010602@ericsson.com> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (fledge.watson.org [127.0.0.1]); Mon, 18 Apr 2016 05:48:57 -0400 (EDT) Archived-At: Cc: draft-ietf-avtext-sdes-hdr-ext.all@ietf.org, "avtext@ietf.org" , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-avtext-sdes-hdr-ext X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 09:49:01 -0000 On Mon, 18 Apr 2016, Magnus Westerlund wrote: > And add RFC7201 as an informative reference. That makes sense to me. > Yes, this is a reasonable thing to consider. I suggest that we add the below > paragraph before the last paragraph in the Security Consideration. .... This is the right idea. It would be good for someone else in the WG to weigh in on its correctness and completeness. The proposed text needs minor editting, but that can wait for the RFC Editor, if needed. > Does this addresses the editorial issue? Yes, perfectly. Thank you for the quick and receptive response. -- Sam From nobody Mon Apr 18 07:29:47 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F8E12D818; Mon, 18 Apr 2016 07:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ly11Cm6g0bVG; Mon, 18 Apr 2016 07:29:44 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EA9212D68D; Mon, 18 Apr 2016 07:29:44 -0700 (PDT) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u3IETdTr008772 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 18 Apr 2016 09:29:39 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Magnus Westerlund" Date: Mon, 18 Apr 2016 09:29:38 -0500 Message-ID: <6A8437B6-9F42-4293-96AC-6FCE3D8DCD91@nostrum.com> In-Reply-To: <5714A9D6.4010602@ericsson.com> References: <5714A9D6.4010602@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: iesg@ietf.org, draft-ietf-avtext-sdes-hdr-ext.all@ietf.org, "avtext@ietf.org" , Samuel Weiler , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-avtext-sdes-hdr-ext X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 14:29:46 -0000 On 18 Apr 2016, at 4:33, Magnus Westerlund wrote: > Hi Samuel, > > (CC the WG) > > Thanks for the review. > > Den 2016-04-17 kl. 13:45, skrev Samuel Weiler: >> 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 am mostly satisfied with this document's security analysis. I am >> worried that implementors will weasel their way around the "SHOULD"s, >> but the appropriate "SHOULD"s are in the doc. >> >> The doc says "...there SHOULD be strong integrity protection and >> source >> authentication of the header extensions" -- I would like to also see >> specific citation(s). (e.g. "Use X for integrity protection." "Use >> X >> for authenticity.") > > So I will claim that the common problem that exists with minor RTP > extension and RTP payload formats (see RFC 7202) do apply here, we > should at least reference RFC 7201 for the options in the security > consideration section. > > I will edit our source and likely push out such a change quite soon so > that it is in place in good time before the IESG call. Unless our AD > objects. > > I propose to add the below to end of the last paragraph. > > "For information regarding options for securing RTP, see [RFC7201]." > > And add RFC7201 as an informative reference. The AD does not object. I think it makes sense to treat this similarly to how we treat payload drafts. > >> >> It would be nice to see some discussion of whether these headers >> increase the utility of RTP as a DOS vector - either by enabling a >> reflector attack or by triggering heavy computation on a receiving >> host. I suspect that there's not much to see here, particularly if >> there really is integrity protection, but it would be nice to see the >> analysis. > > Yes, this is a reasonable thing to consider. I suggest that we add the > below paragraph before the last paragraph in the Security > Consideration. > > The general RTP header extension mechanism does not itself contain any > functionality that is a significant risk for a denial of service > attack, nor from processing or storage requirements. This specific > extension for SDES items, could potentially be a risk. Do you mean that _this_ extension might be a risk, or that any specific SDES item might be a risk? The sentence sounds like it means the former, but the rest of the paragraph suggests the latter. > If the received SDES item and its content causes the receiver to > perform larger amount of processing, create significant storage > structures, or emit more network traffic such a risk do exist. The > CNAME SDES item is only a minor risk as reception of a CNAME item will > create an association between the stream carrying the SDES item and > other RTP streams with the same SDES item. As this can result in time > synchronizing the media streams some additional processing may result. > However, the applications media quality appear will be likely more > affected of the wrongly or changing association, than from the impact > caused by the additional processing. > > > >> [...] From nobody Mon Apr 18 11:56:20 2016 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A7012E3C1; Mon, 18 Apr 2016 10:37:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1461001072; bh=WUIkcIn1mtfFtokjDZDaPK8HrxEf+i3T9PCaDldFrbM=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=h418RE1gHHMWisYuKnAkkTaF7fkrcJVXKHHMHIn7qUPdW4Rc/KTcAQqbW9hcM3mwu Trbx91w3grnJxO7J3dEyH5icWRc70TRZYB5kMWoLHmwFdezAs0dfG8WbEH5bdV+pja UI3GxpXFBGir/paG4/7qDBz2zf7xla8wc4rLl3zA= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B315A12E032 for ; Mon, 11 Apr 2016 20:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPQSnGB5YbJk for ; Mon, 11 Apr 2016 20:20:02 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B1E112E031 for ; Mon, 11 Apr 2016 20:20:02 -0700 (PDT) Received: from [111.202.109.2] (helo=[192.168.1.37]) by raoul.w3.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1aporv-000BXy-Lo for new-work@ietf.org; Tue, 12 Apr 2016 03:20:00 +0000 To: new-work@ietf.org From: Xueyuan Jia Message-ID: <570C697E.3070605@w3.org> Date: Tue, 12 Apr 2016 11:20:30 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Mon, 18 Apr 2016 10:37:51 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Mon, 18 Apr 2016 11:56:19 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Browser Testing and Tools Working Group (until 2016-05-03) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 17:37:53 -0000 Hello, W3C Advisory Committee Representatives received a Proposal to review a draft charter for the Browser Testing and Tools Working Group: http://w3c.github.io/charter-drafts/browser-testing-tools.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 2016-05-03 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [1], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Michael[tm] Smith, Browser Testing and Tools Working Group Team Contact . Thank you, Xueyuan Jia, W3C Marketing & Communications [1] http://www.w3.org/Consortium/Member/List _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Mon Apr 18 11:56:22 2016 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DDE112E3C4; Mon, 18 Apr 2016 10:37:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1461001073; bh=dC5bZx7lIsjy6yPrmv+LFTtRLDZinKl2SKGnPH47vUs=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=H4MFaCN6SChIsfWSXh3722IsiBD9oaeqCHF7huTDGHrrz/2nMYhGa64ByyFSjINpr dLMEs7Ke2JhQmjtb2il7Z340iesKaf3fRSDwOOcs14xF0MPw4gHxN8O/0E2uw72yHt 8H9SsJLVyVTwTWeG/bTaNP/IDw1PcSgFk8Fk6hps= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51FC812D6C9 for ; Fri, 15 Apr 2016 01:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXbE1dFQi_ko for ; Fri, 15 Apr 2016 01:14:52 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 335C812D60E for ; Fri, 15 Apr 2016 01:14:52 -0700 (PDT) Received: from [2001:da8:203:85:d80a:5015:acbf:480] by raoul.w3.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1aqytt-0006yM-Qz for new-work@ietf.org; Fri, 15 Apr 2016 08:14:50 +0000 To: new-work@ietf.org From: Xueyuan Jia Message-ID: <5710A370.3040200@w3.org> Date: Fri, 15 Apr 2016 16:16:48 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Mon, 18 Apr 2016 10:37:51 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Mon, 18 Apr 2016 11:56:19 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Timed Text Working Group (until 2016-05-13) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 17:37:53 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to review a draft charter for the Timed Text Working Group : http://w3c.github.io/charter-drafts/timed-text-charter-2016.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 2016-05-13 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [1], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Philippe Le Hegaret, Interaction Domain Lead , or Thierry Michel, Timed Text Working Group Team Contact . Thank you, Xueyuan Jia, W3C Marketing & Communications [1] http://www.w3.org/Consortium/Member/List _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Mon Apr 18 13:57:24 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D3612E7CD for ; Mon, 18 Apr 2016 13:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ija7pfXd6O-T for ; Mon, 18 Apr 2016 13:57:19 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9840A12E7C9 for ; Mon, 18 Apr 2016 13:57:19 -0700 (PDT) Received: by mail-qg0-x236.google.com with SMTP id c6so126551685qga.1 for ; Mon, 18 Apr 2016 13:57:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ldgJL5+LnFh9gyTa7wb6E/9BavUW/udQkmNP9OyP+90=; b=Tk8s4YI51/Gv/iyOBL62csvD5Dbc+L/T3fjJlZFlNFEQ9cafzKQh1/0Fiins1TOLYa wjI+ZCDDiLar40z5OzhOlmyZQrTYE73BvECLGuM1E/1nLjCVXX5vwRRx0clkbIEbJcUj ZKUf0t2mVRj2McjzEm9OkLd8qs+69A00eKouY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ldgJL5+LnFh9gyTa7wb6E/9BavUW/udQkmNP9OyP+90=; b=TwVsSsrlJQHgkHKbQNQ8XM2Dg3Dgri2/r/AsedN+n7epscIEgU9LOLBDEEWga3eAAm kcOCslfhEuyiT64zpH1BgV3emakYNYiS8mP9O/oHPFGdHNKgrh/TPgxFI4vCWOo7g1ja rYSzx2VNgsO5SQ31cnGVZ9lod9wSv61GuqYxrQg+92NCPcDlh3E7ifbie2EccgAS2nrh j9tbjUY3lLq6aDhQ77tYpHeii46s3AzFbr7idh+FJC0Q91Lm45YTphUFpUZ/T3B19NzY aC/0ciUlQmuBXjD9ICuKbulBwKaeRumPUBGgwJviEpwDMN+ZVw72omnYwORuqLVPONCL WXsA== X-Gm-Message-State: AOPr4FVyOBO+vV7bQbN8CJSgkY7upPiu3V0/wqNoh0g4MHnMz3ShskZMeuXkx4v8ktahcw== X-Received: by 10.140.23.18 with SMTP id 18mr44621148qgo.91.1461013038524; Mon, 18 Apr 2016 13:57:18 -0700 (PDT) Received: from [172.16.0.112] ([96.231.217.211]) by smtp.gmail.com with ESMTPSA id y206sm27189688qhc.0.2016.04.18.13.57.17 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 18 Apr 2016 13:57:18 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <22284.56491.78790.777571@fireball.acr.fi> Date: Mon, 18 Apr 2016 16:57:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1EB8FC0A-E485-458F-A628-AC8C41DC83B5@sn3rd.com> References: <0C91ECA5-3412-4CEC-9A05-AEEAFCFC176D@sn3rd.com> <22284.56491.78790.777571@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3124) Archived-At: Cc: secdir@ietf.org Subject: Re: [secdir] use .all@ietf.org X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 20:57:22 -0000 On Apr 12, 2016, at 07:31, Tero Kivinen wrote: >=20 > Sean Turner writes: >> Before I go off and update the secdir wiki (assuming I can): >>=20 >> Right now it says to use =E2=80=8B.all@tools.ietf.org in a = couple >> of places and we should really be using =E2=80=8B.all@ietf.o= rg=20 >=20 > As far as I know both of them are working, so it might be better to > use the ietf.org version. So feel free to fix the wiki. Wiki changed. spt From nobody Tue Apr 19 01:03:41 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B10612DCCA; Tue, 19 Apr 2016 01:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnKCbJ51_F5w; Tue, 19 Apr 2016 01:03:22 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A9FD12DDEE; Tue, 19 Apr 2016 01:03:20 -0700 (PDT) X-AuditID: c1b4fb2d-f79006d000006928-c8-5715e646c5fe Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 62.38.26920.646E5175; Tue, 19 Apr 2016 10:03:18 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.3.248.2; Tue, 19 Apr 2016 10:03:05 +0200 To: Ben Campbell References: <5714A9D6.4010602@ericsson.com> <6A8437B6-9F42-4293-96AC-6FCE3D8DCD91@nostrum.com> From: Magnus Westerlund Message-ID: <5715E637.7070004@ericsson.com> Date: Tue, 19 Apr 2016 10:03:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <6A8437B6-9F42-4293-96AC-6FCE3D8DCD91@nostrum.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUyM2K7ja7bM9FwgzU7FSw+3rvBajG/8zS7 xYwpB5gtZvyZyGzxYeFDFosJr6czObB5LFnyk8lj1s4nLB5LG3azBzBHcdmkpOZklqUW6dsl cGVMmtPCVnBRsWLz2aNsDYz/pLoYOTkkBEwkFh9ZwgJhi0lcuLeerYuRi0NI4AijxIuLW1kh nOWMElf3XQSrEhawkTh77yo7iC0ioCTxvHkrC0TRLEaJg2+7wRxmgWWMElvnb2MGqWITsJC4 +aORDcTmFdCWeLPjMiOIzSKgKnG77R9YXFQgRqLxwSkmiBpBiZMzn4Bt4xSwl/h2bCnQGRxA Q+0lHmwtAwkzC8hLNG+dDTZeCGhkQ1MH6wRGwVlIumchdMxC0rGAkXkVo2hxanFxbrqRsV5q UWZycXF+nl5easkmRmCIH9zyW3cH4+rXjocYBTgYlXh4FSaKhguxJpYVV+YeYpTgYFYS4Q17 DBTiTUmsrEotyo8vKs1JLT7EKM3BoiTOmxP5L0xIID2xJDU7NbUgtQgmy8TBKdXAKFP/fE1u 0K1bvRktqdUNFtfkeNwOZSydYMIYk1HKUP/orPSlm7ZxOd3NBy65lNhJa8UZ/n3t/Pq96YzJ J56lXljFsENGeWIN5/xVvTc//dtw5OnDznmh8WxvjtrduWvLqlOau91Ocf3jf4vXFc/hflfN Yie3fGO1h3NUO5fSmtUnZqSrTvVWVWIpzkg01GIuKk4EABEFE9VtAgAA Archived-At: Cc: iesg@ietf.org, draft-ietf-avtext-sdes-hdr-ext.all@ietf.org, "avtext@ietf.org" , Samuel Weiler , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-avtext-sdes-hdr-ext X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 08:03:25 -0000 Den 2016-04-18 kl. 16:29, skrev Ben Campbell: > On 18 Apr 2016, at 4:33, Magnus Westerlund wrote: > >> Hi Samuel, >> >> (CC the WG) >> >> Thanks for the review. >> >> Den 2016-04-17 kl. 13:45, skrev Samuel Weiler: >>> 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 am mostly satisfied with this document's security analysis. I am >>> worried that implementors will weasel their way around the "SHOULD"s, >>> but the appropriate "SHOULD"s are in the doc. >>> >>> The doc says "...there SHOULD be strong integrity protection and source >>> authentication of the header extensions" -- I would like to also see >>> specific citation(s). (e.g. "Use X for integrity protection." "Use X >>> for authenticity.") >> >> So I will claim that the common problem that exists with minor RTP >> extension and RTP payload formats (see RFC 7202) do apply here, we >> should at least reference RFC 7201 for the options in the security >> consideration section. >> >> I will edit our source and likely push out such a change quite soon so >> that it is in place in good time before the IESG call. Unless our AD >> objects. >> >> I propose to add the below to end of the last paragraph. >> >> "For information regarding options for securing RTP, see [RFC7201]." >> >> And add RFC7201 as an informative reference. > > The AD does not object. I think it makes sense to treat this similarly > to how we treat payload drafts. > > >> >>> >>> It would be nice to see some discussion of whether these headers >>> increase the utility of RTP as a DOS vector - either by enabling a >>> reflector attack or by triggering heavy computation on a receiving >>> host. I suspect that there's not much to see here, particularly if >>> there really is integrity protection, but it would be nice to see the >>> analysis. >> >> Yes, this is a reasonable thing to consider. I suggest that we add the >> below paragraph before the last paragraph in the Security Consideration. >> >> The general RTP header extension mechanism does not itself contain any >> functionality that is a significant risk for a denial of service >> attack, nor from processing or storage requirements. This specific >> extension for SDES items, could potentially be a risk. > > Do you mean that _this_ extension might be a risk, or that any specific > SDES item might be a risk? The sentence sounds like it means the former, > but the rest of the paragraph suggests the latter. So the SDES item header extension in its basic mechanism does not appear to be a risk. However, the semantics of the SDES item itself may be a cause for concerns. It is really the next sentence below that attempts to clarify from where this risk comes. I will try to wordsmith this with help of my co-authors. > >> If the received SDES item and its content causes the receiver to >> perform larger amount of processing, create significant storage >> structures, or emit more network traffic such a risk do exist. The >> CNAME SDES item is only a minor risk as reception of a CNAME item will >> create an association between the stream carrying the SDES item and >> other RTP streams with the same SDES item. As this can result in time >> synchronizing the media streams some additional processing may result. >> However, the applications media quality appear will be likely more >> affected of the wrongly or changing association, than from the impact >> caused by the additional processing. >> Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed Apr 20 01:38:36 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EAB212E1FD for ; Wed, 20 Apr 2016 01:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDLt5rIoRrNC for ; Wed, 20 Apr 2016 01:38:28 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 414A912E2A0 for ; Wed, 20 Apr 2016 01:38:27 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id j11so36452260lfb.1 for ; Wed, 20 Apr 2016 01:38:27 -0700 (PDT) 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; bh=sefB4Dfkrc7maQF7jWL6LxzCcIsYFaycnPS/TLRc2cU=; b=cukBdlSmAiJMJxbvPzcUZJ3+YDsn3FtDSekGQpEIXLOC8UzlMMiKYnK5904436d28n 0RXc/PQc4fmhLPhNHtRf/r0KiECTeWUQUL0TiRIuraNTHFDYfHRHfBDAJJw2E6strGjY +755aSbn5H+ubIY99nC0XmQp2/c01/01PJTiiK81lTeAGql15v30o5i15yWvDAf2APjn OHdhXqDDjVMjHmxkPjFjCaW/51he3gGFTN58mnPwSm7yhqblToLFOSw36KytSXRvirx3 IVFblwHPI9wZdn4fFyPrBCFr6WYfGtyPQb6KEvwWJw8kMObw8bBy8GScCb3kYUqwhJpI Nf2g== 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; bh=sefB4Dfkrc7maQF7jWL6LxzCcIsYFaycnPS/TLRc2cU=; b=MonFH9ETa8maVzKBJfkNtvvnPkRQJ+oQBhPT1vi2cGXcJrn48Cc1oHddr8zEzx2/ZO jkFAER0VRk8VgRNn7Eo+XmjZLTnRgMs4+Hvc0eluwEBt6SwdGP8nfFqM3GCAz8JeKvFl qvcu3CWYdMHweK8esVDvBZnvzTcXGoz6BMlk7ARcgtCnP6IdsS8XXRZAWycPOmBNxSVh zOVWz0gRGYMBWxbemiSfMlOJIerLT08nCCedcoXAHwbuf4PWheNX4iNtRWTqkFGXQ23V a37DIhwJbXPCW8T3MimUIqnQLQrzi8y5ouOnF/j/03WbxV+qk6OntZMrdCB/c5/eUxk1 Y6Vg== X-Gm-Message-State: AOPr4FXxWqrM8Qjbn+3uX+JjwE0Yi3I0sZ9G7DE1NVHfaTJGplx8ixhzmR/hAcKV0jfgCRMV1xjNGk+BjmU/cSrr MIME-Version: 1.0 X-Received: by 10.25.85.210 with SMTP id j201mr2690888lfb.132.1461141505224; Wed, 20 Apr 2016 01:38:25 -0700 (PDT) Received: by 10.112.60.74 with HTTP; Wed, 20 Apr 2016 01:38:24 -0700 (PDT) In-Reply-To: References: Date: Wed, 20 Apr 2016 10:38:24 +0200 Message-ID: From: Zoltan Szabadka To: "Xialiang (Frank)" Content-Type: multipart/alternative; boundary=001a1141d826631cc70530e68448 Archived-At: Cc: "draft-alakuijala-brotli.all@tools.ietf.org" , aamelnikov@fastmail.fm, "secdir@ietf.org" , "iesg@ietf.org" , Nevil Brownlee , barryleiba@computer.org Subject: Re: [secdir] secdir review of draft-alakuijala-brotli-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 08:38:30 -0000 --001a1141d826631cc70530e68448 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you for reviewing the brotli internet draft. We published a new version of the document ( https://www.ietf.org/id/draft-alakuijala-brotli-09.txt) that addresses your comments on the "Security Considerations" section. This version also has a short paragraph about the CRIME attack. We have not yet considered using brotli for IP compression. If my understanding is correct, it is not necessary to modify this document if we want to use brotli for IPComp later. According to the IANA considerations section of rfc 2407: "Requests for assignments of new IPCOMP transform identifiers must be accompanied by an RFC which describes how to use the algorithm within the IPCOMP framework". This suggests that we would have to write a separate rfc for this purpose with an IANA considerations section that updates the "IPSEC IPCOMP Transform Identifiers" registry. Thanks, Zoltan On Mon, Apr 11, 2016 at 7:47 AM, Xialiang (Frank) 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 are= a > directors. Document editors and WG chairs should treat these comments ju= st > like any other last call comments. > > > > > > This document defines a lossless compressed data format that compresses > data using a combination of the LZ77 algorithm and Huffman coding, with > efficiency comparable to the best currently available general-purpose > compression methods. > > > > > > The document appears in reasonably good shape. > > > > In general, this document specify a new compressed data format which is > used in the end points of a connection, which is not directly subject to > network security issues. In other words, the compressed contents can be > protected by all the existing security technologies (i.e., encryption, > authentication/authorization, anti-attack, etc) if necessary. The main > security concern is about how the bad (or faked) compressed data will > attack the end system, such as: buffer overflow and resource consumption! > Some of the concerns are covered in the =E2=80=9CSecurity Considerations= =E2=80=9D section. > > > > But there are still several security issues (TBDs) missing in the documen= t > that need to be addressed before publication. > > > > > > Below is a series of my comments, questions for your consideration. > > > > > > Discussion: Section 2 > > Right now, your compressed data format is mainly used for the http (see i= n > the IANA section). Have you considered whether it can also be applied to = IP > compression? > > > > > > > > Comments: Section 11 > > In the security considerations section, there are still some serious > security issues not mentioned: > > 1. Resource consumption to the system containing a decompressor > implementation: decompressing the invalid compressed data can make the > decompressor system=E2=80=99s resource (cpu, memory, storage) to be consu= med > greatly, how to protect against this possible attack? > > 2. Resource consumption or buffer overflow to the system containing a > compressor implementation: correspondingly, when a network proxy get some > contents and need to compress them using this format, how to protect > against the possible attacks when compressing the invalid (or faked) > contents? > > > > > > > > Thank you. > > > > B.R. > > Frank > > > --001a1141d826631cc70530e68448 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you for reviewing the brotli internet draft.
We published a new version of the document (https://www.ietf.org/id/dra= ft-alakuijala-brotli-09.txt) that addresses your comments on the "= Security Considerations" section. This version also has a short paragr= aph about the CRIME attack.

We have not yet consid= ered using brotli for IP compression. If my understanding is correct, it is= not necessary to modify this document if we want to use brotli for IPComp = later. According to the IANA considerations section of rfc 2407:=C2=A0"= ;Requests for assignments of new IPCOMP transform identifiers must be accom= panied by an RFC which describes how to use the algorithm within the IPCOMP= framework". This suggests that we would have to write a separate rfc = for this purpose with an IANA considerations section that updates the "= ;IPSEC IPCOMP Transform Identifiers" registry.

Thanks,
Zoltan

On Mon, Apr 11, 2016 at 7:47 AM, Xialiang (Frank) = <frank.xialiang@huawei.com> wrote:

Hello,

=C2=A0

=C2=A0

I have reviewed this document as part of the securi= ty directorate's ongoing effort to review all IETF documents being proc= essed by the IESG.=C2=A0 These comments were written primarily for the bene= fit of the security area directors.=C2=A0 Document editors and WG chairs should treat these comment= s just like any other last call comments.

=C2=A0

=C2=A0

This document defines a lossless compressed data fo= rmat that compresses data using a combination of the LZ77 algorithm and Huf= fman coding, with efficiency comparable to the best currently available gen= eral-purpose compression methods.

=C2=A0

=C2=A0

The document appears in reasonably good shape.

=C2=A0

In general, this document specify a new compressed = data format which is used in the end points of a connection, which is not d= irectly subject to network security issues. In other words, the compressed = contents can be protected by all the existing security technologies (i.e., encryption, = authentication/authorization, anti-attack, etc) if necessary. The main secu= rity concern is about how the bad (or faked) compressed data will attack th= e end system, such as: buffer overflow and resource consumption! Some of the concerns are covered in the <= span lang=3D"EN-US" style=3D"font-family:"Courier New"">=E2=80=9C= Security Considerations=E2=80=9D section.

=C2=A0

But there are still several security issues (TBDs) = missing in the document that need to be addressed before publication.

=C2=A0

=C2=A0

Below is a series of my comments, questions for you= r consideration.

=C2=A0

=C2=A0

Discussion: Section 2

Right now, your compressed data format is mainly us= ed for the http (see in the IANA section). Have you considered whether it c= an also be applied to IP compression?

=C2=A0

=C2=A0

=C2=A0

Comments: Section 11

In the security considerations section, there are s= till some serious security issues not mentioned:

1. Resource consumption to the system containing a = decompressor implementation: decompressing the invalid compressed data can = make the decompressor system=E2=80=99s resource (cpu, memory, storage) to be consumed greatly, how to protect aga= inst this possible attack?

2. Resource consumption or buffer overflow to the s= ystem containing a compressor implementation: correspondingly, when a netwo= rk proxy get some contents and need to compress them using this format, how= to protect against the possible attacks when compressing the invalid (or faked) contents?<= /u>

=C2=A0

=C2=A0

=C2=A0

Thank you.

=C2=A0

B.R.=

Frank

=C2=A0


--001a1141d826631cc70530e68448-- From nobody Wed Apr 20 19:06:41 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AED0A12DB2D; Wed, 20 Apr 2016 19:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LahTsBZQNclT; Wed, 20 Apr 2016 19:06:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33E5912D9AA; Wed, 20 Apr 2016 19:06:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMV02210; Thu, 21 Apr 2016 02:06:32 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 21 Apr 2016 03:06:31 +0100 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.36]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0235.001; Thu, 21 Apr 2016 10:06:27 +0800 From: "Xialiang (Frank)" To: Zoltan Szabadka Thread-Topic: secdir review of draft-alakuijala-brotli-08 Thread-Index: AdGTthpEGuVvRaAtQJGDUJWf2eunBwG5tf0AADUIi8A= Date: Thu, 21 Apr 2016 02:06:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.43.91] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12AF2D953SZXEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.571835A8.0040, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.36, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ebc4f838632ed2123348c1a0477f6271 Archived-At: Cc: "draft-alakuijala-brotli.all@tools.ietf.org" , "aamelnikov@fastmail.fm" , "secdir@ietf.org" , "iesg@ietf.org" , Nevil Brownlee , "barryleiba@computer.org" Subject: [secdir] =?utf-8?b?562U5aSNOiBzZWNkaXIgcmV2aWV3IG9mIGRyYWZ0LWFs?= =?utf-8?q?akuijala-brotli-08?= X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 02:06:41 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F12AF2D953SZXEMA502MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgWm9sdGFuLA0KUGxlYXNlIHNlZSBpbmxpbmU6DQoNCuWPkeS7tuS6ujogWm9sdGFuIFN6YWJh ZGthIFttYWlsdG86c3phYmFka2FAZ29vZ2xlLmNvbV0NCuWPkemAgeaXtumXtDogMjAxNuW5tDTm nIgyMOaXpSAxNjozOA0K5pS25Lu25Lq6OiBYaWFsaWFuZyAoRnJhbmspDQrmioTpgIE6IGllc2dA aWV0Zi5vcmc7IHNlY2RpckBpZXRmLm9yZzsgZHJhZnQtYWxha3VpamFsYS1icm90bGkuYWxsQHRv b2xzLmlldGYub3JnOyBka2dAZmlmdGhob3JzZW1hbi5uZXQ7IE5ldmlsIEJyb3dubGVlOyBhYW1l bG5pa292QGZhc3RtYWlsLmZtOyBiYXJyeWxlaWJhQGNvbXB1dGVyLm9yZw0K5Li76aKYOiBSZTog c2VjZGlyIHJldmlldyBvZiBkcmFmdC1hbGFrdWlqYWxhLWJyb3RsaS0wOA0KDQpUaGFuayB5b3Ug Zm9yIHJldmlld2luZyB0aGUgYnJvdGxpIGludGVybmV0IGRyYWZ0Lg0KDQpXZSBwdWJsaXNoZWQg YSBuZXcgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQgKGh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2Ry YWZ0LWFsYWt1aWphbGEtYnJvdGxpLTA5LnR4dCkgdGhhdCBhZGRyZXNzZXMgeW91ciBjb21tZW50 cyBvbiB0aGUgIlNlY3VyaXR5IENvbnNpZGVyYXRpb25zIiBzZWN0aW9uLiBUaGlzIHZlcnNpb24g YWxzbyBoYXMgYSBzaG9ydCBwYXJhZ3JhcGggYWJvdXQgdGhlIENSSU1FIGF0dGFjay4NCltGcmFu a106IFlvdXIgaW1wcm92ZW1lbnQgaGFzIGFkZHJlc3NlZCBteSBpc3N1ZXMsIHRoYW5rIHlvdS4N Cg0KV2UgaGF2ZSBub3QgeWV0IGNvbnNpZGVyZWQgdXNpbmcgYnJvdGxpIGZvciBJUCBjb21wcmVz c2lvbi4gSWYgbXkgdW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0LCBpdCBpcyBub3QgbmVjZXNzYXJ5 IHRvIG1vZGlmeSB0aGlzIGRvY3VtZW50IGlmIHdlIHdhbnQgdG8gdXNlIGJyb3RsaSBmb3IgSVBD b21wIGxhdGVyLiBBY2NvcmRpbmcgdG8gdGhlIElBTkEgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBv ZiByZmMgMjQwNzogIlJlcXVlc3RzIGZvciBhc3NpZ25tZW50cyBvZiBuZXcgSVBDT01QIHRyYW5z Zm9ybSBpZGVudGlmaWVycyBtdXN0IGJlIGFjY29tcGFuaWVkIGJ5IGFuIFJGQyB3aGljaCBkZXNj cmliZXMgaG93IHRvIHVzZSB0aGUgYWxnb3JpdGhtIHdpdGhpbiB0aGUgSVBDT01QIGZyYW1ld29y ayIuIFRoaXMgc3VnZ2VzdHMgdGhhdCB3ZSB3b3VsZCBoYXZlIHRvIHdyaXRlIGEgc2VwYXJhdGUg cmZjIGZvciB0aGlzIHB1cnBvc2Ugd2l0aCBhbiBJQU5BIGNvbnNpZGVyYXRpb25zIHNlY3Rpb24g dGhhdCB1cGRhdGVzIHRoZSAiSVBTRUMgSVBDT01QIFRyYW5zZm9ybSBJZGVudGlmaWVycyIgcmVn aXN0cnkuDQpbRnJhbmtdOiBTbywgd2hhdOKAmXMgeW91ciBpZGVhPw0KDQpCLlIuDQpGcmFuaw0K DQpUaGFua3MsDQpab2x0YW4NCg0KT24gTW9uLCBBcHIgMTEsIDIwMTYgYXQgNzo0NyBBTSwgWGlh bGlhbmcgKEZyYW5rKSA8ZnJhbmsueGlhbGlhbmdAaHVhd2VpLmNvbTxtYWlsdG86ZnJhbmsueGlh bGlhbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KDQpIZWxsbywNCg0KDQoNCg0KDQpJIGhhdmUgcmV2 aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdz IG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vz c2VkIGJ5IHRoZSBJRVNHLiAgVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBm b3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiAgRG9jdW1lbnQg ZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxp a2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCg0KDQoNCg0KDQpUaGlzIGRvY3VtZW50 IGRlZmluZXMgYSBsb3NzbGVzcyBjb21wcmVzc2VkIGRhdGEgZm9ybWF0IHRoYXQgY29tcHJlc3Nl cyBkYXRhIHVzaW5nIGEgY29tYmluYXRpb24gb2YgdGhlIExaNzcgYWxnb3JpdGhtIGFuZCBIdWZm bWFuIGNvZGluZywgd2l0aCBlZmZpY2llbmN5IGNvbXBhcmFibGUgdG8gdGhlIGJlc3QgY3VycmVu dGx5IGF2YWlsYWJsZSBnZW5lcmFsLXB1cnBvc2UgY29tcHJlc3Npb24gbWV0aG9kcy4NCg0KDQoN Cg0KDQpUaGUgZG9jdW1lbnQgYXBwZWFycyBpbiByZWFzb25hYmx5IGdvb2Qgc2hhcGUuDQoNCg0K DQpJbiBnZW5lcmFsLCB0aGlzIGRvY3VtZW50IHNwZWNpZnkgYSBuZXcgY29tcHJlc3NlZCBkYXRh IGZvcm1hdCB3aGljaCBpcyB1c2VkIGluIHRoZSBlbmQgcG9pbnRzIG9mIGEgY29ubmVjdGlvbiwg d2hpY2ggaXMgbm90IGRpcmVjdGx5IHN1YmplY3QgdG8gbmV0d29yayBzZWN1cml0eSBpc3N1ZXMu IEluIG90aGVyIHdvcmRzLCB0aGUgY29tcHJlc3NlZCBjb250ZW50cyBjYW4gYmUgcHJvdGVjdGVk IGJ5IGFsbCB0aGUgZXhpc3Rpbmcgc2VjdXJpdHkgdGVjaG5vbG9naWVzIChpLmUuLCBlbmNyeXB0 aW9uLCBhdXRoZW50aWNhdGlvbi9hdXRob3JpemF0aW9uLCBhbnRpLWF0dGFjaywgZXRjKSBpZiBu ZWNlc3NhcnkuIFRoZSBtYWluIHNlY3VyaXR5IGNvbmNlcm4gaXMgYWJvdXQgaG93IHRoZSBiYWQg KG9yIGZha2VkKSBjb21wcmVzc2VkIGRhdGEgd2lsbCBhdHRhY2sgdGhlIGVuZCBzeXN0ZW0sIHN1 Y2ggYXM6IGJ1ZmZlciBvdmVyZmxvdyBhbmQgcmVzb3VyY2UgY29uc3VtcHRpb24hIFNvbWUgb2Yg dGhlIGNvbmNlcm5zIGFyZSBjb3ZlcmVkIGluIHRoZSDigJxTZWN1cml0eSBDb25zaWRlcmF0aW9u c+KAnSBzZWN0aW9uLg0KDQoNCg0KQnV0IHRoZXJlIGFyZSBzdGlsbCBzZXZlcmFsIHNlY3VyaXR5 IGlzc3VlcyAoVEJEcykgbWlzc2luZyBpbiB0aGUgZG9jdW1lbnQgdGhhdCBuZWVkIHRvIGJlIGFk ZHJlc3NlZCBiZWZvcmUgcHVibGljYXRpb24uDQoNCg0KDQoNCg0KQmVsb3cgaXMgYSBzZXJpZXMg b2YgbXkgY29tbWVudHMsIHF1ZXN0aW9ucyBmb3IgeW91ciBjb25zaWRlcmF0aW9uLg0KDQoNCg0K DQoNCkRpc2N1c3Npb246IFNlY3Rpb24gMg0KDQpSaWdodCBub3csIHlvdXIgY29tcHJlc3NlZCBk YXRhIGZvcm1hdCBpcyBtYWlubHkgdXNlZCBmb3IgdGhlIGh0dHAgKHNlZSBpbiB0aGUgSUFOQSBz ZWN0aW9uKS4gSGF2ZSB5b3UgY29uc2lkZXJlZCB3aGV0aGVyIGl0IGNhbiBhbHNvIGJlIGFwcGxp ZWQgdG8gSVAgY29tcHJlc3Npb24/DQoNCg0KDQoNCg0KDQoNCkNvbW1lbnRzOiBTZWN0aW9uIDEx DQoNCkluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uLCB0aGVyZSBhcmUgc3Rp bGwgc29tZSBzZXJpb3VzIHNlY3VyaXR5IGlzc3VlcyBub3QgbWVudGlvbmVkOg0KDQoxLiBSZXNv dXJjZSBjb25zdW1wdGlvbiB0byB0aGUgc3lzdGVtIGNvbnRhaW5pbmcgYSBkZWNvbXByZXNzb3Ig aW1wbGVtZW50YXRpb246IGRlY29tcHJlc3NpbmcgdGhlIGludmFsaWQgY29tcHJlc3NlZCBkYXRh IGNhbiBtYWtlIHRoZSBkZWNvbXByZXNzb3Igc3lzdGVt4oCZcyByZXNvdXJjZSAoY3B1LCBtZW1v cnksIHN0b3JhZ2UpIHRvIGJlIGNvbnN1bWVkIGdyZWF0bHksIGhvdyB0byBwcm90ZWN0IGFnYWlu c3QgdGhpcyBwb3NzaWJsZSBhdHRhY2s/DQoNCjIuIFJlc291cmNlIGNvbnN1bXB0aW9uIG9yIGJ1 ZmZlciBvdmVyZmxvdyB0byB0aGUgc3lzdGVtIGNvbnRhaW5pbmcgYSBjb21wcmVzc29yIGltcGxl bWVudGF0aW9uOiBjb3JyZXNwb25kaW5nbHksIHdoZW4gYSBuZXR3b3JrIHByb3h5IGdldCBzb21l IGNvbnRlbnRzIGFuZCBuZWVkIHRvIGNvbXByZXNzIHRoZW0gdXNpbmcgdGhpcyBmb3JtYXQsIGhv dyB0byBwcm90ZWN0IGFnYWluc3QgdGhlIHBvc3NpYmxlIGF0dGFja3Mgd2hlbiBjb21wcmVzc2lu ZyB0aGUgaW52YWxpZCAob3IgZmFrZWQpIGNvbnRlbnRzPw0KDQoNCg0KDQoNCg0KDQpUaGFuayB5 b3UuDQoNCg0KDQpCLlIuDQoNCkZyYW5rDQoNCg0K --_000_C02846B1344F344EB4FAA6FA7AF481F12AF2D953SZXEMA502MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLmhvZW56Yg0K CXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+SGkgWm9sdGFuLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+UGxlYXNlIHNlZSBpbmxpbmU6PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiBab2x0 YW4gU3phYmFka2EgW21haWx0bzpzemFiYWRrYUBnb29nbGUuY29tXQ0KPGJyPg0KPC9zcGFuPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lj5HpgIHml7bpl7Q8c3BhbiBsYW5nPSJF Ti1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+IDIwMTY8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuW5 tDxzcGFuIGxhbmc9IkVOLVVTIj40PC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj4yMDwvc3Bh bj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+IDE2OjM4PGJyPg0KPC9zcGFuPjxiPuaUtuS7tuS6ujxz cGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFhpYWxpYW5n IChGcmFuayk8YnI+DQo8L3NwYW4+PGI+5oqE6YCBPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gaWVzZ0BpZXRmLm9yZzsgc2VjZGlyQGlldGYub3JnOyBk cmFmdC1hbGFrdWlqYWxhLWJyb3RsaS5hbGxAdG9vbHMuaWV0Zi5vcmc7IGRrZ0BmaWZ0aGhvcnNl bWFuLm5ldDsgTmV2aWwgQnJvd25sZWU7IGFhbWVsbmlrb3ZAZmFzdG1haWwuZm07IGJhcnJ5bGVp YmFAY29tcHV0ZXIub3JnPGJyPg0KPC9zcGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFJlOiBzZWNkaXIgcmV2aWV3IG9mIGRyYWZ0 LWFsYWt1aWphbGEtYnJvdGxpLTA4PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+VGhhbmsgeW91IGZvciByZXZpZXdpbmcgdGhlIGJyb3RsaSBpbnRlcm5ldCBkcmFmdC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5XZSBwdWJsaXNoZWQgYSBu ZXcgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQgKDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L2lkL2RyYWZ0LWFsYWt1aWphbGEtYnJvdGxpLTA5LnR4dCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv aWQvZHJhZnQtYWxha3VpamFsYS1icm90bGktMDkudHh0PC9hPikgdGhhdCBhZGRyZXNzZXMgeW91 ciBjb21tZW50cyBvbiB0aGUgJnF1b3Q7U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMmcXVvdDsNCiBz ZWN0aW9uLiBUaGlzIHZlcnNpb24gYWxzbyBoYXMgYSBzaG9ydCBwYXJhZ3JhcGggYWJvdXQgdGhl IENSSU1FIGF0dGFjay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PltGcmFua106IFlvdXIgaW1wcm92ZW1lbnQgaGFzIGFkZHJlc3NlZCBteSBpc3N1ZXMsIHRoYW5r IHlvdS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPldl IGhhdmUgbm90IHlldCBjb25zaWRlcmVkIHVzaW5nIGJyb3RsaSBmb3IgSVAgY29tcHJlc3Npb24u IElmIG15IHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdCwgaXQgaXMgbm90IG5lY2Vzc2FyeSB0byBt b2RpZnkgdGhpcyBkb2N1bWVudCBpZiB3ZSB3YW50IHRvIHVzZSBicm90bGkgZm9yIElQQ29tcCBs YXRlci4gQWNjb3JkaW5nIHRvIHRoZSBJQU5BIGNvbnNpZGVyYXRpb25zIHNlY3Rpb24NCiBvZiBy ZmMgMjQwNzombmJzcDsmcXVvdDtSZXF1ZXN0cyBmb3IgYXNzaWdubWVudHMgb2YgbmV3IElQQ09N UCB0cmFuc2Zvcm0gaWRlbnRpZmllcnMgbXVzdCBiZSBhY2NvbXBhbmllZCBieSBhbiBSRkMgd2hp Y2ggZGVzY3JpYmVzIGhvdyB0byB1c2UgdGhlIGFsZ29yaXRobSB3aXRoaW4gdGhlIElQQ09NUCBm cmFtZXdvcmsmcXVvdDsuIFRoaXMgc3VnZ2VzdHMgdGhhdCB3ZSB3b3VsZCBoYXZlIHRvIHdyaXRl IGEgc2VwYXJhdGUgcmZjIGZvciB0aGlzIHB1cnBvc2Ugd2l0aCBhbg0KIElBTkEgY29uc2lkZXJh dGlvbnMgc2VjdGlvbiB0aGF0IHVwZGF0ZXMgdGhlICZxdW90O0lQU0VDIElQQ09NUCBUcmFuc2Zv cm0gSWRlbnRpZmllcnMmcXVvdDsgcmVnaXN0cnkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bRnJhbmtdOiBTbywgd2hhdOKAmXMgeW91 ciBpZGVhPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CLlIuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5GcmFuazxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRo YW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Wm9sdGFuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBNb24sIEFwciAxMSwgMjAxNiBhdCA3OjQ3IEFN LCBYaWFsaWFuZyAoRnJhbmspICZsdDs8YSBocmVmPSJtYWlsdG86ZnJhbmsueGlhbGlhbmdAaHVh d2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmZyYW5rLnhpYWxpYW5nQGh1YXdlaS5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIGxh bmc9IkVOLVVTIj5IZWxsbyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGhh dmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3Rv cmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcg cHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiZuYnNwOyBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4g cHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMu Jm5ic3A7IERvY3VtZW50DQogZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVz ZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGlzIGRvY3VtZW50IGRlZmluZXMgYSBsb3Nz bGVzcyBjb21wcmVzc2VkIGRhdGEgZm9ybWF0IHRoYXQgY29tcHJlc3NlcyBkYXRhIHVzaW5nIGEg Y29tYmluYXRpb24gb2YgdGhlIExaNzcgYWxnb3JpdGhtIGFuZCBIdWZmbWFuIGNvZGluZywgd2l0 aCBlZmZpY2llbmN5IGNvbXBhcmFibGUgdG8gdGhlIGJlc3QgY3VycmVudGx5IGF2YWlsYWJsZSBn ZW5lcmFsLXB1cnBvc2UgY29tcHJlc3Npb24gbWV0aG9kcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFu IGxhbmc9IkVOLVVTIj5UaGUgZG9jdW1lbnQgYXBwZWFycyBpbiByZWFzb25hYmx5IGdvb2Qgc2hh cGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5JbiBnZW5lcmFsLCB0 aGlzIGRvY3VtZW50IHNwZWNpZnkgYSBuZXcgY29tcHJlc3NlZCBkYXRhIGZvcm1hdCB3aGljaCBp cyB1c2VkIGluIHRoZSBlbmQgcG9pbnRzIG9mIGEgY29ubmVjdGlvbiwgd2hpY2ggaXMgbm90IGRp cmVjdGx5IHN1YmplY3QgdG8gbmV0d29yayBzZWN1cml0eSBpc3N1ZXMuIEluIG90aGVyIHdvcmRz LCB0aGUgY29tcHJlc3NlZCBjb250ZW50cyBjYW4gYmUgcHJvdGVjdGVkIGJ5IGFsbCB0aGUNCiBl eGlzdGluZyBzZWN1cml0eSB0ZWNobm9sb2dpZXMgKGkuZS4sIGVuY3J5cHRpb24sIGF1dGhlbnRp Y2F0aW9uL2F1dGhvcml6YXRpb24sIGFudGktYXR0YWNrLCBldGMpIGlmIG5lY2Vzc2FyeS4gVGhl IG1haW4gc2VjdXJpdHkgY29uY2VybiBpcyBhYm91dCBob3cgdGhlIGJhZCAob3IgZmFrZWQpIGNv bXByZXNzZWQgZGF0YSB3aWxsIGF0dGFjayB0aGUgZW5kIHN5c3RlbSwgc3VjaCBhczogYnVmZmVy IG92ZXJmbG93IGFuZCByZXNvdXJjZSBjb25zdW1wdGlvbiENCiBTb21lIG9mIHRoZSBjb25jZXJu cyBhcmUgY292ZXJlZCBpbiB0aGUgPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPuKAnDwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+4oCdPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj4gc2VjdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0i RU4tVVMiPkJ1dCB0aGVyZSBhcmUgc3RpbGwgc2V2ZXJhbCBzZWN1cml0eSBpc3N1ZXMgKFRCRHMp IG1pc3NpbmcgaW4gdGhlIGRvY3VtZW50IHRoYXQgbmVlZCB0byBiZSBhZGRyZXNzZWQgYmVmb3Jl IHB1YmxpY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPkJlbG93IGlz IGEgc2VyaWVzIG9mIG15IGNvbW1lbnRzLCBxdWVzdGlvbnMgZm9yIHlvdXIgY29uc2lkZXJhdGlv bi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5EaXNjdXNzaW9uOiBTZWN0aW9u IDI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+UmlnaHQgbm93 LCB5b3VyIGNvbXByZXNzZWQgZGF0YSBmb3JtYXQgaXMgbWFpbmx5IHVzZWQgZm9yIHRoZSBodHRw IChzZWUgaW4gdGhlIElBTkEgc2VjdGlvbikuIEhhdmUgeW91IGNvbnNpZGVyZWQgd2hldGhlciBp dCBjYW4gYWxzbyBiZSBhcHBsaWVkIHRvIElQIGNvbXByZXNzaW9uPzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFu IGxhbmc9IkVOLVVTIj5Db21tZW50czogU2VjdGlvbiAxMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5JbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2Vj dGlvbiwgdGhlcmUgYXJlIHN0aWxsIHNvbWUgc2VyaW91cyBzZWN1cml0eSBpc3N1ZXMgbm90IG1l bnRpb25lZDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+MS4g UmVzb3VyY2UgY29uc3VtcHRpb24gdG8gdGhlIHN5c3RlbSBjb250YWluaW5nIGEgZGVjb21wcmVz c29yIGltcGxlbWVudGF0aW9uOiBkZWNvbXByZXNzaW5nIHRoZSBpbnZhbGlkIGNvbXByZXNzZWQg ZGF0YSBjYW4gbWFrZSB0aGUgZGVjb21wcmVzc29yIHN5c3RlbTwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij7igJk8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPnMNCiByZXNvdXJjZSAoY3B1LCBtZW1vcnksIHN0b3JhZ2Up IHRvIGJlIGNvbnN1bWVkIGdyZWF0bHksIGhvdyB0byBwcm90ZWN0IGFnYWluc3QgdGhpcyBwb3Nz aWJsZSBhdHRhY2s/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMi PjIuIFJlc291cmNlIGNvbnN1bXB0aW9uIG9yIGJ1ZmZlciBvdmVyZmxvdyB0byB0aGUgc3lzdGVt IGNvbnRhaW5pbmcgYSBjb21wcmVzc29yIGltcGxlbWVudGF0aW9uOiBjb3JyZXNwb25kaW5nbHks IHdoZW4gYSBuZXR3b3JrIHByb3h5IGdldCBzb21lIGNvbnRlbnRzIGFuZCBuZWVkIHRvIGNvbXBy ZXNzIHRoZW0gdXNpbmcgdGhpcyBmb3JtYXQsIGhvdyB0byBwcm90ZWN0IGFnYWluc3QgdGhlIHBv c3NpYmxlIGF0dGFja3MNCiB3aGVuIGNvbXByZXNzaW5nIHRoZSBpbnZhbGlkIChvciBmYWtlZCkg Y29udGVudHM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rIHlvdS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPkIuUi48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiM4ODg4ODgiPkZyYW5rPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImNvbG9yOiM4ODg4ODgiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_C02846B1344F344EB4FAA6FA7AF481F12AF2D953SZXEMA502MBSchi_-- From nobody Thu Apr 21 03:20:07 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82EA212E3C7 for ; Thu, 21 Apr 2016 03:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0A37xO_UGra for ; Thu, 21 Apr 2016 03:20:03 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E55E812E232 for ; Thu, 21 Apr 2016 03:20:00 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u3LAJuU9024178 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 21 Apr 2016 13:19:56 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u3LAJu32002733; Thu, 21 Apr 2016 13:19:56 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22296.43340.467558.804631@fireball.acr.fi> Date: Thu, 21 Apr 2016 13:19:56 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignment X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 10:20:05 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Sandy Murphy is next in the rotation. For telechat 2016-04-21 Reviewer LC end Draft Shaun Cooley T 2016-03-29 draft-ietf-pce-iro-update-06 Donald Eastlake TR2016-02-22 draft-ietf-dane-openpgpkey-09 Steve Hanna T 2016-04-11 draft-ietf-pim-hierarchicaljoinattr-07 Jeffrey Hutzelman T 2015-12-04 draft-ietf-core-block-19 Leif Johansson T 2016-04-06 draft-ietf-p2psip-sip-19 Joe Salowey T 2016-03-09 draft-ietf-rtcweb-audio-codecs-for-interop-05 Carl Wallace T 2016-03-30 draft-schoenw-opsawg-copspr-historic-04 For telechat 2016-05-05 Donald Eastlake T 2016-04-13 draft-ietf-bess-multicast-damping-04 Shawn Emery T 2016-04-12 draft-ietf-bfd-seamless-base-09 Daniel Kahn Gillmor T 2016-04-12 draft-ietf-bfd-seamless-ip-04 Phillip Hallam-Baker T 2016-04-05 draft-ietf-pals-seamless-vccv-02 Christian Huitema T 2016-04-13 draft-ietf-bess-pta-flags-02 Chris Inacio T 2016-04-26 draft-ietf-ospf-sbfd-discriminator-04 Benjamin Kaduk T 2016-04-21 draft-ietf-rtcweb-alpn-03 Scott Kelly T 2016-04-29 draft-ietf-i2rs-pub-sub-requirements-06 Watson Ladd T 2016-04-29 draft-ietf-i2rs-traceability-08 Ben Laurie T 2016-04-29 draft-ietf-idr-add-paths-13 Chris Lonvick T 2016-04-29 draft-ietf-idr-route-oscillation-stop-02 Catherine Meadows T 2016-04-29 draft-ietf-isis-node-admin-tag-08 Matthew Miller T 2015-02-13 draft-ietf-sidr-as-migration-05 Eric Osterweil T 2016-01-05 draft-campbell-art-rfc5727-update-03 Yaron Sheffer T 2016-03-09 draft-ietf-v6ops-host-addr-availability-06 Tom Yu T 2016-03-24 draft-ietf-dime-drmp-05 Dacheng Zhang T 2016-03-28 draft-ietf-grow-route-leak-problem-definition-04 Last calls and special requests: Alan DeKok 2016-04-30 draft-bradner-rfc3979bis-08 Daniel Kahn Gillmor E 2016-02-01 draft-ietf-rtcweb-security-08 Tero Kivinen 2016-05-04 draft-ietf-aqm-eval-guidelines-11 Warren Kumari 2016-05-04 draft-ietf-aqm-pie-06 Adam Montville 2016-05-13 draft-sheffer-rfc6982bis-00 Hannes Tschofenig 2015-12-28 draft-ietf-hip-rfc5204-bis-07 Hannes Tschofenig E None draft-ietf-ntp-network-time-security-13 Hannes Tschofenig E None draft-ietf-ntp-cms-for-nts-message-06 Hannes Tschofenig E None draft-ietf-ntp-using-nts-for-ntp-04 Brian Weis E 2016-02-01 draft-ietf-cdni-uri-signing-07 Tom Yu R2016-04-25 draft-ietf-netconf-yang-library-05 -- kivinen@iki.fi From nobody Thu Apr 21 10:37:06 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7EF12E89C; Thu, 21 Apr 2016 10:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tfop32BSYCFt; Thu, 21 Apr 2016 10:37:00 -0700 (PDT) Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [IPv6:2001:480:20:118:118::211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5D2712E887; Thu, 21 Apr 2016 10:36:59 -0700 (PDT) Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id u3LHatCj020776 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 21 Apr 2016 13:36:56 -0400 From: Catherine Meadows Content-Type: multipart/alternative; boundary="Apple-Mail=_39C57C84-51C0-4DC2-821E-6ACD43419855" Date: Thu, 21 Apr 2016 13:36:55 -0400 Message-Id: To: secdir@ietf.org, iesg@ietf.org, draft-ietf-isis-node-admin-tag.all@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email Archived-At: Subject: [secdir] sectdir review of draft-ietf-isis-node-admin-tag-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 17:37:02 -0000 --Apple-Mail=_39C57C84-51C0-4DC2-821E-6ACD43419855 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have reviewed this document as part of the security directorate's = ongoing effort to review all=20 IETF documents being processed by the IESG. These comments were written = primarily for the=20 benefit of the security area directors. Document editors and WG chairs = should treat these comments=20 just like any other last call comments. This draft describes an extension to the IS-IS routing protocol, that = allows tagging and grouping of nodes in an IS-IS domain. This makes it possible to increase the efficiency = of route and path selection, since the tags give information about a router=E2=80=99s capabilities. The Security Considerations section correctly identifies one of the main = security risks of using such tags: they may leak sensitive information about, e.g., geographical location. However, = I=E2=80=99m confused by the statement following that: =E2=80=9CThis document does not introduce any new security concerns. = Security concerns for IS-IS are already addressed in [ISO10589], [RFC5304], and [RFC5310] are are applicable to the = mechanisms described in this document.=E2=80=9D As far as I can tell, this document *does* introduce new security = concerns, because the tags may reveal sensitive information that may not have been made available otherwise. Moreover, = RFCs 5304 and 5310 concern authentication, not secrecy, and so do not address information leakage at all. My own = suggestion for a recommendation would be that implementors should weigh the = benefits of putting certain kinds of information on tags versus the risk of its being used by an attacker, and make their = decisions accordingly. This would not be a SHOULD a MUST recommendation by the way, but simply advisory. I=E2=80=99m not sure what is meant by the last sentence in this = paragraph: Extended authentication mechanisms described in [RFC5304] or [RFC5310] = SHOULD be used in deployments where attackers have access to the physical networks and nodes included in the IS-IS domain are vulnerable. Is this addressing the problem of sensitive information on tags? If so, = you need to say how. If it is addressing spoofing of tags, it should be given its own paragraph, and the threat = you are talking about should be made clear. In the last paragraph, on the misattribution of tags from different = domains, what would you recommend for mitigating against this problem? Also, since this is in the security considerations = section, you should say something about how an attacker could take advantage of it. =20 In my opinion, the Security Considerations section needs a major = revision. However, I consider this document Almost Ready, because the purpose of the = revision would be mainly to make the section more clear, not to address any overlooked security problems. Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil = --Apple-Mail=_39C57C84-51C0-4DC2-821E-6ACD43419855 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I have reviewed this document as part of the security = directorate's ongoing effort to review all 
IETF = documents being processed by the IESG.  These comments were written = primarily for the 
benefit of the security = area directors.  Document editors and WG chairs should treat these = comments 
just like any other last call = comments.

This = draft describes an extension to the IS-IS routing protocol, that allows = tagging and grouping of nodes
in an IS-IS domain. =  This makes it possible to increase the efficiency of route and = path selection, since the tags
give information = about a router=E2=80=99s capabilities.

The Security Considerations section = correctly identifies one of the main security risks of using such tags: =  they may leak
sensitive information about, = e.g., geographical location.   However, I=E2=80=99m confused by the = statement following that:

=E2=80=9CThis document does not introduce any new security = concerns.  Security concerns for IS-IS are already addressed = in
[ISO10589], [RFC5304], and [RFC5310] are are = applicable to the mechanisms described in this document.=E2=80=9D

As far as I can tell, = this document *does* introduce new security concerns, because the tags = may reveal sensitive
information that may not have = been made available otherwise.  Moreover, RFCs 5304 and 5310 = concern authentication, not
secrecy, and so do not = address information leakage at all.  My own suggestion
for a recommendation would be that implementors should weigh = the benefits of putting certain kinds of information on tags
versus the risk of its being used by an attacker, and make = their decisions accordingly.  This would not be a SHOULD a = MUST
recommendation by the way, but simply = advisory.

I=E2=80= =99m not sure what is meant by the last sentence in this = paragraph:

 Extended authentication mechanisms described in = [RFC5304] or [RFC5310] SHOULD be used in
  =  deployments where attackers have access to the physical networks = and
   nodes included in the IS-IS domain = are vulnerable.

Is this addressing the problem of sensitive information on = tags?  If so, you need to say how.   If it is = addressing
spoofing of tags, it should be given its = own paragraph, and the threat you are talking about should be made = clear.

In the = last paragraph, on the misattribution of tags from different domains, = what would you recommend for mitigating against
this = problem?  Also, since this is in the security considerations = section, you should say something about how an attacker
could take advantage of it.  

In my opinion, the Security = Considerations section needs a major revision.  However,
I consider this document Almost Ready, because the purpose of = the revision would be mainly to make the section more clear, not to = address
any overlooked security problems.




Catherine Meadows
Naval Research = Laboratory
Code 5543
4555 Overlook Ave., = S.W.
Washington DC, 20375
phone: = 202-767-3490
fax: 202-404-7942
email: catherine.meadows@nrl.navy.mil

= --Apple-Mail=_39C57C84-51C0-4DC2-821E-6ACD43419855-- From nobody Thu Apr 21 14:23:02 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C75A612E6BC; Thu, 21 Apr 2016 14:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9l8JjiBaWra8; Thu, 21 Apr 2016 14:22:52 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECC3A12E21C; Thu, 21 Apr 2016 14:22:51 -0700 (PDT) X-AuditID: 1209190d-fefff700000076cb-de-571944aadde2 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 1F.7A.30411.AA449175; Thu, 21 Apr 2016 17:22:50 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id u3LLMne0030945; Thu, 21 Apr 2016 17:22:50 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u3LLMkIC010563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Apr 2016 17:22:49 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u3LLMknN018153; Thu, 21 Apr 2016 17:22:46 -0400 (EDT) Date: Thu, 21 Apr 2016 17:22:45 -0400 (EDT) From: Benjamin Kaduk To: iesg@ietf.org, secdir@ietf.org, draft-ietf-rtcweb-apln.all@ietf.org Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsUixCmqrLvKRTLcYNETCYsH836zWcz4M5HZ 4sPChywOzB5LlvxkCmCM4rJJSc3JLEst0rdL4Mq4OpOlYBpXxZG24+wNjAs5uhg5OSQETCR2 Hz3G1sXIxSEk0MYkcf/DCXYIZyOjRPPctSwQziEmia1LuxkhnAZGif2zJrCC9LMIaEtcXbYP zGYTUJGY+WYjG4gtIuAu8e/pKhYQW1jAWOLD17tMIDavgKPE/e5rYLaogI7E6v1TWCDighIn Zz4Bs5kFtCSWT9/GMoGRdxaS1CwkqQWMTKsYZVNyq3RzEzNzilOTdYuTE/PyUot0jfRyM0v0 UlNKNzGCQ0mSdwfjv7tehxgFOBiVeHg55CXChVgTy4orcw8xSnIwKYnyrlWUDBfiS8pPqcxI LM6ILyrNSS0+xCjBwawkwjvPCSjHm5JYWZValA+TkuZgURLnjbl5NExIID2xJDU7NbUgtQgm K8PBoSTBm+8M1ChYlJqeWpGWmVOCkGbi4AQZzgM0vBakhre4IDG3ODMdIn+KUVFKnPc9yFYB kERGaR5cLzjWdzOpvmIUB3pFmDcRpJ0HmCbgul8BDWYCGsx/VxRkcEkiQkqqgfExb5bLpDlr Nb/eiXnAFfqSM+FGzJW7Nj5qnwq+bdiQU13Jtdk7tsY5tPrcm4d6ufrK+rsTJkif+3zCovLC 6hDm7WYytpeUHvYEpZ/a8dE0ZNU0p6US3eVZ3SIP+q6Lzjnx6ZB1jf0fxnLZyeKz2xTmHbqU 5HpYL/d1xQI13aPcB37kVezx6lFiKc5INNRiLipOBACHVLE50AIAAA== Archived-At: Subject: [secdir] secdir review of draft-ietf-rtcweb-alpn-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 21:22:58 -0000 Hi all, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I think this document is ready. The main goal is to provide an authenticated indicator to the webrtc peers that confidentiality is needed for the "media" (video, audio) streams of that webrtc session (or that it is not needed); ALPN, which is bound to the DTLS handshake, is used to do so. The only potentially interesting direct consequence that I see is that this constrains any other (future) usage of ALPN by webrtc, since only one ALPN label can be selected for a given DTLS association. Should a need arise, presumably additional ALPN labels can be defined that describe the appropriate combination of confidentiality and any future protocol needs. This document is not intended to cover the details of how the actual webrtc sessions are established and cryptographically protected (if necessary), so there does not seem to be a need for it to discuss the security considerations relevant to those parts of the protocol. -Ben From nobody Thu Apr 21 14:25:39 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F418012E8D8; Thu, 21 Apr 2016 14:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4HvybpjwCMI; Thu, 21 Apr 2016 14:25:37 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C35C812E8B6; Thu, 21 Apr 2016 14:25:36 -0700 (PDT) X-AuditID: 12074423-57bff7000000258f-88-5719454faba3 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id E5.25.09615.F4549175; Thu, 21 Apr 2016 17:25:35 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id u3LLPY5j031435; Thu, 21 Apr 2016 17:25:35 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u3LLPV1W011509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Apr 2016 17:25:34 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u3LLPVRP018516; Thu, 21 Apr 2016 17:25:31 -0400 (EDT) Date: Thu, 21 Apr 2016 17:25:31 -0400 (EDT) From: Benjamin Kaduk To: iesg@ietf.org, secdir@ietf.org, draft-ietf-rtcweb-alpn.all@ietf.org Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDIsWRmVeSWpSXmKPExsUixCmqrOvvKhlucPWRtMX8Pj6LGX8mMlt8 WPiQxYHZY8mSn0wBjFFcNimpOZllqUX6dglcGS0PFQqO8VR8WvucuYFxFVcXIyeHhICJxNXu a2xdjFwcQgJtTBI95x6wQDgbGSW+7FkKlTnEJLGxZyIzhNPAKNHyGMTh5GAR0JZY+v0IE4jN JqAiMfPNRjYQW0TAXWLSwU3sILawgLHEh693wWp4BRwlDu84AtYrKqAjsXr/FBaIuKDEyZlP wGxmAS2J5dO3sUxg5J2FJDULSWoBI9MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXTO93MwSvdSU 0k2MoEBid1Hewfiyz/sQowAHoxIPL4e8RLgQa2JZcWXuIUZJDiYlUd61ipLhQnxJ+SmVGYnF GfFFpTmpxYcYJTiYlUR45zkB5XhTEiurUovyYVLSHCxK4ryMDAwMQgLpiSWp2ampBalFMFkZ Dg4lCV5jF6BGwaLU9NSKtMycEoQ0EwcnyHAeoOHLQWp4iwsSc4sz0yHypxgVpcR560ASAiCJ jNI8uF5wpO9mUn3FKA70ijBvJ0gVDzBJwHW/AhrMBDSY/64oyOCSRISUVAOjzDXJ9+kfl6Sd SFc68lB32z32olkrfm8LcmPw1UoIm6PywY9zcddSznNPyzrPBDDUyHOvakiYn5WhdlrhHvvE D9y/MxoXWK0xnuz/MPHksT1XasyFPUpz7gj5ruiMkROKz8lzn/VCfMVnjxBl3UkL4q/MnMfy bdcVh1Dm2Ae1Jl4SSq3u07mUWIozEg21mIuKEwFDWDDczwIAAA== Archived-At: Subject: [secdir] secdir review of draft-ietf-rtcweb-alpn-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 21:25:39 -0000 [My apologies to those receiving this twice; I do not know why typing draft names seems to be so hard.] Hi all, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I think this document is ready. The main goal is to provide an authenticated indicator to the webrtc peers that confidentiality is needed for the "media" (video, audio) streams of that webrtc session (or that it is not needed); ALPN, which is bound to the DTLS handshake, is used to do so. The only potentially interesting direct consequence that I see is that this constrains any other (future) usage of ALPN by webrtc, since only one ALPN label can be selected for a given DTLS association. Should a need arise, presumably additional ALPN labels can be defined that describe the appropriate combination of confidentiality and any future protocol needs. This document is not intended to cover the details of how the actual webrtc sessions are established and cryptographically protected (if necessary), so there does not seem to be a need for it to discuss the security considerations relevant to those parts of the protocol. -Ben _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Thu Apr 21 21:32:32 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49EC12DB79; Thu, 21 Apr 2016 21:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7-O9azD__sH; Thu, 21 Apr 2016 21:32:28 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29A5512E159; Thu, 21 Apr 2016 21:32:28 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.77; From: "Susan Hares" To: "'Charlie Kaufman'" , , "'The IESG'" , References: In-Reply-To: Date: Fri, 22 Apr 2016 00:32:37 -0400 Message-ID: <023901d19c50$00229c40$0067d4c0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_023A_01D19C2E.79159020" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJifLe7SGAq+mKkdyek6aXReUBP0Z5zpXfA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-i2rs-architecture-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 04:32:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_023A_01D19C2E.79159020 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Charlie: Thank you for the insightful comments. Please see my response below. I've posted a version -14 with these changes. I welcome any additional comments you have. Sue From: Charlie Kaufman [mailto:charliekaufman@outlook.com] Sent: Saturday, March 26, 2016 8:32 PM To: secdir@ietf.org; 'The IESG'; draft-ietf-i2rs-architecture@tools.ietf.org Subject: Secdir review of draft-ietf-i2rs-architecture-13 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 reviewed the -07 version of this document in December 2014. As was true then, this document says very little about security other than the kinds of security mechanisms that are needed. In particular, it does not say what security mechanisms will be used. The document appears to be part of a large suite of documents covering various aspects of this I2RS thing. I would hope the security relevant information appears somewhere else. Sue's comments: The protocol security requirements are in draft-ietf-i2rs-protocol-security-requirements, And the security environment is in draft-ietf-i2rs-security-environment-reqs. I can't resist commenting on some of the things I found confusing. It is likely a lot of my confusion is addressed in related documents. Assuming that's true, it would be helpful if some - perhaps common - introduction to the document suite specified an order in which the documents should be read of avoid forward references. The introduction section has been changed to include: Add /Security is a concern for any new interface to the routing system. Section 4 provides an overview of the security considerations for the I2RS architecture. The detailed requirements for I2RS protocol security are contained in [draft-ietf-i2rs-protocol-security- requirements], and the detailed security requirements for environment in which the I2RS protocol exists in are contained in draft-ietf-i2rs-security-environment-reqs. The document calls itself An Architecture to the Interface to the Routing System. It doesn't say whether this interface is an API or a protocol. Probably both are involved. Section 4 paragraph 1 says "I2RS has been designed to re-utilize existing protocols that carry network management information. Two of the existing protocols which the which may be reused (sic) are NETCONF and RESTCONF." This makes it sound like I2RS is an API. But section 7.2 paragraph 1 says "All such communication channels will use the same higher-layer I2RS protocol (which combines secure transport and I2RS contextural information). This makes it sound like a protocol. Section 4: paragraph 1 altered to the following: This I2RS architecture describes interfaces that clearly require serious consideration of security. As an architecture, I2RS has been designed to reuse existing protocols that carry network management information. Two of the existing protocols which are being reused for I2RS protocol are NETCONF [RFC6241] and RESTCONF. Section 4.1 paragraph 2 talks about application identity, but it wasn't clear (at least to me) whether it was referring to the application as code and protocol (e.g., Wireshark) or as the owner of the instance of the application to determine permissions. Old/ I2RS clients mayb e operating on behalf of other applications. While those applications' identities are not needed for authentication or Authorization, each application should have a unique opaque identifier that can be provided By the I2RS client to the I2RS agent for the purpose of tracking attribution of operations to support functionality such as troubleshooting and logging of network changes. New/ I2RS Clients may be operating on behalf of other applications. While those applications' identities are not needed for authentication or authorization, each application should have a unique opaque identifier that can be provided by the I2RS client to the I2RS agent for purposes of tracking attribution of operations to an application identifier (and from that to the application). This tracking of operations to an application supports I2RS functionality for tracing actions (to aid troubleshooting in routers) and logging of network changes / Section 6.4.2 says "Directly writing to these protocol-specific RIBs or databases is out of scope for I2RS" but says "joining/removing interfaces from multicast trees" was a supported operation. Doesn't that involve directly updating a protocol-specific database? No: The static joins/leaves can be done statically via general I2RS multicast FIB/RIB interface. Section 7.6 says any given piece of information... (should only be)... manipulated by a single I2RS Client. But section 4.3 says there should be multiple clients running with the same client identity. This leaves ambiguous how the clients are supposed to coordinate and whether (for example) both will get copies of notifications the client identity has signed up for. Sue: Yes, it is ambiguous in the architecture because different data models will handle it differently. For example, an I2RS model handling an ephemeral RIB may be manipulated by multiple clients, but the unique unit is the route. The I2RS RIB model indicates how notifications will of route changes will be sent. The publication/subscription of notifications is described in the pub/sub requirements. Nits (typos/language): Section 4 para 1: "which the which may" -> "which may" Fixed Section 4 para 1: "existing protocol in order" -> "existing protocols in order" Fixed Section 4 para 5: "I2RSS" -> "I2RS" Fixed Section 6.3 para 1: First ref to "yang data model" should have reference. Paragraph re-written Section 7.4 para 1: "value ranges for portion of scope policy" -> ??? Replaced with: The specifications for data scope policy (for read, write, or resources consumption) need to specify the data being controlled by the policy, and acceptable ranges of values for the data Section 7.5 para 3: "mechanism instantiated" -> "mechanisms instantiated" Fixed ------=_NextPart_000_023A_01D19C2E.79159020 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Charlie:

 

Thank you for the insightful comments.  Please see my response = below.  I’ve posted a version -14 with these changes.  I = welcome any additional comments you have.

 

Sue

 

From:= = Charlie Kaufman [mailto:charliekaufman@outlook.com]
Sent: = Saturday, March 26, 2016 8:32 PM
To: secdir@ietf.org; 'The = IESG'; draft-ietf-i2rs-architecture@tools.ietf.org
Subject: = Secdir review of = draft-ietf-i2rs-architecture-13

 

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 reviewed the = -07 version of this document in December 2014. As was true then, this = document says very little about security other than the kinds of = security mechanisms that are needed. In particular, it does not say what = security mechanisms will be used. The document appears to be part of a = large suite of documents covering various aspects of this I2RS thing. I = would hope the security relevant information appears somewhere = else.

 

Sue’s = comments:

The protocol = security requirements are in = draft-ietf-i2rs-protocol-security-requirements,

And the security = environment is in draft-ietf-i2rs-security-environment-reqs. =

 

 

I can't resist = commenting on some of the things I found confusing. It is likely a lot = of my confusion is addressed in related documents. Assuming that's true, = it would be helpful if some - perhaps common - introduction to the = document suite specified an order in which the documents should be read = of avoid forward references.

 

The introduction = section has been changed to include:

Add /Security is = a concern for any new interface to the routing system. =

  Sectio= n 4 provides an overview of the security considerations for =

  the = I2RS architecture. The detailed requirements for I2RS =

  protoc= ol security are contained in [draft-ietf-i2rs-protocol-security-  = requirements],

  and = the detailed security requirements for environment in which the I2RS = protocol exists in are contained in = draft-ietf-i2rs-security-environment-reqs.

 

 

The document = calls itself An Architecture to the Interface to the Routing System. It = doesn't say whether this interface is an API or a protocol. Probably = both are involved. Section 4 paragraph 1 says "I2RS has been = designed to re-utilize existing protocols that carry network management = information. Two of the existing protocols which the which may be reused = (sic) are NETCONF and RESTCONF." This makes it sound like I2RS is = an API. But section 7.2 paragraph 1 says "All such communication = channels will use the same higher-layer I2RS protocol (which combines = secure transport and I2RS contextural information). This makes it sound = like a protocol.

 

Section 4: = paragraph 1 altered to the following:

 

This I2RS = architecture describes interfaces that clearly = require

serious = consideration of security. As an architecture, I2RS = has

been designed to = reuse existing protocols that carry network

management = information. Two of the existing protocols which are =

being reused for = I2RS protocol are NETCONF [RFC6241] and RESTCONF… =

 

 

Section 4.1 = paragraph 2 talks about application identity, but it wasn't clear (at = least to me) whether it was referring to the application as code and = protocol (e.g., Wireshark) or as the owner of the instance of the = application to determine permissions.

 

 <= /span>

Old/<= /span>

I2RS clients = mayb e operating on behalf of other applications. =

While those = applications’ identities are not needed for authentication or =

Authorization, = each application should have a unique opaque identifier that can be = provided

By the I2RS = client to the I2RS agent for the purpose of tracking attribution of = operations to support  functionality such as troubleshooting and = logging of network changes.

 

New/ =

I2RS Clients may = be operating on behalf of other applications.

While those = applications' identities are not needed for authentication or = authorization, each application should have a unique opaque identifier = that can be provided by the I2RS client to the I2RS agent for purposes = of tracking attribution of operations to an application identifier (and = from that to the application).  This tracking of operations to an = application supports I2RS functionality for tracing actions (to aid = troubleshooting in routers) and logging of network changes =

/

 

 

Section 6.4.2 = says "Directly writing to these protocol-specific RIBs or databases = is out of scope for I2RS" but says "joining/removing = interfaces from multicast trees" was a supported operation. Doesn't = that involve directly updating a protocol-specific = database?

 

No:  The = static joins/leaves can be done statically via general I2RS multicast = FIB/RIB interface. 

 

 

Section 7.6 = says any given piece of information... (should only be)... manipulated = by a single I2RS Client. But section 4.3 says there should be multiple = clients running with the same client identity. This leaves ambiguous how = the clients are supposed to coordinate and whether (for example) both = will get copies of notifications the client identity has signed up = for.

 

Sue:  Yes, = it is ambiguous in the architecture because different data models will = handle it differently.  For example, an I2RS model handling an = ephemeral RIB may be manipulated by multiple clients, but the unique = unit is the route.   The I2RS RIB model indicates how = notifications will of route changes will be sent.   The = publication/subscription of notifications is described in the pub/sub = requirements.

 

 

Nits = (typos/language):

Section 4 para = 1: "which the which may" -> "which = may" Fixed
Section 4 = para 1: "existing protocol in order" -> "existing = protocols in order" Fixed
Section 4 = para 5: "I2RSS" -> "I2RS" Fixed
Section 6.3 = para 1: First ref to "yang data model" should have = reference. Paragraph = re-written
Section 7.4 = para 1: "value ranges for portion of scope policy" -> = ???

Replaced = with:  The = specifications for data scope policy (for read, write, =

or resources = consumption) need to specify the data being controlled by the policy, =

and acceptable = ranges of values for the data


Section 7.5 = para 3: "mechanism instantiated" -> "mechanisms = instantiated"

Fixed

 

 

------=_NextPart_000_023A_01D19C2E.79159020-- From nobody Fri Apr 22 00:35:04 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49DC012DA0B; Fri, 22 Apr 2016 00:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvhkGaQKlb-W; Fri, 22 Apr 2016 00:34:53 -0700 (PDT) Received: from gilfert.gredler.at (gilfert.gredler.at [87.106.222.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2C8612D791; Fri, 22 Apr 2016 00:34:52 -0700 (PDT) Received: from hannes-mba.local (193-81-152-183.adsl.highway.telekom.at [::ffff:193.81.152.183]) (AUTH: PLAIN hannes, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by gilfert.gredler.at with ESMTPSA; Fri, 22 Apr 2016 09:34:48 +0200 id 00000000033308D9.000000005719D419.00000CD2 To: Catherine Meadows , secdir@ietf.org, iesg@ietf.org, draft-ietf-isis-node-admin-tag.all@ietf.org References: From: Hannes Gredler Message-ID: <5719D3FA.4070402@gredler.at> Date: Fri, 22 Apr 2016 09:34:18 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [secdir] sectdir review of draft-ietf-isis-node-admin-tag-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 07:34:55 -0000 catherine, i fail to see how this does introduce *new* security concerns. background: we have in IS-IS two existing tagging mechanism's: 1) admin-groups for links https://tools.ietf.org/html/rfc5305#section-3.1 2) prefix-tags for prefixes https://tools.ietf.org/html/rfc5130#section-3.1 both "tagging-spaces" are local administered and have no global significance. the purpose of draft-ietf-isis-node-admin-tag-08 is to add support for a third tagging method which allows tagging of an entire node using local administered tagging space. (same operational spirit as in 1) and 2) ) now my question(s): - why is adding of an local-administered tag with no implied semantics considered to be security relevant ? - what specific (apparently mis-)wording in draft-ietf-isis-node-admin-tag makes you think it is security relevant ? /hannes On 4/21/16 19:36, Catherine Meadows wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all > IETF documents being processed by the IESG. These comments were written > primarily for the > benefit of the security area directors. Document editors and WG chairs > should treat these comments > just like any other last call comments. > > This draft describes an extension to the IS-IS routing protocol, that > allows tagging and grouping of nodes > in an IS-IS domain. This makes it possible to increase the efficiency > of route and path selection, since the tags > give information about a router’s capabilities. > > The Security Considerations section correctly identifies one of the main > security risks of using such tags: they may leak > sensitive information about, e.g., geographical location. However, I’m > confused by the statement following that: > > “This document does not introduce any new security concerns. Security > concerns for IS-IS are already addressed in > [ISO10589], [RFC5304], and [RFC5310] are are applicable to the > mechanisms described in this document.” > > As far as I can tell, this document *does* introduce new security > concerns, because the tags may reveal sensitive > information that may not have been made available otherwise. Moreover, > RFCs 5304 and 5310 concern authentication, not > secrecy, and so do not address information leakage at all. My own > suggestion > for a recommendation would be that implementors should weigh the > benefits of putting certain kinds of information on tags > versus the risk of its being used by an attacker, and make their > decisions accordingly. This would not be a SHOULD a MUST > recommendation by the way, but simply advisory. > > I’m not sure what is meant by the last sentence in this paragraph: > > Extended authentication mechanisms described in [RFC5304] or [RFC5310] > SHOULD be used in > deployments where attackers have access to the physical networks and > nodes included in the IS-IS domain are vulnerable. > > Is this addressing the problem of sensitive information on tags? If so, > you need to say how. If it is addressing > spoofing of tags, it should be given its own paragraph, and the threat > you are talking about should be made clear. > > In the last paragraph, on the misattribution of tags from different > domains, what would you recommend for mitigating against > this problem? Also, since this is in the security considerations > section, you should say something about how an attacker > could take advantage of it. > > In my opinion, the Security Considerations section needs a major > revision. However, > I consider this document Almost Ready, because the purpose of the > revision would be mainly to make the section more clear, not to address > any overlooked security problems. > > > > > Catherine Meadows > Naval Research Laboratory > Code 5543 > 4555 Overlook Ave., S.W. > Washington DC, 20375 > phone: 202-767-3490 > fax: 202-404-7942 > email: catherine.meadows@nrl.navy.mil > > From nobody Fri Apr 22 01:04:08 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2754712E7BD; Fri, 22 Apr 2016 01:03:56 -0700 (PDT) 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_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftbEFCq3q-Hp; Fri, 22 Apr 2016 01:03:53 -0700 (PDT) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A754912D8B3; Fri, 22 Apr 2016 01:03:52 -0700 (PDT) Received: from [128.214.10.115] (hpf-7.cs.helsinki.fi [128.214.10.115]) (AUTH: PLAIN sklvarjo, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by mail.cs.helsinki.fi with ESMTPSA; Fri, 22 Apr 2016 11:03:48 +0300 id 00000000005A0111.000000005719DAE4.00002AE4 To: Gonzalo Camarillo , Sean Turner References: <2A372E02-DC5C-4791-91D8-20D4949D6383@sn3rd.com> <5710C137.30305@ericsson.com> From: Varjonen Samu Message-ID: <5719DAE3.4080405@hiit.fi> Date: Fri, 22 Apr 2016 11:03:47 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable In-Reply-To: <5710C137.30305@ericsson.com> Archived-At: Cc: draft-ietf-hip-rfc6253-bis.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-hip-rfc6253-bis X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 08:03:56 -0000 Hi, addressed this nit with the following change " CERT parameters with the same group number in the Cert group field indicate a logical grouping. " This was the last open nit/comment in my knowledge for this document. -Samu Varjonen On 15/04/16 13:23, Gonzalo Camarillo wrote: > Hi Samu, > > could you please revise the draft accordingly? > > Thanks, > > Gonzalo > > On 10/04/2016 2:54 PM, Sean Turner wrote: >> Thanks for the reminder: >> >>> On Feb 12, 2016, at 08:47, Samu Varjonen wrot= e: >>>> Nits: >>>> >>>> nit 1: I read this a couple of times: >>>> CERT parameters with the same Cert group number >>>> in the group field indicate a logical grouping. >>>> Isn=E2=80=99t it that the same group # is in the Cert group field:? >>>> CERT parameters with the same number >>>> in the Cert group field indicate a logical grouping. >>> Is this about missing CERT word in the group field? Or did I misunder= stand this question? >> Yeah this is completely editorial; I think =E2=80=9CCert=E2=80=9D is j= ust in the wrong place. Might be wrong. >> >> spt >> From nobody Fri Apr 22 11:02:01 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F038412E285; Fri, 22 Apr 2016 11:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBWvMqeFzOgE; Fri, 22 Apr 2016 11:01:55 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A70B512E25C; Fri, 22 Apr 2016 11:01:55 -0700 (PDT) Received: by mail-ob0-x233.google.com with SMTP id tz8so52805656obc.0; Fri, 22 Apr 2016 11:01:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ftplDHNTRk5iHr8ihOihHrArIaP68tgBzG5P0t5I6vg=; b=xJgzGWQZQsNNQsGFRoHNB8+mwHblRR7Om1MECSd9hN3Z60JtgPmB2D3t40/kBDloFm xX5BXIVzCXC6CbBLQZC9lJM1PBnnUq+S+xyvzN0jF+CJpui2epFGISqPIkCa5HW7bh6N TZ3kCwKgj3RDIfudv/MIpmiMLlFnubzeiBGfmSz1jqCNhCoSfeQGx8z5yBLgruHZ+hCn rZl2AiQo54o5T8jHsSfH47U7AX3W7DeL9qKfP1OUxFqsXHDq68zZgwlQE96gx0+x8CoM W610CskIPMF8Vi7C7TB3vzATTTgZlSSoN2azpaTcJPiyBIs+hbSboR8V/yAyuXmx+MPU CbLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ftplDHNTRk5iHr8ihOihHrArIaP68tgBzG5P0t5I6vg=; b=OCmZo1NfupZpxzE9nBEjXndzRxIG85TYoDJ/tKgECarHNotJ4P11aGCQ3JM4kWUNPY jPBp9EjK/PpMBx4BFpgeeYlcVQllQ2hKJqBLNk15Bz6ZtdSMrHeDKOP2zHrC4obDc/mP cz/sKn9RAUP4ybYPrfenfauIeWtLOBlAIdh+5ZUU+5F5U47bnsOo+3Nf9yml9dl8RYDc ZhjLxE6e94HHLLVF1ExtGf0ZJODyebUMM0qDNG+A5tqujiYFjIdIt3+xyZwwJcd2qTGN vG5XGdJeWooNx6iwE9XaEs5iQamUGUQXQi7V8A6S3OkI/X0fBAP36HHriJt56K4aaoM5 1myw== X-Gm-Message-State: AOPr4FW30cTSRIbqFTzABAjcevz/MqhMjNXWpldGI28yvS/BE2aKDR8HvesoOnU40buBu524hZMx2lN50HgCqQ== X-Received: by 10.60.21.33 with SMTP id s1mr9124226oee.74.1461348115002; Fri, 22 Apr 2016 11:01:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.22.216 with HTTP; Fri, 22 Apr 2016 11:01:40 -0700 (PDT) In-Reply-To: References: <55E36EFC.6000508@gmail.com> From: Donald Eastlake Date: Fri, 22 Apr 2016 14:01:40 -0400 Message-ID: To: Yaron Sheffer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: draft-ietf-trill-channel-tunnel.all@tools.ietf.org, "trill@ietf.org" , IETF Security Directorate Subject: [secdir] Fwd: Early SecDir review of draft-ietf-trill-channel-tunnel-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 18:01:58 -0000 Hi Yaron, As we discussed in Buenos Aires, here is a revised response to your SECDIR review of draft-ietf-trill-channel-tunnel based on the -08 reversion of that draft. This version of the draft has the group keying material removed as per http://www.ietf.org/mail-archive/web/trill/current/msg07215.html On Sun, Aug 30, 2015 at 5:00 PM, Yaron Sheffer wrote: > >... > > Summary > > I believe the draft is not ready for IETF LC in its current form. I > assume the original intention was to use DTLS, but the use of DTLS > is not well specified and the alternative that's proposed for > multicast comes with inferior security. See below. > Details > > =E2=80=A2 In general, I don't understand why it makes sense to define a w= hole new > security protocol, just for control-plane traffic of one specific protoco= l, > important as it may be. At the very least I would expect an analysis of > potential alternatives (IPsec? MACsec?) and why they do not fit this use > case. Version -08 of the draft has been significant modified as below. I believe the use of DTLS is better specified and group keying is no longer in the draft, being deferred to subsequent documents. The draft specifies the use of serial unicast for multicast / broadcast / unknown unicast. > =E2=80=A2 As a result of the home-brew transport protocol, we also don't = get > a standard key management protocol. In this revised draft, although an authentication only option is provided, which leverages IS-IS key management, when DTLS is used its key management facilities are available. > =E2=80=A2 And from a process POV, the TRILL WG may not be the best place,= as > far as participants' expertise, to develop a security protocol. An > early SecDir review certainly helps, but I'm not sure the current > reviewer is capable of detecting every last issue that might be > lurking in the protocol. At this point, the Channel Tunnel protocol is being used to tunnel DTLS so I don't think there is that much risk. > =E2=80=A2 4.1: the A and E bits are not guaranteed to be correct? Then wh= y > are they here? They describe critical security properties, and > therefore someone is bound to use them to make critical policy > decisions. If the bits' semantics are not guaranteed, we'd better > drop them. > =E2=80=A2 A bit: I think we are confusing authentication with integrity > protection. With opportunistic security, you usually don't have > authentication, but integrity protection is still worthwhile. These bits have been eliminated. > =E2=80=A2 4.2: Coverage - it would be nice if Fig. 2.1 showed the coverag= e > of authentication (integrity protection!) and encryption. Why is an > Ethernet frame's FCS not covered by integrity protection? Is there > any non-malicious reason someone would want to modify the FCS in > transit? Figures showing coverage have been added to Section 4.2. The only time there is an FCS is if the link between two RBridge ports is Ethernet. If, for example, the link is PPP or pseudowire, there is no FCS; In particular, the inner Ethernet-like payload of a TRILL Data packet does not have an FCS. So providing integrity protection of an FCS does not make sense. An RBridge Channel packet looks like a TRILL Data packet and can go multiple RBridge hops some of which are Ethernet and have an FCS and some of which are not Ethernet and do not have an FCS. Even if all were Ethernet, the FCS can change due to changes in presences/absence of an outer VLAN tag or other tags or the like. > =E2=80=A2 4.3: "in some cases" - why not simply say, "When SType is 1 or = 3"? While this is always done for SType 1, it might or might not be used for SType 2 or future STypes. (The SType numbering has changed a bit and there is no STyp3 in the revised draft.) > =E2=80=A2 4.3: why deconstruct HKDF and use HKDF-Expand instead of simply > using the whole thing, including HKDF-Extract? Because the draft follows the advice in RFC 5869 that specifies HKDF: In some applications, the input may already be a good pseudorandom key; in these cases, the "extract" stage is not necessary, and the "expand" part can be used alone. Version -08 of the draft says, "It is assumed that the IS-IS keying material is of high quality." > =E2=80=A2 I am confused about 4.1 vs. 4.5, and specifically, what does th= e > Size byte cover. I think this is incorrect in 4.5. Maybe I am missing something but they look compatible with me. Section 4.1 is more general, and now says that when security information is present it consists of four reserved bits followed by 12 bits of size information followed by zero to 2**12-1 bytes of "More Info". Section 4.5 is more specific and says that for a particular SType, this "More Info" consists of the two byte RFC 5310 Key ID followed by a variable amount of "Authentication Data". > =E2=80=A2 4.6: this section starts with certificates (presumably, both > client and server should authenticate with a cert) and then moves on > to PSK. Are both allowed? The current draft provides that if DTLS is in use, then PSK MUST be supported and certificates MAY be supported. Perhaps that MAY should be turned back into a SHOULD. > =E2=80=A2 4.6: TLS is rapidly moving toward perfect-forward secrecy. Why > require a cipher suite that's being deprecated across all of > industry (TLS_RSA_WITH_AES_128_CBC_SHA256)? The draft no longer specifies cipher suites and is intended to just defer to whatever the DTLS implementation requirements are. I am not sure how much the following comments apply to the current draft... > =E2=80=A2 4.6.: I am still unclear on how CT keys are derived from DTLS. > =E2=80=A2 4.6: Why have a TRILL-level key ID with DTLS-PSK has the notion= of > key ID? > =E2=80=A2 4.6: with certificates the frames may be very large. Does the p= rotocol > support such sizes? > =E2=80=A2 4.6: there should be a lot more text about how DTLS is used to = wrap L2 > frames. DTLS is not used to wrap L2 frames but rather to wrap Channel Tunnel payloads. The type of the payload is give by the PType. True, there is a PType that says the payload is an Ethernet frame. Figure 3.4 show what it would look like without security or with just authentication. Possibly a figure should be added for the DTLS security case. > =E2=80=A2 4.7: if this mode is assumed for multicast, what is the > assumed/recommended mode for unicast? > =E2=80=A2 Obviously integrity protection where the MAC key is shared with= all peers > is very weak. There are various ways to deal with that, starting with RSA > signatures but including more efficient methods (TESLA comes to mind). Ha= ve > you considered any of them? Group security for multi-destination Channel Tunnel messages is being deferred to another document. The revised draft only covers use of serial unicast with pairwise security. > =E2=80=A2 4.7.1: if the authentication data is variable length, you must = ensure that > the field that indicates its size is integrity-protected as well. > =E2=80=A2 Actually, I'm not sure where this size is indicated. Its size would be indicated in the Channel Tunnel Header (which includes the Security Information field) that is shown as authenticated in Figure 4.2. > =E2=80=A2 It seems to me that a fully random 128-bit nonce would be both > simpler to implement and more secure than the scheme proposed here. > =E2=80=A2 Typo: designed -> designated. > =E2=80=A2 5: assuming we will have DTLS handshakes nested within CT, how = are > errors indicated? If DTLS is not supported at the destination, then you get a Channel Tunnel (actually RBridge Channel) error saying SType not supported. If DTLS is supported at the destination, you get a DTLS error Alert back as a Channel Tunnel message. > =E2=80=A2 General: is there any facility for replay protection? If no, wh= y > not? When DTLS is used, the DTLS replay protection is available. There is no replay protection if no security is used or if RFC 5310 authentication is used. > =E2=80=A2 7: The more normative parts of the Security Considerations woul= d > probably fit nicely into a separate Applicability section. > =E2=80=A2 7: I think the document should be much more clear (normative) > about what message types are allowed within the tunnel, or not. And > possibly about required filtering by address. I disagree. The whole idea is to be a general, extensible messaging facility. I don't think it is possible to anticipate in advance what people might want to use it for and the tests they should make. I'm not sure how much more can generally and validly be said other than to be conservative in what you accept and, as it states in the draft "only process payload types required and then only with adequate authentication for the particular circumstances". Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Sun Apr 24 08:13:14 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F600128B44; Sun, 24 Apr 2016 08:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLLGCA81P7gZ; Sun, 24 Apr 2016 08:13:08 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4348D1200A0; Sun, 24 Apr 2016 08:13:08 -0700 (PDT) Received: by mail-pa0-x229.google.com with SMTP id bt5so2118010pac.3; Sun, 24 Apr 2016 08:13:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version; bh=+T5v2358w81YpamyZmgdtAZKCk2JJVo9F1PD1FW1pOI=; b=Eqoxh4p9Wq8ye7HIjnho5l11lzja9ev5/GyTJv8X5BV/7bVhl/nvly59SyPE2rI4fM qxaZJAwSH5lxpHrXCDhS8WurycRX06UWSaPHV8tDxFPczvAnpS1LcBr/i4RR9jJLPZAO +jjnVurj7yxmsBu+/exkDU/CBdWxciyzSpCgyc2C38JTlmdQTylusyL62ObNKcVzqlMh 3n1nqSHZPzXKdP3YgrBxCg2wyPXEsJcLPsYij5iPr0REB8Peq070rzJqDcGXrd+6W/p8 0pxDFsj5uHh+cDHhi2Gok7WPO34JyaqSAYLs/60LFLrBQWWog88fothgUEVAC6MbiLzg g5sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=+T5v2358w81YpamyZmgdtAZKCk2JJVo9F1PD1FW1pOI=; b=lxqCbTu8p2jJkPnFkFTjVzhDHsvjT7HocVDned0Fqbe8hRlrLKUFuQ7v5l/cA7cZhl 13ivlgn5emeCUMEgWCHb0ncLmPI4AGYxMvkrgYzP7qgCs9RwBCv9H9AzuN52DfnqhlrV s2820nJwTaxZ/+c9FzMDRrnbMimf30n2sJQFMNw8EQFXtys+quW1Zq39aoFmFqeKUiIV FOGuy2wQlvAIGRmr8UMhDMG7hx985LyJR6Jl9Z/UcXa3cShqb1uHi1EZiYeCjeaqUbvw D1LVp8cOqk4nSuAf2iFYNCQ6JOsCsmBWFvd4f1aa99OJPnTl/wKnoIHQecYWdhDf3axi hAmQ== X-Gm-Message-State: AOPr4FXEUhxqgHjnPyCFPWQRfTccVd3ngN76o/aa9IPAe3gYxMATWZiiJV2kjg1k/0/ZLA== X-Received: by 10.66.123.105 with SMTP id lz9mr42450437pab.37.1461510787809; Sun, 24 Apr 2016 08:13:07 -0700 (PDT) Received: from Chriss-Air.attlocal.net ([2602:306:838b:1c40:8159:1d42:165:e93e]) by smtp.googlemail.com with ESMTPSA id wy7sm22945708pab.5.2016.04.24.08.13.06 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 24 Apr 2016 08:13:07 -0700 (PDT) To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-idr-route-oscillation-stop.all@ietf.org From: Chris Lonvick Message-ID: <571CE281.3080308@gmail.com> Date: Sun, 24 Apr 2016 10:13:05 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------020502000001050804000601" Archived-At: Subject: [secdir] SECDIR review of draft-ietf-idr-route-oscillation-stop-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2016 15:13:10 -0000 This is a multi-part message in MIME format. --------------020502000001050804000601 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Overall this document appears to be ready. The Security Considerations Section points back to the overall security concerns of BGP [RFC4271] as this specification does not add any new parameters. I think this is appropriate. Regards, Chris --------------020502000001050804000601 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi,

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

Overall this document appears to be ready. The Security Considerations Section points back to the overall security concerns of BGP [RFC4271] as this specification does not add any new parameters. I think this is appropriate.

Regards,
Chris

--------------020502000001050804000601-- From nobody Sun Apr 24 16:29:09 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A72B912D17A for ; Sun, 24 Apr 2016 16:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IUQJLsE-ynC for ; Sun, 24 Apr 2016 16:29:07 -0700 (PDT) Received: from xsmtp04.mail2web.com (xsmtp04.mail2web.com [168.144.250.231]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6127E12B01B for ; Sun, 24 Apr 2016 16:29:07 -0700 (PDT) Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1auTSb-0007Zz-JL for secdir@ietf.org; Sun, 24 Apr 2016 19:29:06 -0400 Received: (qmail 25382 invoked from network); 24 Apr 2016 23:29:04 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 24 Apr 2016 23:29:04 -0000 From: "Christian Huitema" To: , , Date: Sun, 24 Apr 2016 16:29:00 -0700 Message-ID: <033501d19e81$1697ec40$43c7c4c0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdGegQTs2dkO8CpOSNm3gn0kEh7hDg== Content-Language: en-us Archived-At: Subject: Re: [secdir] SECDIR review of draft-ietf-bess-pta-flags-02.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2016 23:29:08 -0000 Resending with the proper IESG address. Sorry. ================================================= 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 ready with issues. The document defines an extension mechanism for the "flags" field in the "P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute" used to carry information in BGP about multicast routing inside VPN. RFC 6514 describes an 8-bit flag, with 7 bits reserved and 1 bit defined. The draft reserves one of the 7 bits as an extension mark, and proposes to create an IANA registry for the remaining 6 values, and for the values of the newly defined extension field. The draft is pretty simple, but it poses the generic issue of extensions. What happens if some routers in a domain are aware of the newly assigned extension and some are not? The authors argue that this behavior is properly defined in the documents describing the future extensions. This is plausible, but the draft does define a generic mechanism, and does switch the meaning of one of bits marked as "reserved" in RFC 6514. We have thus two possible issues: 1) A router supports RFC 6514 but does not implement the extension mechanism. 2) A router supports the extension mechanism, but does not support the specific extension. I am able to guess a plausible behavior based on the text in the draft and the reference to " Treat-as-withdraw" option of RFC 7606, but I would much prefer if there was a recommended behavior in the draft. -- Christian Huitema From nobody Sun Apr 24 16:45:54 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCA4D12D12F for ; Sun, 24 Apr 2016 16:45:53 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E2 hex): To: ,\n\t<\342\200\213iesg@ietf.org[...] X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7pzoESc3Bd2 for ; Sun, 24 Apr 2016 16:45:53 -0700 (PDT) Received: from xsmtp12.mail2web.com (xsmtp12.mail2web.com [168.144.250.177]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4416C12B01B for ; Sun, 24 Apr 2016 16:45:53 -0700 (PDT) Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1auTPY-0004xp-Rl for secdir@ietf.org; Sun, 24 Apr 2016 19:25:57 -0400 Received: (qmail 30718 invoked from network); 24 Apr 2016 23:25:55 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 24 Apr 2016 23:25:55 -0000 From: "Christian Huitema" To: , <​iesg@ietf.org>, Date: Sun, 24 Apr 2016 16:25:53 -0700 Message-ID: <033301d19e80$a6261090$f27231b0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdGefQkRRs1G2+4uQ6Cv4Kv4fVoTKg== Content-Language: en-us Archived-At: Subject: [secdir] SECDIR review of draft-ietf-bess-pta-flags-02.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2016 23:45:54 -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. The document is ready with issues. The document defines an extension mechanism for the "flags" field in the "P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute" used to carry information in BGP about multicast routing inside VPN. RFC 6514 describes an 8-bit flag, with 7 bits reserved and 1 bit defined. The draft reserves one of the 7 bits as an extension mark, and proposes to create an IANA registry for the remaining 6 values, and for the values of the newly defined extension field. The draft is pretty simple, but it poses the generic issue of extensions. What happens if some routers in a domain are aware of the newly assigned extension and some are not? The authors argue that this behavior is properly defined in the documents describing the future extensions. This is plausible, but the draft does define a generic mechanism, and does switch the meaning of one of bits marked as "reserved" in RFC 6514. We have thus two possible issues: 1) A router supports RFC 6514 but does not implement the extension mechanism. 2) A router supports the extension mechanism, but does not support the specific extension. I am able to guess a plausible behavior based on the text in the draft and the reference to " Treat-as-withdraw" option of RFC 7606, but I would much prefer if there was a recommended behavior in the draft. -- Christian Huitema From nobody Mon Apr 25 10:40:41 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA35E12B029; Mon, 25 Apr 2016 10:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPllnPlb1sbM; Mon, 25 Apr 2016 10:40:38 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0127.outbound.protection.outlook.com [65.55.169.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7D7312B018; Mon, 25 Apr 2016 10:40:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GGnbIHRVgSXI516TjZMZE731I4rgDU4I1ghF0+pRV3I=; b=VcIsB+V9mCuwzq/vLjuyJMjrpmhodu8zOkoThcjuPIIWvpgJtwbHGA6m+BIhdiHthQu9XCvK/n7LR8FBgpMtxJbaEKCS1MIGiTt0j0uhdgPGTDxIszhnbn8wRoihMMReTh5l7TSjD/iudaLPKo1jG/uFQSzlQhMOOZfmVmBppLY= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.35.186] (66.129.241.12) by BLUPR05MB786.namprd05.prod.outlook.com (10.141.209.145) with Microsoft SMTP Server (TLS) id 15.1.466.19; Mon, 25 Apr 2016 17:40:31 +0000 To: Christian Huitema , , , References: <033501d19e81$1697ec40$43c7c4c0$@huitema.net> From: Eric C Rosen Message-ID: Date: Mon, 25 Apr 2016 13:40:26 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <033501d19e81$1697ec40$43c7c4c0$@huitema.net> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: CY1PR12CA0032.namprd12.prod.outlook.com (10.160.137.42) To BLUPR05MB786.namprd05.prod.outlook.com (10.141.209.145) X-MS-Office365-Filtering-Correlation-Id: 0da52cb5-5674-47cb-641a-08d36d30b38f X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB786; 2:BN3sAqL3ZPltXY3MUd7fS806mz2R6Q0xFwpABCON5r0XR3FNJHrrdLmpFWffWGuGPNEEgRiGSbwgGSGOSF9utVPX0OoZYbA4xRSn3bua7JnWAI2w6hOjIyjF/HqRpUZkwca5wz7473Y7phjmFkUsesF1TKaqswRA4jHm+wy6+0LqpER8/pwNvdQlWTyeoEcS; 3:V6FaVJqx2qRX1ijabstYOaLLjXhnTSBHlxLDvqht4C/jM84nx4hLjFKY2EAZtkI9CmdbcZiKEd4ItZh0KonxuaStgTrCp+LngwqMMQ1nkq2eeu7vM+EYBQTn7bsEajYf X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB786; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB786; 25:ir80/aUmjHFgA4NMhJ5bakE8MFdHuv2kD5HiWMI21quknbnHNCYzuq9z4jpGzsVvrBIIZxuSESGq+JGDqQMguZK/g2/CjpNplTxppeFnJDue/lDJ4fSCroRE/clNfUTfVwIGIBYmOTubmtiPLg3dcj8BzwVXWUcW6GrK5rNAVVr1FHw0Wz0XN1iD9AatQbr+a2KXdp6LeGUvnWhhvPsFTXArhujsTlDTyRXFzgNptV+w6XllhOKcHvh2B7aojoyHPXKiVVCokIGKALIRr2TCTXn5C/IuYgnktuNIjfR7Vz7j15epZhxtdFRl2cC/yY94y0HAROi2HD0l4OmvCgHqwCcDKiIQfOKzGUX6kN9RAWtHDfG7vQf5E/02R1UE0s3tqjVnFKI6pcqxJvsHEINfnDDsne09NEi1O0H4bxW0nrS07SedfEGX3YkMoqBmrvaG1t4HxeJT8H3spq6ojGxdbi5gbILCgp85yqfk/FCPhyFPUE3wlbOfE6KcLANS9UNez8IAjU2mJfvMkbl0iGbayG5Tmrp7EwQJVeOOFh9YEn+39DXDq4LzQ8/GZmEPPgPSi1NdpEztRiQ8xSUee7FAKctsKPWwl9Hds3MNT9bTGsRBjb8yV2mShQttpCpk10DjPeinK46n42DdDKY0UtZuow== X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB786; 20:fv7O/7hI6YLMkPC7adyEjpvB9UNmn8xd/XylR2huCwXZOLTqypU65qQ1iyGkxXjE6+8ke3tYv/vutuxjx/bwzzKKSq7PPn15+U8Xl3uMvb1QTCiPRu+MQgbDtw4CHTWuXs4GQwHQclOe3OMOYIbrO5ewJq2Jz6dZ8UdF56IsNka8W9xwXaDw6IblwYrMEUd6LGw4CoR4f/+ON8yyFuLzxUuJ1u4ORuGmJU2SPDMgRtvTGWiYJzuLH7r89+4Eq4i1O2t/yC4wJHLf8MvwgzKePg8lS1p43YIChMMwTwov5Y8GDtKbt90EArM28SMa5tCndp8sEIOImDVK6ZvlYnWQMFdslENGbvS+TvgSYHRGaFWBxA5NfYynKpaSUxIJF56K3wuqXnMLVWVrMqbISkwu7s/JaXZE5fL10EdItTk+slSnOCxyI8ooFM5D5YsjO/Qk1ul9FGlM1GaaXjUUUcRinjdKBxDinzOsg0THHp/Brr67kk4k2Fxqc25YNUxk2ayg; 4:vpotEBXMMRL0uF6nam2DcUM/c6PXqJWTDzYUU14OxiLkedRmnRT0HDv+95AHeKwWiZbYSmFHADKwZ3iSK/VcaYEh/rVWua36kOjsQpGORoDOA//2Ql94iDJxckco3q9yR+GJvvyH7YPt2laI+HRxr9jcND8rcNkk+UlonC4OhyJyP2+xACZaPv3h0AvLD81YDdx7wfM441nzZvF/TGX/uLcbuyvDQIr2xwvLsijgmSsouhE/e9GZSEkuX7pf5B8ZG2YzN7ryQWscLulkLGCtWLAJvATTWxEZysGUMky4p6mRT9q5XThfAJ25G4wKhzxOOmlUr3TwpNqop3qDMh1ICwg3YtDPi1ZBB9g6qM5Tfbm94k310dXZdhiTtxJQ2nJ7T7KSQjyBZENS4JrO+VQZ+eLX3L19R257fxGWPzoOVkA= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(9101521067)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:BLUPR05MB786; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB786; X-Forefront-PRVS: 0923977CCA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(24454002)(377454003)(92566002)(23746002)(81166005)(83506001)(5008740100001)(77096005)(2906002)(5001770100001)(2950100001)(230700001)(3846002)(6116002)(189998001)(107886002)(586003)(2201001)(33646002)(1096002)(31696002)(230783001)(86362001)(66066001)(64126003)(65956001)(42186005)(65806001)(54356999)(5004730100002)(76176999)(36756003)(50986999)(31686004)(47776003)(65826006); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB786; H:[172.29.35.186]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BLUPR05MB786; 23:TAA0wYhJJHBNlVvRh9VGzQHjCI3vdjN9YqMfwU?= =?Windows-1252?Q?Ab0cg6xYZXnR3e+2l8o3arSjpBW5K47ImQZUqPDnX6qbUMqXMfpYLCUH?= =?Windows-1252?Q?UOeCjG9XxUpNab/L/k92UejZ3rUGGk0vu8+/E2HLgiNP7eEXAnbtSxDJ?= =?Windows-1252?Q?aAF81qzJIr85u1I9i6Jcy9P61xqjUbOZ7EOfjmqfwkisR16fnZSDqEsm?= =?Windows-1252?Q?UZ/cUBGXMnBXfGIgFYw7oTS19i8v1odUaEfezGUqTVduad3zoPANxJJa?= =?Windows-1252?Q?7QWRnvsFJzDXvh0t3WlfguaEdaCRdv8+UncVdOErpBOqBCGKN80uJiGU?= =?Windows-1252?Q?GpxRlBVZ3wNxIz4/8Z+FdMfaJwC7TJoCGdeiN+iCrzz1mPSpZYNU3CrF?= =?Windows-1252?Q?x/78ui+KTaaqWXt0ZqiYet7mcCCPdf/DbXbxw9OUBopswicRK929nLN2?= =?Windows-1252?Q?NnTsghhXPyYK8DgrtTGVKndcnoFGvY9WnwSCyjFBrD4OXClDlOXit791?= =?Windows-1252?Q?Ql/0l95vhzCK0DF/MdStUUIz9lLpc+XJnMW4lOzKwA5UOBE1QCS+nN4t?= =?Windows-1252?Q?ur/TRoRLP9K29d0IxFrxAd5JxxdBE5PU7mHl0102tDZLdsiLWLzQvtWj?= =?Windows-1252?Q?GrT79RFfzV+lT/A+67pYdCiTL3PCC+Td3ymz22Wpm7Y8JEUAgXvIb1PP?= =?Windows-1252?Q?Zk9nKITgXUTzx3IYrj5Oo/VSeMGuxTcTB5v2RBXWUw50OgFXwoLfdQY7?= =?Windows-1252?Q?noF1IKLbOuIsC7XbCNJyYkdy88inTc487IWvVlxxuUbeRJTMXbhBTtIC?= =?Windows-1252?Q?zi/0KN/w2grgaCWI0GSM2XiLQ27lvB4AEhKSJhchSehPDm0ESbyfO8Tx?= =?Windows-1252?Q?FzwixtSnd3GAdHQmdDpG5v3rC9IsHsXCMDph0DAt9nwixeC4qDurahiZ?= =?Windows-1252?Q?lXUdvLs+Dw2zYIliSV7w3uDWZD+25Ir7YZHS4YCz4EY8DQUB+hKs89MP?= =?Windows-1252?Q?4HhYcFXDmGhNiwdtFHvk+OCskaJVIDByf4zYkzIwL8NvWh3I5UQjUJp6?= =?Windows-1252?Q?979Mfs30xzAXU6RNLrWWA/1f5wArifbQLGT8RtOMjcpJzmwNSbJWOvkg?= =?Windows-1252?Q?=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB786; 5:3N3vt/+gcjQqoTyKMXME8Lswwu5UAYSj1mOIEQGEel3gG6fEejTppri2hSHNi+ot8rcJUg9fQMxT56iZyg3lsefeOx7y++JWYshPQ3qxEKw36tT11+qkWX92vIbvBnCc7TX4kEqJr4x8sEEnAmEjj6okMdUEzOOvVWN4IPmdpzQ0/k3m0Js9nBx3521iYdux; 24:nP+NNMulso8LPZjwUG7Hm7WVXOpLBYJQxhVXBO5liVnQobRVN1PsfZMOsW6FDM3O8Dwy4YSzWHc6jFJaVMuREvJyLjB2/3w/w4ckHWEi2P0=; 7:ykIK2C+xe/uyxuYr6dU1dUGsz6J1bxjKrmj47ui0Tdu5x7RquiD6knv6VzyjhmZyGF8KEciazmShcKpUwDOB973IGsGGHobr2oO2pJUAhZCRHOiXLc2RHITUdkz8/Y+UBV/t1QSHJGWmN1+kX3enDHXt3MWVkIXwaKycmo0b0lQC4b7uvpYtH7PzefUmrHQ7XBjxyubJQ83Yc/H9cDJAHg== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Apr 2016 17:40:31.7592 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB786 Archived-At: Subject: Re: [secdir] SECDIR review of draft-ietf-bess-pta-flags-02.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 17:40:39 -0000 On 4/24/2016 7:29 PM, Christian Huitema wrote: > We have thus two possible issues: > > 1) A router supports RFC 6514 but does not implement the extension > mechanism. > 2) A router supports the extension mechanism, but does not support the > specific extension. With regards to case 1, I don't think there's much to say. A router that supports RFC 6514 but not the pta-flags draft will ignore all the flags except the one that is defined in RFC 6514. Similarly, in case 2, a router that doesn't recognize a particular flag will ignore it. However, I can add some text to the draft saying to ignore any bits you don't recognize. If there are mechanisms that require the use of a particular extension, those mechanisms won't work properly with routers that don't support the necessary extension. Applications that require such mechanisms either need to provide signaling to determine whether all involved routers support the necessary extension, or else they need to define procedures for interworking with routers that don't support the extension. I could add some text stating this, but I don't think there's much more that can be said. From nobody Mon Apr 25 12:20:28 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5C612D522 for ; Mon, 25 Apr 2016 12:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4E_VObc4k7Oi for ; Mon, 25 Apr 2016 12:20:25 -0700 (PDT) Received: from xsmtp11.mail2web.com (xsmtp31.mail2web.com [168.144.250.234]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 440F512D680 for ; Mon, 25 Apr 2016 12:20:25 -0700 (PDT) Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1aum3Q-0000ij-CA for secdir@ietf.org; Mon, 25 Apr 2016 15:20:24 -0400 Received: (qmail 402 invoked from network); 25 Apr 2016 19:20:19 -0000 Received: from unknown (HELO huitema2) (Authenticated-user:_huitema@huitema.net@[131.107.147.60]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 25 Apr 2016 19:20:19 -0000 From: "Christian Huitema" To: "'Eric C Rosen'" , , , References: <033501d19e81$1697ec40$43c7c4c0$@huitema.net> In-Reply-To: Date: Mon, 25 Apr 2016 12:20:18 -0700 Message-ID: <045801d19f27$818c46d0$84a4d470$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJ4tIhog5CnxYH6q0cOrVpsm7GB3QHgxMhnnj3d7RA= Content-Language: en-us Archived-At: Subject: Re: [secdir] SECDIR review of draft-ietf-bess-pta-flags-02.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 19:20:27 -0000 On Monday, April 25, 2016 10:40 AM, Eric C Rosen wrote: > > On 4/24/2016 7:29 PM, Christian Huitema wrote: > > We have thus two possible issues: > > > > 1) A router supports RFC 6514 but does not implement the extension > > mechanism. > > 2) A router supports the extension mechanism, but does not support the > > specific extension. > > With regards to case 1, I don't think there's much to say. A router that > supports RFC 6514 but not the pta-flags draft will ignore all the flags except > the one that is defined in RFC 6514. > > Similarly, in case 2, a router that doesn't recognize a particular flag will ignore > it. However, I can add some text to the draft saying to ignore any bits you > don't recognize. Yes, please. > If there are mechanisms that require the use of a particular extension, those > mechanisms won't work properly with routers that don't support the necessary > extension. Applications that require such mechanisms either need to provide > signaling to determine whether all involved routers support the necessary > extension, or else they need to define procedures for interworking with routers > that don't support the extension. I could add some text stating this, but I don't > think there's much more that can be said. Don't routers have to relay these extensions to BGP-adjacent routers? In that case, are they supposed to blindly relay the extensions that they don't understand? Are they supposed to reset the corresponding flags to zero, or just leave them as is? It is probably obvious for you, but these things are often better said than just implied. -- Christian Huitema From nobody Mon Apr 25 13:25:38 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBE512D545; Mon, 25 Apr 2016 13:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lytKxMjUfWVJ; Mon, 25 Apr 2016 13:25:35 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0752.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:752]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F37212D5E8; Mon, 25 Apr 2016 13:25:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QyKt6mmtLHIDjFaTvvWNBnxKuGcGbvyqgP/KVtd21uc=; b=LJE/0Y/KDU+n+mtm1OYzkOICNbjaw0kswQG1311+JjN9dY1HN6LpJ7S3SDw5r8eYs/pyEiGUgVmMjlnZdStJX0B1+1oputLVQnUIM5hsNG9jVdhfBQB2/ZEAiLDc/9b3BuNo0dn168aP2n5rw1RXVsUkxeemy1Ih0wkDOYXmCZU= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.35.186] (66.129.241.12) by CO2PR05MB794.namprd05.prod.outlook.com (10.141.226.19) with Microsoft SMTP Server (TLS) id 15.1.477.8; Mon, 25 Apr 2016 20:25:14 +0000 To: Christian Huitema , , , References: <033501d19e81$1697ec40$43c7c4c0$@huitema.net> <045801d19f27$818c46d0$84a4d470$@huitema.net> From: Eric C Rosen Message-ID: <45cc2319-d1c9-976a-ece1-0697a623e21c@juniper.net> Date: Mon, 25 Apr 2016 16:25:10 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <045801d19f27$818c46d0$84a4d470$@huitema.net> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BY2PR0601CA0002.namprd06.prod.outlook.com (10.163.62.12) To CO2PR05MB794.namprd05.prod.outlook.com (10.141.226.19) X-MS-Office365-Filtering-Correlation-Id: e2c7185b-f6ba-45be-ac2a-08d36d47b641 X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB794; 2:rABGBFGfTmOQlhCXOWMThPqj4N2Qmdh5sjHfGmoeW0sEKQxKgERDLebST46JFn04pwJax63XcvSnl6G8S/RMlY9hOFWwACHVkScvnJ+grPeMB+gMBKe3A5Jsgm2NkTRIwNB4uzENVlZK7U36lXYkH3pmqiYk9yDhWsir+N444BnwrCvYWRainGljNeb7N+LQ; 3:+FKsIgU8iNlmu3oleQh3lE/HZOZEU757sIR7Gt1zmlV2npBAJBobYDRay8TPqcs2w+V1Jyc9WLBJNaDbwElizXQPoIAvYjxBhbuwnhkIQoFZFDkuTlnjV5mlX8KsOFAD; 25:ELKjcq18M6VdB6JUB0/jXIeQcj2nZVcYHHmiQWeS/XUGm9BXFvrCfpANlFuG8O89HJGN0mp/gv3U4HRwYBDUHCyG31TMGKKxjI5aExzYrkwG9KzVllQ3EhRkXDez06Qp/LBIzZto9QRZ2DYHNBC+vkFIXpEw1oB02iwiF7CqIa+ibmZ2Mbn7wMyOQq/j3MxNS+WNC1Wmjbc3B2tHfqazdcCj1TKOpnYoSNqtUJ9hm0fMy8vMaN7dAZhYe66kd/SpdS5O26/MmuFBF/kNvahf38AMzR2szJskmZrQTOPh+NSkHtEbLF9gqbKjHceoQ+/R+qW0L9Tg2kvyKIV1l2OlkQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB794; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB794; 20:zrV8W/8QnhKeouTgoHj4OiBuRM0uZWMSPGj1m4v2coPWWQ3/3aE4VtJVUIUbhaNZWBCGU/h87aI4GhuhJ3YSdcIgB2lEP+oJ1FE1GDt393fYrm17FkmiCbybr5bmMuGabEtx+OjblfnGKC5Inyrv7NSwrv9qHV9psWUgFmoPW5n7oDVo8jgAshkmWS89+nAkyB5u6b0JeP3DR9/bS3mfIc929ofwXy91ksfOeK2fuPLlLQcgElMQiAhbX53iHkichIlMqJL68S6zoSPt8jap6GTy3T6R31VrZdemM304AuJvhNFS8HvHU8gT+JvxuzULXCLOHLbHeAAZwE2bb5uLM4P0GLau3vtqoeuUpm6BhNkggxiyNu0vufnUNIV+Ew4ZXUk4TgeYKR+1ALBytaC767acUqkUkANtl8LPZ5Jme28wJUOAphPb/nOvoZiDgTeXV/o4XHpEUOVY8Y9iNmSryGavAPEJ66mC1O5JPHqzpG4qx9JYxPQbmW8DH+pc2lD1; 4:u1bZWngZ3JsetBIgWVCvqT5kHivlz3f7gYv3NJ/C7JzGFc7BV8fc+uENKPft8A6rPZW+FYHIabL6xyVDYmyS/DzOw01t3DL193sbK23ZCUCrMyoJLahAUNOg7+4jOxGTZQzQET5IlPdRlK+cP4xKjnFTsXnBRtBLgHHvzh/N3Min8JfzS5MfNQBAkRjRRNgWVs9phzKoVaGofBbs4OQTGA97LMyO8Orp8gkYejOuArSHahKfsx0glnQP+am6Unjf5u2ab1eTjlFqy1MEk8Xy1ul2PFJeQZ8kE+ZxINY14R39rJLQrS1swyHK+D37xJzFvs153uUsDpckRfHDWzqh3rZ0w54V09dh6Ge+OpxH+6lS861QnRyTS8siuE2h1iJsN/PcamD5LOoevmRjioIX3+40UV39vPNi6HJvNUkMQwo= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(9101521072)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:CO2PR05MB794; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB794; X-Forefront-PRVS: 0923977CCA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(24454002)(377454003)(83506001)(5008740100001)(2950100001)(65806001)(3846002)(50466002)(23746002)(65956001)(1096002)(66066001)(5004730100002)(42186005)(47776003)(6116002)(31686004)(33646002)(76176999)(50986999)(54356999)(92566002)(586003)(2906002)(2201001)(230700001)(4001350100001)(81166005)(86362001)(31696002)(230783001)(107886002)(36756003)(5001770100001)(77096005)(189998001)(64126003)(65826006); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB794; H:[172.29.35.186]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; CO2PR05MB794; 23:HCQO9ewPwCfIbJQ3By7y2qqrIlp5qmWVWkChNK?= =?Windows-1252?Q?PcwACXU0nKqDShqqkzEhiGr2SIDSoGWQ1+0rrzIlL2aro/ndgcWzfLXl?= =?Windows-1252?Q?uodpJVJOszKBE3FA3AnOC28t4hiQ4kn3x3hmPgyI46hYOXW1O2sfFkm4?= =?Windows-1252?Q?KMwq1BgY9ar5VK4wZeFSn5pKWBbfvwhTWAqzhRfD4mweUWBXyq2WODm3?= =?Windows-1252?Q?jRD2DO2P6tKl1Y5itKi5mmMltkshqdx75PSazaoijR/AwVsiV0Fn5VlH?= =?Windows-1252?Q?s+xDn9MTxXtHcObIubvHDC9LS7x+XHdQvSt4I5fj3nZlFUFkkP7O6kMb?= =?Windows-1252?Q?CcDqdMuer4hUkxFtdTu+T1rmPQ3uz0w5C+8Rnhez4IMFzvUz1m5G69CC?= =?Windows-1252?Q?LtKFo8r3qjUfaCAaRh4Lx6ydl3GNAGRFtr0LKjXFVYL/RjmySYQYUj0I?= =?Windows-1252?Q?6QlIf7EE0/vubeX10qDslNPA6FDJvY7fM+Bl680gcZJ3KwowXdc01mpm?= =?Windows-1252?Q?Id+VycDrcEWYkvzsD1HmHVApCy9QcE6sfiUO25acVqHBoKy9Nb51lOR6?= =?Windows-1252?Q?9RTRQCnnYZIE0yr7DM9ZLPoRYQISwAiaARXO2Hmn+qQ/ogZbmFws9El2?= =?Windows-1252?Q?fpiJRJRR8f+AvIVwle3qxqEzSqrT2VAl3/qeDdlCVwFPASla2mDBCz56?= =?Windows-1252?Q?r0uXqRiCWvHomZ6VoRpZCgxNJOmPoCI6yVEk4wT8OX0XwG+JFGxK0PIA?= =?Windows-1252?Q?NK4x3IHXggY1M/YK4dtcrdLagU0hrR9PPLCoyp8A9bgU2enBC9XG/sRx?= =?Windows-1252?Q?F4YH9YllikYYQZYU+jLfPPHhM2UXemzXzOnFni4shqPTpPFGj4p+LAXm?= =?Windows-1252?Q?17hnwX27L5V7Gz5M1hPyh30k17uJQzqO3fziz87ZFxCRqzjkRfx5mItH?= =?Windows-1252?Q?BGkH6HBuLV8RMg6V8bh++R9Uh+W79n8IaZR/MIitSRLqe3MvKQDpTxuH?= =?Windows-1252?Q?gfx992HdOJF3mEpJ9r9rgCMUWYTGgrUypBS6LpONatGpNcwcSvYn8BdF?= =?Windows-1252?Q?I/wZXJZ+z1xUxUB6eUPDx45jCeEQW22zKf2+6s+cGPQPNMKcEaAFRUB9?= =?Windows-1252?Q?9R/AmjJICbz0+2Yx5JOJFvF4RC7SDxB4iGvDora9Or?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB794; 5:O81g0gaDlCIKQTYj8NTrlP37DXB76US0i/7O0OzoYSjsGwCDwaAPOynr8+AJObgrAZcPGAtLu55xKobcHJAG+CKsFJ7mMF8uJwK+B4MNJ8bwMwEQMLbVDrEeeFFFpNHO97O3ARPddH7RkmxvWCgcFg==; 24:yAk50PhnhbPnf+M7a7LbN9rGJrC7eraeo+sny8tMZ1jBTzETVc1IXj1ZDcdxD7Zdjn79kqX9SgiY0mvOyGE6Z5tUG/fhYEnnyPryfIZBtzg=; 7:pzBuP9y5oUCj3pS5N6GFVQRB5eV9HZrlY5VKNNEQg9irGYBrJGSRER6o+fSj/pAvv+DtqED9foEdgdQ7OheOQYL2tNYsAxNyMbG9A2tLG85m4YFF8i5zlUltiYNJ8EjBpcH5F+BIUOQIRvSALr95Aznl53WshP+2mLOQ6ykxQIg= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Apr 2016 20:25:14.8172 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB794 Archived-At: Subject: Re: [secdir] SECDIR review of draft-ietf-bess-pta-flags-02.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 20:25:37 -0000 On 4/25/2016 3:20 PM, Christian Huitema wrote: > Don't routers have to relay these extensions to BGP-adjacent routers? In > that case, are they supposed to blindly relay the extensions that they don't > understand? Are they supposed to reset the corresponding flags to zero, or > just leave them as is? It is probably obvious for you, but these things are > often better said than just implied. Both the "PMSI Tunnel" attribute and the "Additional PMSI Tunnel Attribute Flags" Extended Community are defined to be BGP transitive attributes. This means that any BGP speaker that doesn't understand one of these attributes would just pass it along unchanged. If a BGP speaker understands the attributes, but does not understand some of the flags, it would not be correct for it to reset the flags. The flags might have edge-to-edge (ingress-to-egress or egress-to-ingress) significance, and it might not be necessary for intermediate routers to understand them. I will add a statement saying that, by default, flags that are not understand SHOULD be left unchanged. (Saying "by default" leaves open the possibility that someone might configure a policy to clear certain bits.) There are cases (discussed in RFCs 6514 and 7524) where the PMSI Tunnel attribute is modified as an UPDATE is propagated. I'll add some text pointing out that if the original PMSI Tunnel attribute had the extension flag set, but the modified one does not, then the "Additional PMSI Tunnel Attribute Flags" Extended Community MUST be removed. From nobody Tue Apr 26 05:48:14 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD4B12D1B7; Tue, 26 Apr 2016 05:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rhjo2-kYNwPf; Tue, 26 Apr 2016 05:48:12 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 093B212D1B6; Tue, 26 Apr 2016 05:48:12 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id c126so16507881lfb.2; Tue, 26 Apr 2016 05:48:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to; bh=4j7Fqb5x9Sz91jifcn4FfbxosR8OfyAwrndrpW/n9sI=; b=SiVCANasSg4JKkQhVf5EAxc7reHXEaj+8VXjcM12UzHUrR37kB4jX1Z9p0nUEQ3pmp 4RM2H5ecyGBe7s2e/PStBuQoEGZLPS22Ddna4XwlmpjFlYTlE0kqmVaug5hNeHoZTve+ Ogc/kgiW35YpKyghxjhWCoYysUbtULcxLNwP1GjULq9iBdxV1aCIsEPL0wzAUu1jnuYt 1n/yTeWmxuwqdusdqEuEo1eza3nhaiCJ11PPnOf+ZElaUWbT0lx0c+eAGt0gaWgsmJAt u2GzhJJ+yVFgRiQ61yej094U8wmeD7RfBNZKsoZz1eiPH7W7qD+BMwxEtLUf96Pf5Lc0 dimQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to; bh=4j7Fqb5x9Sz91jifcn4FfbxosR8OfyAwrndrpW/n9sI=; b=j7RDBaBClsP+KcwiEVYmqk5xjzkbjVtlP61IaikF/7pKAWMVq6cgriyQPoTAJ9/+rc fwVcekeFiAel2hNz0u/9wjIC8LANKdyFcwvGe7yOyuPBLifbYZpG3jL/LXMLMUPWsaFg Fm9mIw6r9SDqdKIdhaTUwq9wN/xCmNsscEwvOJEpATU/evl02p+ee/9J6YDgpWSp/gcb 6uocAXTBFq9SWXZF+Z0Z1JMOJpL35t+YwF3P4Jdq0u/sdkPvqjyxiPu8ch0i7yIM22O0 zisnA/J5b1ePnKHKOUlCNKj/kc+EAvo3jLRP5YLbQfct1rRxU/2yk/hGIV1UPfokbkFS NP4g== X-Gm-Message-State: AOPr4FWMme+w5NvG9y0yceUSf5IuhBk8ikIOKsrXC034CRvrljCWAgF37OcsgOu66Wim5MqHkArJ3sqUOTD/mw== MIME-Version: 1.0 X-Received: by 10.112.135.4 with SMTP id po4mr1245075lbb.112.1461674890025; Tue, 26 Apr 2016 05:48:10 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.3.102 with HTTP; Tue, 26 Apr 2016 05:48:09 -0700 (PDT) Date: Tue, 26 Apr 2016 08:48:09 -0400 X-Google-Sender-Auth: kYSLYmBHM62py0cRpcUwahmVtIA Message-ID: From: Phillip Hallam-Baker To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-pals-seamless-vccv.all@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [secdir] SECDIR review of draft-ietf-pals-seamless-vccv-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 12:48:13 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is an incremental change to a layer 2 virtualization layer (Software Defined Networking). As such it properly references RFC5085 for security considerations. That said, I am a bit surprised at the security considerations in RFC5085 which points out that denial of service is an issue but not the introduction of a new set of opportunities for interception. This is surprising given that BGP interception had already been used in international hostilities when the RFC was published. Further the proposed solution is to sprinkle on some magic IPSEC dust or equivalent. While that might be an appropriate approach in an experimental protocol, it is hardly adequate for a production protocol with implications for Internet security as a whole. Given the critical function of this layer and the date of its inception, I would expect to see a comprehensive security architecture developed as part of the overall scheme. From nobody Tue Apr 26 07:18:50 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6F812D1C9; Tue, 26 Apr 2016 07:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d14Rm2IoDtDX; Tue, 26 Apr 2016 07:18:48 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D17D12B065; Tue, 26 Apr 2016 07:18:48 -0700 (PDT) Received: by mail-ob0-x233.google.com with SMTP id tz8so7505743obc.0; Tue, 26 Apr 2016 07:18:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JJwP4aFdI8K46PV4rUt7WwGAlxbZL8Mt9edV54Ugc7c=; b=sKYQ/6zO0h+neJTt0rErd7gCc8P32dJVwXAUri360/6g+7F/UU5FqHAJPL/GpXtBpH 0+9ZI6XCfg49y+j48cLtPIlzQWxhHTZTSq5/WcmD6FDD3RrqOI3TUmaQaaobWCFXeYWD h1ekuj+HD5Km0yvTEBz5myEUKgn2lcroZ5Z20mJpXohFLcfoDC6tsUOSB86jCgQiZoU0 gA4AphoO0f6h9rdhUUiPlgGJ/1ZVrfSQEhtIRvIX2yGJdIcH5VQKqL5Yyl64BmD/QEEk 3aeYho3ZiMBi1+n+1rmBeYtnDnyMkug4vStWx31e0SgnUZhltUk1BtI4A2pLdZ+rOWBY ouFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JJwP4aFdI8K46PV4rUt7WwGAlxbZL8Mt9edV54Ugc7c=; b=ADuF9mH7lkJTyYCIgEZN9W79Iw8nm8bsb48pLi8DISTOcH0lTNi80tUY/vf/I3V2Mk WI40su9Ynppvzezcuqt7fBU22Bccexc1RT9sKHRIfMpQmAlHOUxdkIhxFBQRfGSKgTAX WMbyUvnKMVJZo3o6ykg725sbPfN71Y9Iiuw4DsrJMHdIZ6lQV9IsUWy5r8On9E29zVKc s/jCeel8/SBzg/vLNAEAEEGH8F9SvRjb8mt0i30WD+qgLvUOjIokLkm+OAirdwpPa8OC wTMsnkvKXYzTnc14MJtvhL7W58W61pQfUUkWEUjIUQla2tun1yX4kHxRfjeY2zy0Rho1 3UBQ== X-Gm-Message-State: AOPr4FUw54NIL/Ky5rhu5kiXa8D6p471RADirHCNYYRjQAM+OF1I4cy/M9h6xsFwB/svQfSioCiEyFPaORNJ1w== X-Received: by 10.182.22.137 with SMTP id d9mr1190793obf.83.1461680327752; Tue, 26 Apr 2016 07:18:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.231.106 with HTTP; Tue, 26 Apr 2016 07:18:28 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Tue, 26 Apr 2016 10:18:28 -0400 Message-ID: To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=001a11c2e558b60424053163f8ad Archived-At: Cc: draft-ietf-pals-seamless-vccv.all@ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-pals-seamless-vccv-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 14:18:50 -0000 --001a11c2e558b60424053163f8ad Content-Type: text/plain; charset=UTF-8 Phillip, On behalf of the PALS WG, thanks for your review. To be clear, this sounds like more a comment on RFC 5085 than it does a comment on the draft in question. So is there any action requested regarding the draft? Also, you many not be aware that pseudowires are almost exclusively used in well-managed private enterprise services networks, usually either physically or logically separated from the public Internet for reasons of both traffic management and assurance to enterprise customers that their private traffic is well separated from the Internet. Thus interception is less a threat than it may be for protocols that are used in the public Internet. Thanks, Andy On Tue, Apr 26, 2016 at 8:48 AM, Phillip Hallam-Baker wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > > This document is an incremental change to a layer 2 virtualization > layer (Software Defined Networking). As such it properly references > RFC5085 for security considerations. > > That said, I am a bit surprised at the security considerations in > RFC5085 which points out that denial of service is an issue but not > the introduction of a new set of opportunities for interception. This > is surprising given that BGP interception had already been used in > international hostilities when the RFC was published. > > Further the proposed solution is to sprinkle on some magic IPSEC dust > or equivalent. While that might be an appropriate approach in an > experimental protocol, it is hardly adequate for a production protocol > with implications for Internet security as a whole. > > Given the critical function of this layer and the date of its > inception, I would expect to see a comprehensive security architecture > developed as part of the overall scheme. > --001a11c2e558b60424053163f8ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Phillip,

On behalf of the PALS WG, than= ks for your review.

To be clear, this sounds like mo= re a comment on RFC 5085 than it does a comment on the draft in question. S= o is there any action requested regarding the draft?

Also, you many not be aware that pseudowires are almost exclusively used= in well-managed private enterprise services networks, usually either physi= cally or logically separated from the public Internet for reasons of both t= raffic management and assurance to enterprise customers that their private = traffic is well separated from the Internet. Thus interception is less a th= reat than it may be for protocols that are used in the public Internet.

Thanks,
Andy


On Tue, Apr 26,= 2016 at 8:48 AM, Phillip Hallam-Baker <phill@hallambaker.com><= /span> wrote:
I have reviewed this docume= nt as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.


This document is an incremental change to a layer 2 virtualization
layer (Software Defined Networking). As such it properly references
RFC5085 for security considerations.

That said, I am a bit surprised at the security considerations in
RFC5085 which points out that denial of service is an issue but not
the introduction of a new set of opportunities for interception. This
is surprising given that BGP interception had already been used in
international hostilities when the RFC was published.

Further the proposed solution is to sprinkle on some magic IPSEC dust
or equivalent. While that might be an appropriate approach in an
experimental protocol, it is hardly adequate for a production protocol
with implications for Internet security as a whole.

Given the critical function of this layer and the date of its
inception, I would expect to see a comprehensive security architecture
developed as part of the overall scheme.

--001a11c2e558b60424053163f8ad-- From nobody Tue Apr 26 07:26:48 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B8C12D1D7; Tue, 26 Apr 2016 07:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53CClAQ6LK61; Tue, 26 Apr 2016 07:26:42 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7226712D1D4; Tue, 26 Apr 2016 07:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4334; q=dns/txt; s=iport; t=1461680802; x=1462890402; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FLibItUMerfTnsYLmZV8dDYqQq4oGnpJSCygrXxB1yA=; b=Wu+lDc3mmuz0Ta9B33qoT/3CAg4vXIo2Z+v2OQwvh7ylCegk/44fOq7N loAVd3/Ulti3w/csH03/zaexwcTtVpuZ7Lc4gfYjb0W5i4qCQ/hPXbGcF DdOsFRKbp8tSj+ac7A+9AdDh+ywnr8shuXSc5QGid1LGQGr9DGLJr628C 0=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DQAgCbeR9X/5FdJa1egziBUAa3Z4IPD?= =?us-ascii?q?oF0gl6DMAKBNjgUAQEBAQEBAWUnhEEBAQEDASNWBQsCAQgSBioCAjIXDgIEDgU?= =?us-ascii?q?ODYgHCLJqkTUBAQEBAQEBAQEBAQEBAQEBAQEBAQ4IhiGBdYJWhz8rgisFkx+Ec?= =?us-ascii?q?QGDJ4FniQiBZ4RNiF2PLwEeAUOCBRuBS2yIAX8BAQE?= X-IronPort-AV: E=Sophos;i="5.24,536,1454976000"; d="asc'?scan'208";a="265600419" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Apr 2016 14:26:41 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u3QEQf5Y025952 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Apr 2016 14:26:41 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 26 Apr 2016 10:26:40 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Tue, 26 Apr 2016 10:26:40 -0400 From: "Carlos Pignataro (cpignata)" To: Phillip Hallam-Baker Thread-Topic: SECDIR review of draft-ietf-pals-seamless-vccv-02 Thread-Index: AQHRn7noe7HtbKiJG0u+NZfEBeLzNZ+ckuUA Date: Tue, 26 Apr 2016 14:26:40 +0000 Message-ID: <01160F37-0C73-42CE-AA8C-A09F876080A8@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.115.58] Content-Type: multipart/signed; boundary="Apple-Mail=_5D68EDFC-7C68-4A45-8454-FEE22B9374BA"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-pals-seamless-vccv.all@ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-pals-seamless-vccv-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 14:26:44 -0000 --Apple-Mail=_5D68EDFC-7C68-4A45-8454-FEE22B9374BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Phillip, Many thanks for your review. As you rightly call out, this is indeed an incremental addition =E2=80=94 = I might add for emphasis a very incremental change. One point of clarification, however, is that this solution as defined = does _not_ use BGP. The relevant control protocols=E2=80=99 security = considerations are addressed in RFC 5085. This is not 'IPsec pixy-dust' = =E2=80=94 if you follow the pointers, you will get to the control = connection (endpoint and message) security as well as protection for = data plane spoofing. In re-reading the Security Considerations section (thanks again for the = review), I do believe there is an area of improvement: from RFC 5885, = since these PWs specify single-hop adjacencies, the document ought to = specify the use of GTSM for the IP/UDP encapsulations. I=E2=80=99ll be happy to add that in. Please let me know if you have any = concerns with it. Phillip, Andy, Stewart, Lastly, Phillip, you are suggesting or recommending the development of a = comprehensive security architecture (scoped for L2VPNs? or PWs? or = VCCV?). Since that is clearly beyond the scope of this (incremental) = doc, I=E2=80=99ll let Andy and Stewart (PALS chairs) answer that one. My personal opinion as individual participant is that all the different = security considerations for each architectural building block and = modules (control planes, data plane, attacks, etc) are in place =E2=80=94 = perhaps not in a single document, but throughout. Thanks! =E2=80=94 Carlos. > On Apr 26, 2016, at 8:48 AM, Phillip Hallam-Baker = wrote: >=20 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 >=20 > This document is an incremental change to a layer 2 virtualization > layer (Software Defined Networking). As such it properly references > RFC5085 for security considerations. >=20 > That said, I am a bit surprised at the security considerations in > RFC5085 which points out that denial of service is an issue but not > the introduction of a new set of opportunities for interception. This > is surprising given that BGP interception had already been used in > international hostilities when the RFC was published. >=20 > Further the proposed solution is to sprinkle on some magic IPSEC dust > or equivalent. While that might be an appropriate approach in an > experimental protocol, it is hardly adequate for a production protocol > with implications for Internet security as a whole. >=20 > Given the critical function of this layer and the date of its > inception, I would expect to see a comprehensive security architecture > developed as part of the overall scheme. --Apple-Mail=_5D68EDFC-7C68-4A45-8454-FEE22B9374BA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXH3qfAAoJEIXgpQGOZny9ITUP/i49rfun5vJkz6mKocnx78pp AMc69Kzly/Ejvztdwow+iCWjcnHVSdjlBqpjZ7napj8VztdvtZ+6Apm9O6V17/Z/ lhFzbG5QrT4ThQO23APvvlbffy5dXVwHc9zjhsJ98hLmZgcBjSY5bu29Q0qI3Fq9 Lz4cHI/uReo8NLZTuFEaoqNUzNVZSTITp9u3LtdIS3drEjyYS6NVRR3rjY6MVTJ7 pIFvU4bLdtdB+tXU3fytWBAJmahrQiLgAJGx5ynBprQSeYz85GXhk3lbS6GTJPEd bgUdHTrG3/6hPMYoNk+UEb91rIUvG24OjUCtf2NGVuMzlPSY9cowQ4AFeMZdUqWO 2vbo5jLpjwIqDHt3ZsJnJJ0yYQVy3djo5tPuzdYOaFqaf4ZoeTbv/2aKoz9yNzhb VpKobKIL0KdP7drN5g63Es1ayrBrRUtBUfEo4qmC/x/ebJ0MHUjUuFXlJNqqzFMt Obr35ejL9mHeLlo8yQg7Ywrujjo9d9j4HDGaQPJLFGffHsQY5b+Rsv2ISJ11dLKl qfe+RBBlP67IV6YPV4uQ0t8tGrc/MzezsqeJWvYRGtUdpq9kZeB5auchxLDx4iuM 2Poiy32bv40TTuK7Y5PEUatPPosLbvzGdWjSRX2L3f+FWftmTRoJuKqUDdm39VjQ P84n0vvKQIy/FMI2He8h =0I7Y -----END PGP SIGNATURE----- --Apple-Mail=_5D68EDFC-7C68-4A45-8454-FEE22B9374BA-- From nobody Tue Apr 26 07:51:35 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7135B12D14C; Tue, 26 Apr 2016 07:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWo85FY5kLpF; Tue, 26 Apr 2016 07:51:28 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17DBF12B00C; Tue, 26 Apr 2016 07:51:27 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id u64so18884935lff.3; Tue, 26 Apr 2016 07:51:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=35cZv8VtD4qXvf8d7Rqc7crbMkA5W93dmhGCoBFcG/Y=; b=wuBDv3w75aMb5gVAeqCxU3Daf3MiWTI/+ja9aG2TIGm/FJi8SJRUYMc7BN7k/Fn2Td KaNssfHH46ithnbTNM3F4LI+QzWVzcsDspU5lYr72htX06O9m9pqeLjlPwdtCiDmfRQg 2+7a3jmWavSTvEIKKqlLun6qGwARq41ZQ7SWr/sMQS+QPq0pyLp21HKzRJxZZ+ayZXcV izC/nGzxXJazSdp+6FJg4ks+q1ix/+I3d/8ETqN/rsrjZ6/pwIgDY4qr+y9SIqSGsetj Nrf9cMVp1YDvt2EWO9jrEdKZAKeW2ut4yxVcsxnAPvsOpmlNN8hJob1N/PXLoC61b5sO yUVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=35cZv8VtD4qXvf8d7Rqc7crbMkA5W93dmhGCoBFcG/Y=; b=QW8m9quwWZy81lHFswLMq/Qmz57BPYLxFp1dqgJqK7Xi4Xq3+LwGV+jGihJJH4qTdt Piq0fDOjxJwHJUh8JJ6MhHwUtXb0eHhYBv3y4veBVYe75+xIQGS065t+A+fRomtNlVhV pyeQVkWi/C8f5Z3j6r+Nl92EWkHORBUD3++xOGzv4EJg8CBoRO2SD7bjgAOSFGyDTc/9 kRm+icNiOx2SzUqdOBZbUF9DPKrG7QBo2W5+52x5cMX76Z58V9KaYboopHkTNWd2mlIK AgLDaKDzZmBn0JfkGfblVl3KPXyEEzDn3JneOZoNhgcGvCXP+0aFtUZU3uY8Nu97rBEB qFGA== X-Gm-Message-State: AOPr4FVWYxeM9zNWFeWywXU8+P44W3g/fQHmLDqdNdbevf0XG2+gLKbXITKLtmdwWWTodjO2DyGbLhhy2t6ZSg== MIME-Version: 1.0 X-Received: by 10.112.161.41 with SMTP id xp9mr1467674lbb.133.1461682285051; Tue, 26 Apr 2016 07:51:25 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.3.102 with HTTP; Tue, 26 Apr 2016 07:51:24 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Apr 2016 10:51:24 -0400 X-Google-Sender-Auth: vKER1EHGJWeJ596HYUR0pihMPGM Message-ID: From: Phillip Hallam-Baker To: "Andrew G. Malis" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-pals-seamless-vccv.all@ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-pals-seamless-vccv-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 14:51:29 -0000 Yes, I think that what is needed is IAB review of what is going on rather than action on this particular draft. In particular, I don't consider a protocol suitable to be considered an IETF standard unless people can buy devices from multiple vendors and configure them to work together securely. The security approach outlined in 5085 is mix and match with a large dose of handwaving. It desperately needs to be reconsidered and a security architecture written up. I don't think that you can expect interoperability on the basis of that description. The Snowden documents demonstrate that 'well managed enterprise networks' are attacked on a daily basis and that this is the basis for mass surveillance. I do not consider IPSEC to be a suitable security mechanism for this type of system. If I was given the design brief, I would insist that every message be authenticated by digital signature rather than a MAC and the control messages logged. I might use a MAC for pre-authentication to prevent DoS attack on the control plane. But the control messages should be fixed in non repudiable fashion. That is the only way I could be confident that PRISM class attack against the network had not been performed. On Tue, Apr 26, 2016 at 10:18 AM, Andrew G. Malis wrote: > Phillip, > > On behalf of the PALS WG, thanks for your review. > > To be clear, this sounds like more a comment on RFC 5085 than it does a > comment on the draft in question. So is there any action requested regarding > the draft? > > Also, you many not be aware that pseudowires are almost exclusively used in > well-managed private enterprise services networks, usually either physically > or logically separated from the public Internet for reasons of both traffic > management and assurance to enterprise customers that their private traffic > is well separated from the Internet. Thus interception is less a threat than > it may be for protocols that are used in the public Internet. > > Thanks, > Andy > > > On Tue, Apr 26, 2016 at 8:48 AM, Phillip Hallam-Baker > wrote: >> >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors. Document editors and WG chairs should treat >> these comments just like any other last call comments. >> >> >> This document is an incremental change to a layer 2 virtualization >> layer (Software Defined Networking). As such it properly references >> RFC5085 for security considerations. >> >> That said, I am a bit surprised at the security considerations in >> RFC5085 which points out that denial of service is an issue but not >> the introduction of a new set of opportunities for interception. This >> is surprising given that BGP interception had already been used in >> international hostilities when the RFC was published. >> >> Further the proposed solution is to sprinkle on some magic IPSEC dust >> or equivalent. While that might be an appropriate approach in an >> experimental protocol, it is hardly adequate for a production protocol >> with implications for Internet security as a whole. >> >> Given the critical function of this layer and the date of its >> inception, I would expect to see a comprehensive security architecture >> developed as part of the overall scheme. > > From nobody Tue Apr 26 07:57:26 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE2FE12B00C; Tue, 26 Apr 2016 07:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPyBRGEFuuKZ; Tue, 26 Apr 2016 07:57:23 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD26312D17B; Tue, 26 Apr 2016 07:57:22 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id u64so19091890lff.3; Tue, 26 Apr 2016 07:57:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-transfer-encoding; bh=SoxphWmurFxh98w87nRPXWijtCCHai6pzmXMOaEWBVE=; b=A7gpbLFyrCydTqvVSc2AIxOW0RDBwaVitMttZNuCaUZlwXIukZhPHZW/201K2vfBAv xwFFWWhLZ7MURLGNbn67MguIjRt8HwmRqo6ymc8grNaWHKHx5ywH5RdBAnn8oD+p8Efg ssR6HYzaNjAWqcmdlgLSWgQLnD/6habdOw75tVW8rxjEw9lRiP5qgrlDHnH/s7KTER5n DKQ9Ebt+y/+acK5f89RiH5CnRRBYT5iNlDjRYApZSwEiU/c5H5r8UtilWGTE5byRYsAr +Ctlkny4fUlHdocZI1EimffYWHISNPhWZTUOmjV8vPRS8wtOGhjqSNzTMpYMfmhVDo/j kN5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=SoxphWmurFxh98w87nRPXWijtCCHai6pzmXMOaEWBVE=; b=Ph5BIZL4cUpbmP9DUV+RXdMMhE1yrF49AyAteYUMFH5p6on7PQ1z42qX8lBHSCVaqF GcAHvjCdDBq8fldb/WBCqe8Nr5bgjPUHgvvb+3QSLCQsHnGhxg4w/osgMxs7sVl9xY8D h+vqZUn2TMxb02gdJDjedm3ZVm2R4IJeCg4ueVRN9/cwIZCkIbhp67PPnrpldeaNb7+X yqhUxMxVhbFJmuS3EiTj3/OJxiEN5ZTEmceDhBbbhuWc3S0rt14491Fc7gZbjsYnNorA 2FfyqbnUqHDWjk/7pG4HjHv24KrZmM5XDncrQKFYN69UGhoXZvYXS6IBUeEhf6d1hKhW +v+A== X-Gm-Message-State: AOPr4FV7FsjgGQWlGxZv0tz2tDNlp05+cGlUWFYOMMMVzqd+gTrzyg+xxW2tlL8Xtp45kSH41XLe/fLqplGU/Q== MIME-Version: 1.0 X-Received: by 10.25.83.10 with SMTP id h10mr1277140lfb.39.1461682641115; Tue, 26 Apr 2016 07:57:21 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.3.102 with HTTP; Tue, 26 Apr 2016 07:57:21 -0700 (PDT) In-Reply-To: <01160F37-0C73-42CE-AA8C-A09F876080A8@cisco.com> References: <01160F37-0C73-42CE-AA8C-A09F876080A8@cisco.com> Date: Tue, 26 Apr 2016 10:57:21 -0400 X-Google-Sender-Auth: UY_1pUfQ-z9fEAwIJntqteKRQ3M Message-ID: From: Phillip Hallam-Baker To: "Carlos Pignataro (cpignata)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "draft-ietf-pals-seamless-vccv.all@ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-pals-seamless-vccv-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 14:57:25 -0000 On Tue, Apr 26, 2016 at 10:26 AM, Carlos Pignataro (cpignata) wrote: > Phillip, > > Many thanks for your review. > > As you rightly call out, this is indeed an incremental addition =E2=80=94= I might add for emphasis a very incremental change. > > One point of clarification, however, is that this solution as defined doe= s _not_ use BGP. The relevant control protocols=E2=80=99 security considera= tions are addressed in RFC 5085. This is not 'IPsec pixy-dust' =E2=80=94 if= you follow the pointers, you will get to the control connection (endpoint = and message) security as well as protection for data plane spoofing. With respect, I disagree. A collection of pointers to a dozen other documents is not a security architecture. I am aware that this is not BGP which is a layer 3 switching protocol. This is layer 2 but the same security concerns apply. The fact that we have seen nation state actors use BGP injection attacks as tools of war demonstrate that this is a real concern. > In re-reading the Security Considerations section (thanks again for the r= eview), I do believe there is an area of improvement: from RFC 5885, since = these PWs specify single-hop adjacencies, the document ought to specify the= use of GTSM for the IP/UDP encapsulations. > > I=E2=80=99ll be happy to add that in. Please let me know if you have any = concerns with it. For an infrastructure of this scale, the security architecture should really be described in a separate document and at length. From nobody Tue Apr 26 10:10:43 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D1612D54D for ; Tue, 26 Apr 2016 10:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVYg__6PR4vR for ; Tue, 26 Apr 2016 10:10:39 -0700 (PDT) Received: from xsmtp06.mail2web.com (xsmtp06.mail2web.com [168.144.250.232]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB52512D530 for ; Tue, 26 Apr 2016 10:10:39 -0700 (PDT) Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1av6Ux-0007KW-4s for secdir@ietf.org; Tue, 26 Apr 2016 13:10:38 -0400 Received: (qmail 5786 invoked from network); 26 Apr 2016 17:10:05 -0000 Received: from unknown (HELO huitema2) (Authenticated-user:_huitema@huitema.net@[131.107.147.60]) (envelope-sender ) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 26 Apr 2016 17:10:04 -0000 From: "Christian Huitema" To: "'Eric C Rosen'" , , , References: <033501d19e81$1697ec40$43c7c4c0$@huitema.net> <045801d19f27$818c46d0$84a4d470$@huitema.net> <45cc2319-d1c9-976a-ece1-0697a623e21c@juniper.net> In-Reply-To: <45cc2319-d1c9-976a-ece1-0697a623e21c@juniper.net> Date: Tue, 26 Apr 2016 10:10:03 -0700 Message-ID: <00cc01d19fde$7a1de270$6e59a750$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJ4tIhog5CnxYH6q0cOrVpsm7GB3QHgxMhnAejMR8oB1gh11Z4hVtFg Content-Language: en-us Archived-At: Subject: Re: [secdir] SECDIR review of draft-ietf-bess-pta-flags-02.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 17:10:41 -0000 On Monday, April 25, 2016 1:25 PM, Eric C Rosen wrote: > > On 4/25/2016 3:20 PM, Christian Huitema wrote: > > Don't routers have to relay these extensions to BGP-adjacent routers? > > In that case, are they supposed to blindly relay the extensions that > > they don't understand? Are they supposed to reset the corresponding > > flags to zero, or just leave them as is? It is probably obvious for > > you, but these things are often better said than just implied. > > Both the "PMSI Tunnel" attribute and the "Additional PMSI Tunnel Attribute > Flags" Extended Community are defined to be BGP transitive attributes. This > means that any BGP speaker that doesn't understand one of these attributes > would just pass it along unchanged. > > If a BGP speaker understands the attributes, but does not understand some of > the flags, it would not be correct for it to reset the flags. > The flags might have edge-to-edge (ingress-to-egress or > egress-to-ingress) significance, and it might not be necessary for intermediate > routers to understand them. I will add a statement saying that, by default, > flags that are not understand SHOULD be left unchanged. (Saying "by default" > leaves open the possibility that someone might configure a policy to clear > certain bits.) > > There are cases (discussed in RFCs 6514 and 7524) where the PMSI Tunnel > attribute is modified as an UPDATE is propagated. I'll add some text pointing > out that if the original PMSI Tunnel attribute had the extension flag set, but the > modified one does not, then the "Additional PMSI Tunnel Attribute Flags" > Extended Community MUST be removed. Works for me, thanks. -- Christian Huitema From nobody Tue Apr 26 13:06:49 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A1912D56C; Tue, 26 Apr 2016 13:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWeo76_jIKQ7; Tue, 26 Apr 2016 13:06:42 -0700 (PDT) Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [IPv6:2001:480:20:118:118::211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A5F412D0BA; Tue, 26 Apr 2016 13:06:42 -0700 (PDT) Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id u3QK64b7019492 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 26 Apr 2016 16:06:04 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_70758162-5CEB-481D-852B-6AC37FDAE20A" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Catherine Meadows In-Reply-To: <5719D3FA.4070402@gredler.at> Date: Tue, 26 Apr 2016 16:06:04 -0400 Message-Id: <7609B084-63E4-4341-912B-2083E88F6CB8@nrl.navy.mil> References: <5719D3FA.4070402@gredler.at> To: Hannes Gredler X-Mailer: Apple Mail (2.3124) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email Archived-At: Cc: draft-ietf-isis-node-admin-tag.all@ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] sectdir review of draft-ietf-isis-node-admin-tag-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 20:06:46 -0000 --Apple-Mail=_70758162-5CEB-481D-852B-6AC37FDAE20A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hannes: My apologies, I could have been a little more clear. The security considerations section begins with a security = consideration: =20 Node administrative tags may be used by operators to indicate geographical location or other sensitive information. The information carried in node administrative tags could be leaked to an IGP snooper. This doesn=E2=80=99t come with a citation of any other document, so I = assumed it was =E2=80=9Cnew=E2=80=9D, and was confused when the next sentence said the document does not introduce any new security = concerns. If this security consideration also applies to=20 RFC5130 and RFC5305, you could cite those (although they do not address = this particular issue in their security concerns section it would still show that you are not introducing any = new security concerns). Cathy=20 Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil = > On Apr 22, 2016, at 3:34 AM, Hannes Gredler wrote: >=20 > catherine, >=20 > i fail to see how this does introduce *new* security concerns. >=20 > background: >=20 > we have in IS-IS two existing tagging mechanism's: >=20 > 1) admin-groups for links > https://tools.ietf.org/html/rfc5305#section-3.1 >=20 > 2) prefix-tags for prefixes > https://tools.ietf.org/html/rfc5130#section-3.1 >=20 > both "tagging-spaces" are local administered and have > no global significance. >=20 > the purpose of draft-ietf-isis-node-admin-tag-08 is to > add support for a third tagging method which allows tagging > of an entire node using local administered tagging space. > (same operational spirit as in 1) and 2) ) >=20 > now my question(s): >=20 > - why is adding of an local-administered tag with no implied > semantics considered to be security relevant ? >=20 > - what specific (apparently mis-)wording in > draft-ietf-isis-node-admin-tag makes you think > it is security relevant ? >=20 > /hannes >=20 > On 4/21/16 19:36, Catherine Meadows 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. >>=20 >> This draft describes an extension to the IS-IS routing protocol, that >> allows tagging and grouping of nodes >> in an IS-IS domain. This makes it possible to increase the = efficiency >> of route and path selection, since the tags >> give information about a router=E2=80=99s capabilities. >>=20 >> The Security Considerations section correctly identifies one of the = main >> security risks of using such tags: they may leak >> sensitive information about, e.g., geographical location. However, = I=E2=80=99m >> confused by the statement following that: >>=20 >> =E2=80=9CThis document does not introduce any new security concerns. = Security >> concerns for IS-IS are already addressed in >> [ISO10589], [RFC5304], and [RFC5310] are are applicable to the >> mechanisms described in this document.=E2=80=9D >>=20 >> As far as I can tell, this document *does* introduce new security >> concerns, because the tags may reveal sensitive >> information that may not have been made available otherwise. = Moreover, >> RFCs 5304 and 5310 concern authentication, not >> secrecy, and so do not address information leakage at all. My own >> suggestion >> for a recommendation would be that implementors should weigh the >> benefits of putting certain kinds of information on tags >> versus the risk of its being used by an attacker, and make their >> decisions accordingly. This would not be a SHOULD a MUST >> recommendation by the way, but simply advisory. >>=20 >> I=E2=80=99m not sure what is meant by the last sentence in this = paragraph: >>=20 >> Extended authentication mechanisms described in [RFC5304] or = [RFC5310] >> SHOULD be used in >> deployments where attackers have access to the physical networks = and >> nodes included in the IS-IS domain are vulnerable. >>=20 >> Is this addressing the problem of sensitive information on tags? If = so, >> you need to say how. If it is addressing >> spoofing of tags, it should be given its own paragraph, and the = threat >> you are talking about should be made clear. >>=20 >> In the last paragraph, on the misattribution of tags from different >> domains, what would you recommend for mitigating against >> this problem? Also, since this is in the security considerations >> section, you should say something about how an attacker >> could take advantage of it. >>=20 >> In my opinion, the Security Considerations section needs a major >> revision. However, >> I consider this document Almost Ready, because the purpose of the >> revision would be mainly to make the section more clear, not to = address >> any overlooked security problems. >>=20 >>=20 >>=20 >>=20 >> Catherine Meadows >> Naval Research Laboratory >> Code 5543 >> 4555 Overlook Ave., S.W. >> Washington DC, 20375 >> phone: 202-767-3490 >> fax: 202-404-7942 >> email: catherine.meadows@nrl.navy.mil >> >>=20 --Apple-Mail=_70758162-5CEB-481D-852B-6AC37FDAE20A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hannes:

My = apologies, I could have been a little more clear.
The security considerations section = begins with a security consideration:

 
Node = administrative tags may be used by operators to indicate
   geographical location or other sensitive = information.  The
   information = carried in node administrative tags could be leaked to an
   IGP snooper.

This doesn=E2=80=99t come with a = citation of any other document, so I assumed it was =E2=80=9Cnew=E2=80=9D,= and was confused when the
next sentence said the = document does not introduce any new security concerns.   If this = security consideration also applies to 
RFC5130 = and RFC5305, you could cite those (although they do not address this = particular issue in their security
concerns section = it would still show that you are not introducing any new security = concerns).


Cathy 




Catherine Meadows
Naval Research = Laboratory
Code 5543
4555 Overlook Ave., = S.W.
Washington DC, 20375
phone: = 202-767-3490
fax: 202-404-7942
email: catherine.meadows@nrl.navy.mil

On Apr 22, 2016, at 3:34 AM, Hannes Gredler <hannes@gredler.at> = wrote:

catherine,

i fail to see how = this does introduce *new* security concerns.

background:

we have in IS-IS two = existing tagging mechanism's:

1) = admin-groups for links
  https://tools.ietf.org/html/rfc5305#section-3.1

2) prefix-tags for prefixes
=   https://tools.ietf.org/html/rfc5130#section-3.1

both "tagging-spaces" are local administered = and have
no global significance.

the purpose of draft-ietf-isis-node-admin-tag-08 is to
add support for a third tagging method which allows = tagging
of an entire node using local administered tagging = space.
(same operational spirit as in 1) and 2) )

now my question(s):

- why is adding of an local-administered tag with no = implied
 semantics considered to be security = relevant ?

- what specific (apparently = mis-)wording in
 draft-ietf-isis-node-admin-tag = makes you think
 it is security relevant ?

/hannes

On = 4/21/16 19:36, Catherine Meadows wrote:
I have reviewed this document as part of the = security directorate's
ongoing effort to review all
IETF documents being processed by the IESG.  These = comments were written
primarily for the
benefit of the security area directors.  Document = editors and WG chairs
should treat these comments
just like any other last call comments.

This draft describes an extension to the IS-IS routing = protocol, that
allows tagging and grouping of nodes
in an IS-IS domain.  This makes it possible to increase = the efficiency
of route and path selection, since the = tags
give information about a router=E2=80=99s = capabilities.

The Security Considerations = section correctly identifies one of the main
security = risks of using such tags:  they may leak
sensitive = information about, e.g., geographical location.   However, = I=E2=80=99m
confused by the statement following that:

=E2=80=9CThis document does not introduce any = new security concerns.  Security
concerns for IS-IS = are already addressed in
[ISO10589], [RFC5304], and = [RFC5310] are are applicable to the
mechanisms described = in this document.=E2=80=9D

As far as I can = tell, this document *does* introduce new security
concerns, = because the tags may reveal sensitive
information that may = not have been made available otherwise.  Moreover,
RFCs= 5304 and 5310 concern authentication, not
secrecy, and so = do not address information leakage at all.  My own
suggestion
for a recommendation would be that = implementors should weigh the
benefits of putting certain = kinds of information on tags
versus the risk of its being = used by an attacker, and make their
decisions accordingly. =  This would not be a SHOULD a MUST
recommendation by = the way, but simply advisory.

I=E2=80=99m = not sure what is meant by the last sentence in this paragraph:

 Extended authentication mechanisms = described in [RFC5304] or [RFC5310]
SHOULD be used in
   deployments where attackers have access to = the physical networks and
   nodes = included in the IS-IS domain are vulnerable.

Is this addressing the problem of sensitive information on = tags?  If so,
you need to say how.   If it = is addressing
spoofing of tags, it should be given its own = paragraph, and the threat
you are talking about should be = made clear.

In the last paragraph, on the = misattribution of tags from different
domains, what would = you recommend for mitigating against
this problem? =  Also, since this is in the security considerations
section, you should say something about how an attacker
could take advantage of it.

In = my opinion, the Security Considerations section needs a major
revision.  However,
I consider this = document Almost Ready, because the purpose of the
revision = would be mainly to make the section more clear, not to address
any overlooked security problems.




Catherine = Meadows
Naval Research Laboratory
Code = 5543
4555 Overlook Ave., S.W.
Washington DC, = 20375
phone: 202-767-3490
fax: = 202-404-7942
email: catherine.meadows@nrl.navy.mil
<mailto:catherine.meadows@nrl.navy.mil>

= --Apple-Mail=_70758162-5CEB-481D-852B-6AC37FDAE20A-- From nobody Tue Apr 26 14:27:49 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E6E120727; Tue, 26 Apr 2016 14:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cxTS5zO-m1y; Tue, 26 Apr 2016 14:27:46 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF4E512D0F2; Tue, 26 Apr 2016 14:27:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13566; q=dns/txt; s=iport; t=1461706065; x=1462915665; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Z8F1+sJZgHBRD4lNUdhG8v05rZUAW+WXQDHS4oPre+g=; b=ezCxpVfc51TOFGx9qhvnv2cH6qczlQlP5FocB8LQLigefMH/XRFTVC4D vxtWFETBe6NlD+rL+LCjKQIa8FfD71/vJfpo4Y7PPh2Gm+KsheaL2Pi7N PNZ5yQOhmj6Arnsq4L/v6BXYSQ9JOq2zbY8tjvlUXeMSPvJn3EV3j5OlI k=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DvAgBI3B9X/5RdJa1egzhTfQauG4Zqg?= =?us-ascii?q?mSCDw6BdB6CQIMxAoFAOBQBAQEBAQEBZSeEQQEBAQMBI1YFCwIBCBIGKgICIRE?= =?us-ascii?q?XDgIEDgUODYd6AwoIDrM4jCINhGEBAQEBAQEBAQEBAQEBAQEBAQEBAQENBASGI?= =?us-ascii?q?YF1CIJOgkGCK4JTK4IrBZMfhEAxAYMngWdthiWBdo8Rh1GHXgEeAUOCBRuBS2y?= =?us-ascii?q?IL38BAQE?= X-IronPort-AV: E=Sophos;i="5.24,538,1454976000"; d="asc'?scan'208,217";a="101611183" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Apr 2016 21:27:43 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u3QLRh6J002162 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Apr 2016 21:27:43 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 26 Apr 2016 17:27:42 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Tue, 26 Apr 2016 17:27:42 -0400 From: "Carlos Pignataro (cpignata)" To: Phillip Hallam-Baker Thread-Topic: SECDIR review of draft-ietf-pals-seamless-vccv-02 Thread-Index: AQHRn7noe7HtbKiJG0u+NZfEBeLzNZ+ckJsAgAAJNACAAG64gA== Date: Tue, 26 Apr 2016 21:27:42 +0000 Message-ID: <274768D8-88B0-4290-AEFF-463C3AD02CF6@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.182.239] Content-Type: multipart/signed; boundary="Apple-Mail=_A1969861-7133-4F2F-8FA2-62DE500FF49F"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-pals-seamless-vccv.all@ietf.org" , "Andrew G. Malis" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-pals-seamless-vccv-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 21:27:48 -0000 --Apple-Mail=_A1969861-7133-4F2F-8FA2-62DE500FF49F Content-Type: multipart/alternative; boundary="Apple-Mail=_949C6DE8-0432-44A9-9FE3-3E36A3FEEFC6" --Apple-Mail=_949C6DE8-0432-44A9-9FE3-3E36A3FEEFC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Phillip, > rather than action on this particular draft. OK. Thanks. > On Apr 26, 2016, at 10:51 AM, Phillip Hallam-Baker = wrote: >=20 > Yes, I think that what is needed is IAB review of what is going on > rather than action on this particular draft. >=20 > In particular, I don't consider a protocol suitable to be considered > an IETF standard unless people can buy devices from multiple vendors > and configure them to work together securely. >=20 > The security approach outlined in 5085 is mix and match with a large > dose of handwaving. It desperately needs to be reconsidered and a > security architecture written up. To add further context, RFC 5085 describes, at a high level, OAM for = PWs. To understand your point, do you mean there=E2=80=99s a need for a = security architecture for OAM for PWs? Some of your comments are generic = (see below for an example), and somewhat hard for me to parse if you = mean the infrastructure itself, the PWs, the L2VPNs, the OAM on top, or = something else. > I don't think that you can expect > interoperability on the basis of that description. >=20 https://tools.ietf.org/html/rfc7079 = (I=E2=80=99ve not contributed to that RFC, but seems to imply the only = interop hiccup has been the optional CW with Ethernet PWs, not OAM) > The Snowden documents demonstrate that 'well managed enterprise > networks' are attacked on a daily basis and that this is the basis for > mass surveillance. >=20 > I do not consider IPSEC to be a suitable security mechanism for this > type of system. If I was given the design brief, I would insist that > every message be authenticated by digital signature rather than a MAC > and the control messages logged. I might use a MAC for > pre-authentication to prevent DoS attack on the control plane. But the > control messages should be fixed in non repudiable fashion. >=20 > That is the only way I could be confident that PRISM class attack > against the network had not been performed. >=20 This exemplifies my earlier point: =E2=80=9Cagainst the network=E2=80=9D = seems quite generic. You have control message exchange without RFC 5085 = and without this draft. Thanks! =E2=80=94 Carlos. >=20 > On Tue, Apr 26, 2016 at 10:18 AM, Andrew G. Malis = wrote: >> Phillip, >>=20 >> On behalf of the PALS WG, thanks for your review. >>=20 >> To be clear, this sounds like more a comment on RFC 5085 than it does = a >> comment on the draft in question. So is there any action requested = regarding >> the draft? >>=20 >> Also, you many not be aware that pseudowires are almost exclusively = used in >> well-managed private enterprise services networks, usually either = physically >> or logically separated from the public Internet for reasons of both = traffic >> management and assurance to enterprise customers that their private = traffic >> is well separated from the Internet. Thus interception is less a = threat than >> it may be for protocols that are used in the public Internet. >>=20 >> Thanks, >> Andy >>=20 >>=20 >> On Tue, Apr 26, 2016 at 8:48 AM, Phillip Hallam-Baker >> wrote: >>>=20 >>> I have reviewed this document as part of the security directorate's >>> ongoing effort to review all IETF documents being processed by the >>> IESG. These comments were written primarily for the benefit of the >>> security area directors. Document editors and WG chairs should treat >>> these comments just like any other last call comments. >>>=20 >>>=20 >>> This document is an incremental change to a layer 2 virtualization >>> layer (Software Defined Networking). As such it properly references >>> RFC5085 for security considerations. >>>=20 >>> That said, I am a bit surprised at the security considerations in >>> RFC5085 which points out that denial of service is an issue but not >>> the introduction of a new set of opportunities for interception. = This >>> is surprising given that BGP interception had already been used in >>> international hostilities when the RFC was published. >>>=20 >>> Further the proposed solution is to sprinkle on some magic IPSEC = dust >>> or equivalent. While that might be an appropriate approach in an >>> experimental protocol, it is hardly adequate for a production = protocol >>> with implications for Internet security as a whole. >>>=20 >>> Given the critical function of this layer and the date of its >>> inception, I would expect to see a comprehensive security = architecture >>> developed as part of the overall scheme. >>=20 >>=20 --Apple-Mail=_949C6DE8-0432-44A9-9FE3-3E36A3FEEFC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Phillip,

rather than action on = this particular draft.

OK. Thanks.

On = Apr 26, 2016, at 10:51 AM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:

Yes, = I think that what is needed is IAB review of what is going on
rather than action on this particular draft.

In particular, I don't consider a protocol suitable to be = considered
an IETF standard unless people can buy devices = from multiple vendors
and configure them to work together = securely.

The security approach outlined in = 5085 is mix and match with a large
dose of handwaving. It = desperately needs to be reconsidered and a
security = architecture written up.

To add further context, RFC 5085 describes, at a high = level, OAM for PWs. To understand your point, do you mean there=E2=80=99s = a need for a security architecture for OAM for PWs? Some of your = comments are generic (see below for an example), and somewhat hard for = me to parse if you mean the infrastructure itself, the PWs, the L2VPNs, = the OAM on top, or something else.

 I don't think that you can expect
interoperability on the basis of that description.



(I=E2=80=99ve not contributed to that RFC, but = seems to imply the only interop hiccup has been the optional CW with = Ethernet PWs, not OAM)

The Snowden documents = demonstrate that 'well managed enterprise
networks' are = attacked on a daily basis and that this is the basis for
mass surveillance.

I do not = consider IPSEC to be a suitable security mechanism for this
type of system. If I was given the design brief, I would = insist that
every message be authenticated by digital = signature rather than a MAC
and the control messages = logged. I might use a MAC for
pre-authentication to = prevent DoS attack on the control plane. But the
control = messages should be fixed in non repudiable fashion.

That is the only way I could be confident that PRISM class = attack
against the network had not been performed.


This exemplifies my earlier point: = =E2=80=9Cagainst the network=E2=80=9D seems quite generic. You have = control message exchange without RFC 5085 and without this = draft.

Thanks!

=E2=80=94 Carlos.


On Tue, Apr = 26, 2016 at 10:18 AM, Andrew G. Malis <agmalis@gmail.com> = wrote:
Phillip,

On behalf of the PALS WG, thanks for your = review.

To be clear, this sounds like more = a comment on RFC 5085 than it does a
comment on the draft = in question. So is there any action requested regarding
the = draft?

Also, you many not be aware that = pseudowires are almost exclusively used in
well-managed = private enterprise services networks, usually either physically
or logically separated from the public Internet for reasons = of both traffic
management and assurance to enterprise = customers that their private traffic
is well separated = from the Internet. Thus interception is less a threat than
it may be for protocols that are used in the public = Internet.

Thanks,
Andy


On Tue, Apr 26, 2016 at 8:48 = AM, Phillip Hallam-Baker
<phill@hallambaker.com> wrote:

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


This document is = an incremental change to a layer 2 virtualization
layer = (Software Defined Networking). As such it properly references
RFC5085 for security considerations.

That said, I am a bit surprised at the security = considerations in
RFC5085 which points out that denial of = service is an issue but not
the introduction of a new set = of opportunities for interception. This
is surprising = given that BGP interception had already been used in
international hostilities when the RFC was published.

Further the proposed solution is to sprinkle = on some magic IPSEC dust
or equivalent. While that might = be an appropriate approach in an
experimental protocol, it = is hardly adequate for a production protocol
with = implications for Internet security as a whole.

Given the critical function of this layer and the date of = its
inception, I would expect to see a comprehensive = security architecture
developed as part of the overall = scheme.



= --Apple-Mail=_949C6DE8-0432-44A9-9FE3-3E36A3FEEFC6-- --Apple-Mail=_A1969861-7133-4F2F-8FA2-62DE500FF49F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXH91MAAoJEIXgpQGOZny9BPoQAIfsG5ZK3UoK75QfPueLduSF 3VQvqoD80eDt0mT+8prV2BEIXmtrgTr5Z6sDFd8//+Of5dIoc9L1I6wT+4UhnyX2 doWK+W/5fw3xILHdafr0PXgCOCW7Sx9HlpBjQBwJpyzqNBJi2NKsP0LPUxh5Nl0T urfwUk09cmahjJcQdLVHVfmkGzFFHT5Oc0E2V8dcPP4EVLvbrLBfkPYGjwspIQqJ sOoj/Wla34symh3MktFxr1/gfyjEa/ra9UhvOam9rtkdd1FY3rzY10ZxLxumCwM+ cOd3LNt/DfWD+Wy5ItRUpHLIXOViPzPfeovnPmCG5IYP8gvUYT7IuIAPcXWD5KI0 wZ/82Wi2WmDozCk8CfeW0/LrGdxoxB4TsDCK+EmliSP57YlznOmUG98tWY5ck9RQ purYNTnWwziVtL+LWy6kBmmuoXHyIidKxLfIyyyh/ilCiwHLgGp0W7nAsJBeRKQy o4SttX+zfPjr0kXpkvHg6myrznfXy9veqRCvZWLL3lxKEpdPu5vOVhbnNxv7EKOe IfLjojEswloXR1XoWjCPV3w81+IF76hxaLsE0RzUjPDk6ZAGJcC9xktW8IGpwANv uPG/GtCyx6UflMzqdyHDRMf8ycrPljdQL3KpLym6jnWI9bq6usDON4MW3NK8AjLr Sa3t4F9glZ3ZQhIOawCm =9nSv -----END PGP SIGNATURE----- --Apple-Mail=_A1969861-7133-4F2F-8FA2-62DE500FF49F-- From nobody Tue Apr 26 14:32:55 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC96C12D0F2; Tue, 26 Apr 2016 14:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-BBPNwvc7Ja; Tue, 26 Apr 2016 14:32:54 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5B43120727; Tue, 26 Apr 2016 14:32:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6559; q=dns/txt; s=iport; t=1461706373; x=1462915973; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DtdJsFZC3nUil+JIGs7vZxB5oCUJS4WBq+WxxSlAmAw=; b=OxvNzmvLocWI9h716GMsQDDLTuUu1uBiIXcRC8KA9ZcDVNd287XcBvH6 Gc7+RPVuS0n7DVm/l2X53ar5CZVgXLQ2HAeJ7HnOefXUXmZPyuN3G33U9 F8XjIJA0+oEcuhKrv0nug/kAqkS/DX9X68yh6OZ1Rf0ER2GUyO98PLjul M=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DhAgCV3R9X/5tdJa1egmxMgVAGtQWCZ?= =?us-ascii?q?IIPDoF0hg8CgUA4FAEBAQEBAQFlJ4RBAQEBAwEjVgULAgEIEgYqAgIyFw4CBA4?= =?us-ascii?q?FDogUCLNBkQ4BAQEBAQEBAQEBAQEBAQEBAQEBAQENCIYhgXUIgk6HP4JWBZMfh?= =?us-ascii?q?HEBgyeBZ4kIgWeETYhdjy8BHgFDggUbgUtsiC9/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,538,1454976000"; d="asc'?scan'208,217";a="266405210" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Apr 2016 21:32:53 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u3QLWqgA026625 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Apr 2016 21:32:52 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 26 Apr 2016 17:32:51 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Tue, 26 Apr 2016 17:32:51 -0400 From: "Carlos Pignataro (cpignata)" To: Phillip Hallam-Baker Thread-Topic: SECDIR review of draft-ietf-pals-seamless-vccv-02 Thread-Index: AQHRn7noe7HtbKiJG0u+NZfEBeLzNZ+ckuUAgAAIk4CAAG58gA== Date: Tue, 26 Apr 2016 21:32:51 +0000 Message-ID: References: <01160F37-0C73-42CE-AA8C-A09F876080A8@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.182.239] Content-Type: multipart/signed; boundary="Apple-Mail=_E5632678-049B-439B-95FC-3CEB28DF1B99"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-pals-seamless-vccv.all@ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-pals-seamless-vccv-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 21:32:55 -0000 --Apple-Mail=_E5632678-049B-439B-95FC-3CEB28DF1B99 Content-Type: multipart/alternative; boundary="Apple-Mail=_572DEA97-080B-4515-8632-15AD2B5C7991" --Apple-Mail=_572DEA97-080B-4515-8632-15AD2B5C7991 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Phillip, Please find below one follow-up, the rest of the message snipped out for = clarity > On Apr 26, 2016, at 10:57 AM, Phillip Hallam-Baker = wrote: >=20 >> In re-reading the Security Considerations section (thanks again for = the review), I do believe there is an area of improvement: from RFC = 5885, since these PWs specify single-hop adjacencies, the document ought = to specify the use of GTSM for the IP/UDP encapsulations. >>=20 >> I=E2=80=99ll be happy to add that in. Please let me know if you have = any concerns with it. >=20 > For an infrastructure of this scale, the security architecture should > really be described in a separate document and at length. I understand what you write, but you are answering a different question. In a separate note you said: > rather than action on this particular draft. Here, I was only asking if you have concerns with one specific = improvement that we can add to the Security Considerations of this = document. Thanks! =E2=80=94 Carlos. --Apple-Mail=_572DEA97-080B-4515-8632-15AD2B5C7991 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Phillip,

Please find below one follow-up, the rest of the message = snipped out for clarity

On = Apr 26, 2016, at 10:57 AM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:

In re-reading the Security Considerations section (thanks = again for the review), I do believe there is an area of improvement: = from RFC 5885, since these PWs specify single-hop adjacencies, the = document ought to specify the use of GTSM for the IP/UDP = encapsulations.

I=E2=80=99ll be happy to = add that in. Please let me know if you have any concerns with it.

For an infrastructure of this scale, the = security architecture should
really be described in a separate = document and at length.

I understand what you write, but you = are answering a different question.

In a separate note you said:

rather than action on this particular draft.

Here, I was = only asking if you have concerns with one specific improvement that we = can add to the Security Considerations of this document.

Thanks!

=E2=80=94 = Carlos.
= --Apple-Mail=_572DEA97-080B-4515-8632-15AD2B5C7991-- --Apple-Mail=_E5632678-049B-439B-95FC-3CEB28DF1B99 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXH95/AAoJEIXgpQGOZny9T9YQAKm3BnMRCop3yQrzqdnsktKw p/8lTK0ZwCgh3P8qMy3khv+b9cnqsuhUwbkvNUElBMtTyA5S+N7v4nkRXTrBvisP PERTfow6TE2hyInfwDsn7pMYbJiQxPmdMaJZ7tC0SwyLl3LTWpG5PELsV3immHvi el53Tzh2KNiU97oG6Fp3H4G7VPNFLdqKLZpZbqhN/nlTMUeMO2vy4eJom1BQ8Kxy MU0xO/7CVDJpY4mGAiWVQyvW32r4Ev2Z4rIDibh48p+Ig6KB/6ASAd7vBp1zPhK1 seEUBGCo3pVKIJrCiVcNN2oUN16oaJrEpytDBIkotqWzmrW72rFLbB2KzhPn3KA/ Lntax53BKqONqhiVLuGdAFlgB29ZOf7LKwsK70stL9BrMWrMnIV/YUHng/uwdCLD x9/HV5IrC99BkA/shSUqnnJmNPqslqgciq69i/pBu1Bowk6G8Dswg9kbwdXpfSkH YzNFKcT0wI78GkPJRiYkgYd3K18GvuKK5PKDNXzV9jVhq2HMcx14OtCBqBYtZbY3 G62T3Hmr4HzxHJuj6ecfndYfe4CKKEnmcbp1w6kWKhCc79UXDSufa/DcVm5sORg7 YQZUgqR/a0yM0l8A0tfSIdlDnudiThHBTGGJHyeRQliOUrBGakYxTteKZDsUWmOq n4RJJzoQIFnI3veSDZqF =fMDE -----END PGP SIGNATURE----- --Apple-Mail=_E5632678-049B-439B-95FC-3CEB28DF1B99-- From nobody Wed Apr 27 02:00:14 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56CE312D63C; Wed, 27 Apr 2016 02:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLESUGmyWV-v; Wed, 27 Apr 2016 02:00:02 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9649812D11C; Wed, 27 Apr 2016 02:00:01 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id e201so28883351wme.0; Wed, 27 Apr 2016 02:00:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=jzQapfs8r07v2PiK22f7y3c5GV0fx87xe/a+yg8Ceq8=; b=udpEvXqElbAursNqm1RcViq01crFERz17GoQCMHdHdAR71/PYQ2XBnQlqYyJQTOzR/ B8zSUrhr2dw5I7Jp0Y6bkj0HBzGor7g/6pz6xZHY33rlhEw13m/oSwHzLx7b44F8nfA1 K6m67ajAAX49efa34yCstggULELGXM8N2NtSrUNcFrn82ngJu3XJDPk7p3RtEfZsvNMZ 4mPhGoNCHsZKconoRa3T6SwF59Z50z8RbIMZ0yc12pbmg5ecSLGci9J97w4KWavByae0 caomTpAKn0X55S3g+qg6NFzLo5TxMg+J7LpcXSV+9GgdBsVOVrDNPW0mQGPTGT9JWg19 qqoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=jzQapfs8r07v2PiK22f7y3c5GV0fx87xe/a+yg8Ceq8=; b=WA4qee0/D86RVfrIhtswnKhZvFvDbEEa1L91JkEuz0BxMxNrjY/4wE/fAftPaGYLR4 MFnp2QbUGNnXg8HNXDCg3U4YzQN/ZdBSqOhnwlvnaGGnULA3FPrM7KFC14P+Q22eDxu+ voyj9Yu3EzdD7p31o3eQOgcqPigh3sy3SNsnpnL33el+lf0zeiz+Rffi8LQTtTb3otoL X/97jiYlB/kgMPgcuLClhJEQV6DC8p85U/k3rFpo8OM0Mvuu7+lZ3X5Ik8TcCe12ZEFk F3vnQ7N+Cxe64N2Pp9PmGErn7Zwl75hKHJEhT+RftkpRU/vN6O23m8aHc1rsvdnWhmQH bK3Q== X-Gm-Message-State: AOPr4FUvlME+2jOrGQBRBs5ht7Q72ZEsaQTE5K2qYcJJUloXTAof2kys6ptN4k1u9bFqXQ== X-Received: by 10.194.107.6 with SMTP id gy6mr7966664wjb.20.1461747600108; Wed, 27 Apr 2016 02:00:00 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id m20sm7318501wma.23.2016.04.27.01.59.58 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Apr 2016 01:59:58 -0700 (PDT) To: Phillip Hallam-Baker , "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-pals-seamless-vccv.all@ietf.org References: From: Stewart Bryant Message-ID: <57207F8D.9080000@gmail.com> Date: Wed, 27 Apr 2016 09:59:57 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------090609020509060702020904" Archived-At: Subject: Re: [secdir] SECDIR review of draft-ietf-pals-seamless-vccv-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 09:00:08 -0000 This is a multi-part message in MIME format. --------------090609020509060702020904 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 26/04/2016 13:48, Phillip Hallam-Baker wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > > This document is an incremental change to a layer 2 virtualization > layer (Software Defined Networking). I don't see how you conclude that this is anything to do with SDN, other than noting that SDN is ONE of the control planes that might be used, except that in the early days of this work we called it "static". > As such it properly references > RFC5085 for security considerations. As others later state this is a small update to RFC5085. As such it should not be held hostage to your concerns about RFC5085, which is a widely deployed protocol with significant interoperation, at least in its MPLS variant. > > That said, I am a bit surprised at the security considerations in > RFC5085 which points out that denial of service is an issue but not > the introduction of a new set of opportunities for interception. This > is surprising given that BGP interception had already been used in > international hostilities when the RFC was published. So I am curious what would an interception attack on an OAM protocol look like and what would harm would such an attack do? If you could simply read the packets you could find out the loss, delay, jitter and outage rate but I don't see why an attacker would be that interested in such data. If you could intercept the OAM packets, I am sure that the data packets carried over the same path would be far more interesting, and securing those would secure the OAM since they fate share. > > Further the proposed solution is to sprinkle on some magic IPSEC dust > or equivalent. While that might be an appropriate approach in an > experimental protocol, it is hardly adequate for a production protocol > with implications for Internet security as a whole. I really don't understand this point. In the MPLS case we use exactly the same dataplane and exactly the same signalling plane as is used by Internet traffic. You may have concerns about the security of those aspects of the Internet, but this is not the place to address those concerns. If you extend the security of MPLS, this protocol will inherit those extensions. I am not sure how widely L2TP OAM is actually deployed, but both the L2TP control and dataplane (and the OAM fate shares with the dataplane) run over IP, and will inherit any security enhancements that are applied to IP. > > Given the critical function of this layer and the date of its > inception, I would expect to see a comprehensive security architecture > developed as part of the overall scheme. As I noted above, the most widely deployed version is the MPLS variant and any concern about MPLS security needs to be addressed to the MPLS WG. PALS will automatically pick up any MPLS security extensions. - Stewart --------------090609020509060702020904 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

On 26/04/2016 13:48, Phillip Hallam-Baker wrote:
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.


This document is an incremental change to a layer 2 virtualization
layer (Software Defined Networking).

I don't see how you conclude that this is anything to do with SDN, other
than noting that SDN is ONE of the control planes that might be used,
except that in the early days of this work we called it "static".

As such it properly references
RFC5085 for security considerations.

As others later state this is a small update to RFC5085. As such it should not be held
hostage to your concerns about RFC5085, which is a widely deployed protocol
with significant interoperation, at least in its MPLS variant. 


That said, I am a bit surprised at the security considerations in
RFC5085 which points out that denial of service is an issue but not
the introduction of a new set of opportunities for interception. This
is surprising given that BGP interception had already been used in
international hostilities when the RFC was published.

So I am curious what would an interception attack on an OAM protocol look
like and what would harm would such an attack do? If you could simply
read the packets you could find out the loss, delay, jitter and outage rate
but I don't see why an attacker would be that interested in such data.

If you could intercept the OAM packets, I am sure that the data packets carried
over the same path would be far more interesting, and securing those would
secure the OAM since they fate share.


Further the proposed solution is to sprinkle on some magic IPSEC dust
or equivalent. While that might be an appropriate approach in an
experimental protocol, it is hardly adequate for a production protocol
with implications for Internet security as a whole.

I really don't understand this point.

In the MPLS case we use exactly the same dataplane and exactly the same
signalling plane as is used by Internet traffic. You may have concerns about the
security of those aspects of the Internet, but this is not the place to address
those concerns. If you extend the security of MPLS, this protocol will inherit
those extensions.

I am not sure how widely L2TP OAM is actually deployed, but both the L2TP
control and dataplane (and the OAM fate shares with the dataplane) run
over IP, and will inherit any security enhancements that are applied to IP.


Given the critical function of this layer and the date of its
inception, I would expect to see a comprehensive security architecture
developed as part of the overall scheme.

As I noted above, the most widely deployed version is the MPLS variant
and any concern about MPLS security needs to be addressed to the MPLS
WG. PALS will automatically pick up any MPLS security extensions.

- Stewart
--------------090609020509060702020904-- From nobody Wed Apr 27 02:37:40 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D2012D694; Wed, 27 Apr 2016 02:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiicy-5fXcDK; Wed, 27 Apr 2016 02:37:31 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 168FA12D5E9; Wed, 27 Apr 2016 02:31:50 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id a17so7809201wme.0; Wed, 27 Apr 2016 02:31:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=L71op/rH1joACXb0Zci24SI3rhLuo76+//MfbBYY2RU=; b=nTANdMnnSfhlQA5wVxBBMP4D+qsOVawoHaIg8mvNiJHXpew94Em5Cj58npTDiMee22 yZI3rdBXhgJsPAj+xmiXvlMR9YSTQJfsOu5MtieZ1eFR17OmKzgZWn72c8DWRAbne4PO py9g5RUZET+C1XmK0GatyjBjLMx2JMnuWEA7M6IfVUlPnDGomtRPRwMRzvbf29EJUmCU MxgexM7mqe7fJiw0dGWcGkKqEwb+u7poQrWSajQed3yKEbtqYdbf23ynvwFI5I1q0N7K znx1jE06BWzn59UjmSCv9wVdi+49uvJkaW7NnhThwAplHiQce//g6sIo1VMG5s4+OOWC 6t4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=L71op/rH1joACXb0Zci24SI3rhLuo76+//MfbBYY2RU=; b=hP9xWbxZiF7EUG2MRFi9oyeh4Haa0zsqwrATJ6+DdTTRNdE3PMB+dpF05Vw670FaWj RkACBhw26T3sYdoLbFlMPMC8xNEUV+Mg4ax6znjfj48nVbE4qPVeKoeA0dBDRYVkBDO3 p/qMZU283aPOi49eVBWELYB4iTSmz5SvtF6qZmVZOeBTDfi/nL85zRbW/FEiDZuBSpED Oy9JUbxe+Fi0oGG1iBXlAYkJHxoeZb6yJsb5JGXrxJJsD8UJ+4aJF5dYZQFksh6+nH+m hJs51y/kudbxc1yD4QpoCkueL+fGZtCH5ZkJbUcqr7eGwJT2tre5LKAI2cifErYPSZyT FChA== X-Gm-Message-State: AOPr4FWZbK4tUBo/suRpHAlLb0/NtMhtJgQw1S/eKlw4yaeWx0Y7fAeD9SKo0jGHSP3aGg== X-Received: by 10.194.63.8 with SMTP id c8mr7949870wjs.89.1461749508624; Wed, 27 Apr 2016 02:31:48 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id o128sm7432749wmb.19.2016.04.27.02.31.46 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Apr 2016 02:31:47 -0700 (PDT) To: Phillip Hallam-Baker , "Andrew G. Malis" References: From: Stewart Bryant Message-ID: <57208701.2010209@gmail.com> Date: Wed, 27 Apr 2016 10:31:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------040703010801030303090403" Archived-At: Cc: draft-ietf-pals-seamless-vccv.all@ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-pals-seamless-vccv-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 09:37:33 -0000 This is a multi-part message in MIME format. --------------040703010801030303090403 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 26/04/2016 15:51, Phillip Hallam-Baker wrote: > Yes, I think that what is needed is IAB review of what is going on > rather than action on this particular draft. Sorry - what is the scope of your proposed IAB review? > In particular, I don't consider a protocol suitable to be considered > an IETF standard unless people can buy devices from multiple vendors > and configure them to work together securely. Sure, but I would like to see an evidence based assessment of the specific problem you are seeing in the field. So far none has been brought to PALS (ne PWE3) or MPLS as far as I am aware. Carlos can talk to L2TP, but again I have not heard of a specific problem ever being raised. If one is raised we will address it in the appropriate WG. > > The security approach outlined in 5085 is mix and match with a large > dose of handwaving. It desperately needs to be reconsidered and a > security architecture written up. I don't think that you can expect > interoperability on the basis of that description. If we do that, we should really do it in two halves, MPLS and L2TP. Since PALS over MPLS runs the MPLS control and dataplane the solution needs to be owned by MPLS. Similarly any LT2P work belongs in L2TPext. > > The Snowden documents demonstrate that 'well managed enterprise > networks' are attacked on a daily basis and that this is the basis for > mass surveillance. Right, but I cannot see why anyone would want to mass surveil the OAM protocol, and we inherit the security enhancements to the underlying data and control planes. > > I do not consider IPSEC to be a suitable security mechanism for this > type of system. If I was given the design brief, I would insist that > every message be authenticated by digital signature rather than a MAC > and the control messages logged. I might use a MAC for > pre-authentication to prevent DoS attack on the control plane. But the > control messages should be fixed in non repudiable fashion. We need to examine this statement in more detail to understand which element of the system you are concerned about. However please remember that some elements of the dataplane and OAM are cost and time sensitive. > > That is the only way I could be confident that PRISM class attack > against the network had not been performed. That is all very well, but we do need an eco-system that is prepared to pay for any upgrade. The place to start here is with an operator requirement draft. Given a requirements RFC agreed by the operator community, I am sure we will design the necessary technology to fullfill those requirements. Stewart > > > On Tue, Apr 26, 2016 at 10:18 AM, Andrew G. Malis wrote: >> Phillip, >> >> On behalf of the PALS WG, thanks for your review. >> >> To be clear, this sounds like more a comment on RFC 5085 than it does a >> comment on the draft in question. So is there any action requested regarding >> the draft? >> >> Also, you many not be aware that pseudowires are almost exclusively used in >> well-managed private enterprise services networks, usually either physically >> or logically separated from the public Internet for reasons of both traffic >> management and assurance to enterprise customers that their private traffic >> is well separated from the Internet. Thus interception is less a threat than >> it may be for protocols that are used in the public Internet. >> >> Thanks, >> Andy >> >> >> On Tue, Apr 26, 2016 at 8:48 AM, Phillip Hallam-Baker >> wrote: >>> I have reviewed this document as part of the security directorate's >>> ongoing effort to review all IETF documents being processed by the >>> IESG. These comments were written primarily for the benefit of the >>> security area directors. Document editors and WG chairs should treat >>> these comments just like any other last call comments. >>> >>> >>> This document is an incremental change to a layer 2 virtualization >>> layer (Software Defined Networking). As such it properly references >>> RFC5085 for security considerations. >>> >>> That said, I am a bit surprised at the security considerations in >>> RFC5085 which points out that denial of service is an issue but not >>> the introduction of a new set of opportunities for interception. This >>> is surprising given that BGP interception had already been used in >>> international hostilities when the RFC was published. >>> >>> Further the proposed solution is to sprinkle on some magic IPSEC dust >>> or equivalent. While that might be an appropriate approach in an >>> experimental protocol, it is hardly adequate for a production protocol >>> with implications for Internet security as a whole. >>> >>> Given the critical function of this layer and the date of its >>> inception, I would expect to see a comprehensive security architecture >>> developed as part of the overall scheme. >> --------------040703010801030303090403 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

On 26/04/2016 15:51, Phillip Hallam-Baker wrote:
Yes, I think that what is needed is IAB review of what is going on
rather than action on this particular draft.
Sorry - what is the scope of your proposed IAB review?
In particular, I don't consider a protocol suitable to be considered
an IETF standard unless people can buy devices from multiple vendors
and configure them to work together securely.

Sure, but I would like to see an evidence based assessment of the specific
problem you are seeing in the field. So far none has been brought to PALS (ne PWE3)
or MPLS as far as I am aware. Carlos can talk to L2TP, but again I have not
heard of a specific problem ever being raised.

If one is raised we will address it in the appropriate WG.


The security approach outlined in 5085 is mix and match with a large
dose of handwaving. It desperately needs to be reconsidered and a
security architecture written up. I don't think that you can expect
interoperability on the basis of that description.

If we do that, we should really do it in two halves, MPLS and L2TP. Since
PALS over MPLS runs the MPLS control and dataplane the solution needs
to be owned by MPLS. Similarly any LT2P work belongs in L2TPext.


The Snowden documents demonstrate that 'well managed enterprise
networks' are attacked on a daily basis and that this is the basis for
mass surveillance.

Right, but I cannot see why anyone would want to mass surveil the OAM
protocol, and we inherit the security enhancements to the underlying
data and control planes.


I do not consider IPSEC to be a suitable security mechanism for this
type of system. If I was given the design brief, I would insist that
every message be authenticated by digital signature rather than a MAC
and the control messages logged. I might use a MAC for
pre-authentication to prevent DoS attack on the control plane. But the
control messages should be fixed in non repudiable fashion.

We need to examine this statement in more detail to understand which element
of the system you are concerned about. However please remember that some
elements of the dataplane and OAM are cost and time sensitive.


That is the only way I could be confident that PRISM class attack
against the network had not been performed.

That is all very well, but we do need an eco-system that is prepared to
pay for any upgrade. The place to start here is with an operator requirement
draft. Given a requirements RFC agreed by the operator community, I am
sure we will design the necessary technology to fullfill those requirements.

Stewart



On Tue, Apr 26, 2016 at 10:18 AM, Andrew G. Malis <agmalis@gmail.com> wrote:

Phillip,

On behalf of the PALS WG, thanks for your review.

To be clear, this sounds like more a comment on RFC 5085 than it does a
comment on the draft in question. So is there any action requested regarding
the draft?

Also, you many not be aware that pseudowires are almost exclusively used in
well-managed private enterprise services networks, usually either physically
or logically separated from the public Internet for reasons of both traffic
management and assurance to enterprise customers that their private traffic
is well separated from the Internet. Thus interception is less a threat than
it may be for protocols that are used in the public Internet.

Thanks,
Andy


On Tue, Apr 26, 2016 at 8:48 AM, Phillip Hallam-Baker
<phill@hallambaker.com> wrote:

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


This document is an incremental change to a layer 2 virtualization
layer (Software Defined Networking). As such it properly references
RFC5085 for security considerations.

That said, I am a bit surprised at the security considerations in
RFC5085 which points out that denial of service is an issue but not
the introduction of a new set of opportunities for interception. This
is surprising given that BGP interception had already been used in
international hostilities when the RFC was published.

Further the proposed solution is to sprinkle on some magic IPSEC dust
or equivalent. While that might be an appropriate approach in an
experimental protocol, it is hardly adequate for a production protocol
with implications for Internet security as a whole.

Given the critical function of this layer and the date of its
inception, I would expect to see a comprehensive security architecture
developed as part of the overall scheme.

--------------040703010801030303090403-- From nobody Wed Apr 27 02:45:10 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC6E12D5E9; Wed, 27 Apr 2016 02:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyEjAdAI8Wnu; Wed, 27 Apr 2016 02:44:59 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D969312D695; Wed, 27 Apr 2016 02:44:58 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id a17so8255180wme.0; Wed, 27 Apr 2016 02:44:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=xOBckTupv3g7Cw/gM9lNfl5IzMFXROvIu61WMBze7Cs=; b=upQo7qteVydMsanii2QrQDWOV+Ycy226AF0At5CfnWzEOqL0iayOWOUfGyYoGg3ULW 0VloJTRkkjaZeAx8p7mL+hsniFldUVtxKgEnzEvCXvrkLc99uF8O+0Qxpdads1Rdf/di /lQuM6Jxvb8Ru0OE/SNynH+5byfpXSJul03/Qs47mHn0ZsVd3I490mrXEmEXT7vvwkp0 HZEojKT2z/oUNAocR+hfHNfN+S2Q6rCfV73y4T58qvSmPtZcL7tu/G7uqyVuCKRxclHL UfpqdsiBMlFaVqYTLIZknbtUhrtRLAHAbLSWNpl99omJkOXYpPRha37iuvY3Dd37M4gv JMVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=xOBckTupv3g7Cw/gM9lNfl5IzMFXROvIu61WMBze7Cs=; b=f5XLe+gTHmOTp1HZ3xMK6kvrMPeoTw7y9sjVZQpw+5clh9KTpKF69YBGx1pUE18c6U UybrtPAzXGoP3YRxvLpDqbYJz9dDSqeUHTnEqLjE4i1n/UWOXk5WaoQS3w4r/x5B42rX z4lXSn5tsuxIvAtiBnO4+87Qft5ZLN6o8JpoWTVtAS44nJhAPJvV9k79FPiA/zKxCjO0 amkxScocx+nv5Mdpk66tPJZh41zA9WmDk0ZONhoSeuKP0pmNbFDWmg7KHaKLN66rCSw7 lnVC6MEf2+EGjq3lTToMo5eHJAw9Vaq050g3OTH7EeO73dGGu/EPSJ2rHJl/zI211F8R MRQg== X-Gm-Message-State: AOPr4FXpdpJecQjIgFRuqh97UGt8V4/9dPzknkMHWHTRwTdOtf2awGP6Cx2drDFAneDJNg== X-Received: by 10.194.111.199 with SMTP id ik7mr8969075wjb.150.1461750297352; Wed, 27 Apr 2016 02:44:57 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id f11sm23059285wmf.22.2016.04.27.02.44.55 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Apr 2016 02:44:56 -0700 (PDT) To: Phillip Hallam-Baker , "Carlos Pignataro (cpignata)" References: <01160F37-0C73-42CE-AA8C-A09F876080A8@cisco.com> From: Stewart Bryant Message-ID: <57208A16.5050602@gmail.com> Date: Wed, 27 Apr 2016 10:44:54 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-pals-seamless-vccv.all@ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-pals-seamless-vccv-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 09:45:00 -0000 On 26/04/2016 15:57, Phillip Hallam-Baker wrote: > On Tue, Apr 26, 2016 at 10:26 AM, Carlos Pignataro (cpignata) > wrote: >> Phillip, >> >> Many thanks for your review. >> >> As you rightly call out, this is indeed an incremental addition — I might add for emphasis a very incremental change. >> >> One point of clarification, however, is that this solution as defined does _not_ use BGP. The relevant control protocols’ security considerations are addressed in RFC 5085. This is not 'IPsec pixy-dust' — if you follow the pointers, you will get to the control connection (endpoint and message) security as well as protection for data plane spoofing. > > With respect, I disagree. > > A collection of pointers to a dozen other documents is not a security > architecture. > > I am aware that this is not BGP which is a layer 3 switching protocol. I don't think anyone would describe BGP as a layer 3 switching protocol! It exchanges reachability information, it does not switch packets. > This is layer 2 but the same security concerns apply. The fact that we > have seen nation state actors use BGP injection attacks as tools of > war demonstrate that this is a real concern. I think you need to explain the attack scenario you have in mind. >> In re-reading the Security Considerations section (thanks again for the review), I do believe there is an area of improvement: from RFC 5885, since these PWs specify single-hop adjacencies, the document ought to specify the use of GTSM for the IP/UDP encapsulations. >> >> I’ll be happy to add that in. Please let me know if you have any concerns with it. > For an infrastructure of this scale, the security architecture should > really be described in a separate document and at length. Let's start with the MPLS variant. What do you think needs to be added to RFC5920, and what of that is explicit to PALS? - Stewart From nobody Wed Apr 27 06:07:08 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBF812D162; Wed, 27 Apr 2016 06:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2U6V8apNgTFp; Wed, 27 Apr 2016 06:07:05 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 456DB12D161; Wed, 27 Apr 2016 06:07:05 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u3RD70hZ000978 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 27 Apr 2016 16:07:00 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u3RD6xwB006766; Wed, 27 Apr 2016 16:06:59 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22304.47475.765923.579337@fireball.acr.fi> Date: Wed, 27 Apr 2016 16:06:59 +0300 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org, draft-ietf-aqm-eval-guidelines.all@tools.ietf.org X-Edit-Time: 11 min X-Total-Time: 11 min Archived-At: Subject: [secdir] Secdir review of draft-ietf-aqm-eval-guidelines-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 13:07: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. Summary: ready with nits. This document describes various criteria for doing characterizations of active queue management schemes. As this is not really a protocol document there is not that much of security issues that could raise from here. The security considerations section says Some security considerations for AQM are identified in [RFC7567].This document, by itself, presents no new privacy nor security issues. and I agree with that. As for nits, the document uses very heavily references in a format where it makes document very hard to read. The references are used in such way, that if they are removed or hidden, the whole document comes completely unreadable. I think the references should only provide extra information, and the document should be readable even if you remove everything between [], but in this case the text comes like this: An AQM scheme SHOULD adhere to the recommendations outlined in [], and SHOULD NOT provide undue advantage to flows with smaller packets []. Also references style (i.e. whether it is [RFCxxxx] or [1]) should not affect the document readability, but in this case it makes things very hard to read when text is like: [1] separately describes the AQM algorithm implemented in a router from the scheduling of packets sent by the router. When you are reading the document and you do not remember what [1] (or [RFC7567]) actually is it forces you to go and check the reference section to see what this document is. It would be better if the text would be expanded so that the actual text is readable even if you remove all references, i.e. the first example would come: An AQM scheme SHOULD adhere to the recommendations outlined in Byte and Packet Congestion Notification document [RFC7141], and SHOULD NOT provide undue advantage to flows with smaller packets. (I have no idea why the second reference was there at all, it might be useful if it provided section talking about that, but as the whole document is "IETF Recommendations Regarding Active Queue Management", I do not think it relates only to the smaller packets. -- kivinen@iki.fi From nobody Wed Apr 27 11:24:52 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D67312DBA9; Wed, 27 Apr 2016 11:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4VhghwJJue6; Wed, 27 Apr 2016 11:24:48 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 603AD12DBA6; Wed, 27 Apr 2016 11:24:48 -0700 (PDT) Received: by mail-ob0-x234.google.com with SMTP id bg3so27060180obb.1; Wed, 27 Apr 2016 11:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=wV9+p9wVPXKySSRWcSUVwgewl9vp3G/WG+q68mm3CaY=; b=s8prsxg8PXfVSKxYSscGcA8DNO6nyzyl8vftD65+J/jsHZgcZuRlAUoNY5tzO4SPw5 viUB+uuAxbm8MFkc+ipOT6nU8xxjhVxcy1NiAGPMPMJGcLf27Gnc+kcciAtYHcyA5Nuh 75sTTIlb0mBqLy1GViA/hESelbjisJdXoLlQg76H6Epv6R9UKXPcLFPtI87P6sbO5nUP bojLhSohMtiRyxcdSGhdeqVLrWvB5hv7GTOeeH7RLZhUtltC3gvSRgcad4fpR2YF81MY DJ9SJxrTQZ8HPTK8WXQSYmkOKAWadgfU7wPrnwcSzoV1aTQ6k+yJsH+NXSThwkG91IVW Q+NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=wV9+p9wVPXKySSRWcSUVwgewl9vp3G/WG+q68mm3CaY=; b=JFq6ubxUGQ2wIEMr7z1XQIWnvggPmC/XWgXysgZBc9Hjjq2plKqgB57Rsp+ZRvt7V0 4KowcmkN2vpPLCoo3xqJiLgJY/fRFkw9+fYxSPB4SuZ+hNWIRy+DjHUZLdQeua5A3WNJ 43QUBPD+h2kXSX3P2+2RIFEEjZe9L9kNrD4pfac7pXK8HE8ayAw95haj5xiJtXw5Yt2Z im2k3yo9wEb+0XzfGdCu/XFjwBdEEfm56Jb1zUJS1MYSzercoNq+/S7oCCqoFKoYYD/D SyZu5sFp9mbVPs4kYBFYmJIJPVPLfdpV8Zzs5gokcvgiKl7c+TjvimFMBnJZfjPMbXDW wy1g== X-Gm-Message-State: AOPr4FXc7jOQUl4kctj7ymMADsmRJVjr/NA3xsRIKOdL1jlXiOT8yPz52qx6ZO9CEIhh6JpotDBs0jF24HktqQ== X-Received: by 10.60.97.38 with SMTP id dx6mr4414989oeb.5.1461781487531; Wed, 27 Apr 2016 11:24:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.22.216 with HTTP; Wed, 27 Apr 2016 11:24:32 -0700 (PDT) From: Donald Eastlake Date: Wed, 27 Apr 2016 14:24:32 -0400 Message-ID: To: "iesg@ietf.org" , draft-ietf-bess-multicast-damping.all@ietf.org Content-Type: multipart/alternative; boundary=089e0115f2a04dc21905317b86fd Archived-At: Cc: "secdir@ietf.org" Subject: [secdir] draft-ietf-bess-multicast-damping-04 SECDIR Review X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 18:24:50 -0000 --089e0115f2a04dc21905317b86fd Content-Type: text/plain; charset=UTF-8 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes procedures for damping multicast virtual private network routing state changes to control the effect, particularly the control plane load, of the churn due to the dynamic multicast group membership in customer sites. *Security:* Overall, I think it is ready with nits but my confidence in that assessment is not very high. The feature specified in this document is aimed at limiting one type of denial of service, or at least at interference to some users by others: denial or interference due to excessive control plane traffic due to a high rate of multicast group membership change. Still, it makes me a bit queasy that the document has not one word, even by reference, about security for the setting or changing of the parameters used at a node in the damping algorithm. I suppose it is reasonable that it doesn't talk about how any of the control messages involved are protected or authenticated since the document is just about suppressing such messages... The Security Considerations section has a reasonable discussion of how and to what extent the mechanisms specified provide the services claimed. Page 15, Section 9 (Security Considerations), 1st paragraph starting on this page: There are a number of things wrong with the following sentence: Note well that the two mechanism may interact: state for which Prune has been requested may still remain taken into account for some time if damping has been triggered and hence result in otherwise acceptable new state from being successfully created. I would guess it should be "result in preventing otherwise" or should end with "state not being successfully created". Here is a suggested replacement: The two mechanisms may interact as follows: if damping has been triggered, state for which Prune has been requested may remain and still be taken into account for some time resulting in an otherwise acceptable new state not being created. *Editorial:* This document is very heavy with acronymic jargon with no expansion or definition in this document. However, most of it is defined in other RFCs that are referenced. Although I am willing to accept that it is just a matter of style, this document has lots of extra words that add nothing but verbosity. Things that could be completely dropped with no loss, like starting a sentence with "Additionally, it is worth nothing that ...". If it wasn't worth noting, it presumably wouldn't be in the document. Page 4, Section 3, 3rd paragraph: "...this technique will allow to meet the goals..." -> "...this technique will meet the goals..." Page 12, Section 7.2: "More specifically it is RECOMMENDED to complement the existing ... (e.g. MRIB states): ..." -> "Complementing the existing ... (e.g. MRIB states) is RECOMMENDED: ..." Page 13, Section 7.3, 2nd paragraph: What does "dimentioning" mean? Also "...state churn to go beyond what..." -> "...state churn going beyond what..." Page 14, Section 9, 3rd paragraph: The word "shall" is used. While not capitalized, this word sounds quite mandatory to me but it is not used in a mandatory requirement context... I suggest "shall rely upon" -> "relies on". Page 15, near the top: "should rely upon already" -> "should use already" Finally, while I understand that others have a different opinion, I find it objectionable that not a single first page author is willing to list a telephone number of any sort in the Authors' Addresses section. To my mind, this sort of corner cutting does not speak well for the document. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com --089e0115f2a04dc21905317b86fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security= directorate's ongoing effort to review all IETF documents being proces= sed by the IESG.=C2=A0 Document editors and WG chairs should treat these co= mments just like any other last call comments.

This document describes procedures for damping multicast virtual private = network routing state changes to control the effect, particularly the contr= ol plane load, of the churn due to the dynamic multicast group membership i= n customer sites.

Security:

Overall, I think it is ready with nits but my confiden= ce in that assessment is not very high.

The feature specified in this document is aimed at limiting one type= of denial of service, or at least at interference to some users by others:= denial or interference due to excessive control plane traffic due to a hig= h rate of multicast group membership change. Still, it makes me a bit queas= y that the document has not one word, even by reference, about security for= the setting or changing of the parameters used at a node in the damping al= gorithm. I suppose it is reasonable that it doesn't talk about how any = of the control messages involved are protected or authenticated since the d= ocument is just about suppressing such messages...

The Security Considerations section has a reasonable discussion of how and= to what extent the mechanisms specified provide the services claimed.

Page 15, Section 9 (Security Considerations), 1st= paragraph starting on this page: There are a number of things wrong with t= he following sentence:

      =
    Note well that the two
   mechanism may interact: state for which Prune has been requested may
   still remain taken into account for some time if damping has been
   triggered and hence result in otherwise acceptable new state from
   being successfully created.

I would guess it should be "result in preventing otherwise" or= should end with "state not being successfully created". Here is = a suggested replacement:

          The two mechanisms may interact a=
s follows: if damping has
   been triggered, stat=
e for which Prune has been requested may remain
 =
  and still be taken into account for some time resulting in an
<= pre class=3D"" style=3D"font-size:13.3333px;margin-top:0px;margin-bottom:0p= x;color:rgb(0,0,0)"> otherwise accept= able new state not being created.

<= div>Editorial:

This document is very h= eavy with acronymic jargon with no expansion or definition in this document= . However, most of it is defined in other RFCs that are referenced.

Although I am willing to accept that it is just a m= atter of style, this document has lots of extra words that add nothing but = verbosity. Things that could be completely dropped with no loss, like start= ing a sentence with "Additionally, it is worth nothing that ...".= If it wasn't worth noting, it presumably wouldn't be in the docume= nt.

Page 4, Section 3, 3rd paragraph: "...thi= s technique will allow to meet the goals..." -> "...this techn= ique will meet the goals..."

Page 12, Section= 7.2: "More specifically it is RECOMMENDED to complement the existing = ... (e.g. MRIB states): ..." -> "Complementing the existing ..= . (e.g. MRIB states) is RECOMMENDED: ..."

Pag= e 13, Section 7.3, 2nd paragraph: What does "dimentioning" mean? = Also "...state churn to go beyond what..." -> "...state c= hurn going beyond what..."

Page 14, Section 9= , 3rd paragraph: The word "shall" is used. While not capitalized,= this word sounds quite mandatory to me but it is not used in a mandatory r= equirement context... I suggest "shall rely upon" -> "rel= ies on".

Page 15, near the top: "should = rely upon already" -> "should use already"
=
Finally, while I understand that others have a different opi= nion, I find it objectionable that not a single first page author is willin= g to list a telephone number of any sort in the Authors' Addresses sect= ion. To my mind, this sort of corner cutting does not speak well for the do= cument.

Thanks,
= Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd=C2=A0=C2=A0 +1-508= -333-2270 (cell)
=C2=A0155 Beaver Street,=C2=A0Milford, MA 01757 USA
= =C2=A0d3e3e3@gmail.co= m
--089e0115f2a04dc21905317b86fd-- From nobody Wed Apr 27 12:32:08 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF6E212D547; Wed, 27 Apr 2016 12:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePbI1KJWQLvL; Wed, 27 Apr 2016 12:32:04 -0700 (PDT) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB39612DB5E; Wed, 27 Apr 2016 12:32:03 -0700 (PDT) Received: by mail-pf0-x242.google.com with SMTP id e190so6699589pfe.0; Wed, 27 Apr 2016 12:32:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=ikJOniF4W9uxmTWnw+69pvweom2G45HWHGvD4IGo/Uc=; b=KBUpKUqDW2EnH07o/FrRDzF37PYkQYrQF95ytSP7srhTW70HnQayrD5kdUFASi2W7h t3eLCJX8hBuxTL5dOpdn21Ukf1cPMLzJVcMeYX1zgB9pVXxoCB8yfrw8CgOrHncQAp9W sMSqqvPLQkjTQwN2l9chRRyAG/YDhw+k8IyPqLYvEvOZ8ijNCl2RK+OnBvYB8KvwHZpo aOJkNSuRB0g2RmsImXKtKVbXDt2S1nbd/N2ktrymFrlcP0DpyOntmdo6ei7nN6T8zST2 qUC3zfoP3MmNp9iLcvL/h3sObRrGMgKJZBtr0EIbjxNdvF6dEwSD5LFavchIuxdnwPxV rZOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=ikJOniF4W9uxmTWnw+69pvweom2G45HWHGvD4IGo/Uc=; b=jO+D60AuU3L5gO0rjBomzs04BdMFTGm29X5obpXsuFbB8Yc27r6aheyPKFn5nv9awT x8GlwNJS49DIGEpagqKJtdF7SUoEnTAcQMkMOMPIS3Y3mbmwc43nB7Bs2K1DV9lvgnzJ dMCI9JqAKqvKkVfBiXTO6eId5NB7/ijDzG15IFEilbnWq4lAIMiOdsEZfJktIKa9uC/j jCrhncDS4QEhW2swip7MolVG1Idbp/R4NwSxxyG4sp/GfioFGlY+kkDYgnai3w7KrkJ4 gP/rVU/9D2D2Q5riLxQ3RLXYAgksUDYmIxS/CA1zLX/xqXBzY+1VSfCIi4k2sxtDd1cz Z4Jg== X-Gm-Message-State: AOPr4FVfE+P1aUVBj9D98rukeXsIVWysBxabFfHedDoy+MPIMaPSWniAvVPfVfTcXq60Hg== X-Received: by 10.98.70.67 with SMTP id t64mr14506623pfa.110.1461785523509; Wed, 27 Apr 2016 12:32:03 -0700 (PDT) Received: from Pushpasiss-MacBook-Pro.local ([171.48.10.246]) by smtp.gmail.com with ESMTPSA id q20sm8565044pfi.63.2016.04.27.12.32.00 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Apr 2016 12:32:02 -0700 (PDT) To: Catherine Meadows , Hannes Gredler References: <5719D3FA.4070402@gredler.at> <7609B084-63E4-4341-912B-2083E88F6CB8@nrl.navy.mil> From: Pushpasis Sarkar Message-ID: <572113AE.80602@gmail.com> Date: Thu, 28 Apr 2016 01:01:58 +0530 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <7609B084-63E4-4341-912B-2083E88F6CB8@nrl.navy.mil> Content-Type: multipart/alternative; boundary="------------090507040509050601080109" Archived-At: Cc: draft-ietf-isis-node-admin-tag.all@ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] sectdir review of draft-ietf-isis-node-admin-tag-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 19:32:06 -0000 This is a multi-part message in MIME format. --------------090507040509050601080109 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Catherine, Please let me know if the following text clarifies it better or not. " 6. Security Considerations Node administrative tags, like link administrative tags [RFC5305], can be used by operators to indicate geographical location or other sensitive information. The information carried in node administrative tags, like link administrative tags, can be leaked to an IGP snooper. Hence this document does not introduce any new security issues. Advertisement of tag values for one administrative domain into another involves the risk of misinterpretation of the tag values (if the two domains have assigned different meanings to the same values), and may have undesirable and unanticipated side effects. Security concerns for IS-IS are already addressed in [ISO10589], [RFC5304], and [RFC5310] and are applicable to the mechanisms described in this document. Extended authentication mechanisms described in [RFC5304] or [RFC5310] SHOULD be used in deployments where attackers have access to the physical networks and nodes included in the IS-IS domain are vulnerable. " Thanks and Regards, -Pushpasis On 4/27/16 1:36 AM, Catherine Meadows wrote: > Hannes: > > My apologies, I could have been a little more clear. > > The security considerations section begins with a security consideration: > > Node administrative tags may be used by operators to indicate > geographical location or other sensitive information. The > information carried in node administrative tags could be leaked to an > IGP snooper. > > This doesn’t come with a citation of any other document, so I assumed > it was “new”, and was confused when the > next sentence said the document does not introduce any new security > concerns. If this security consideration also applies to > RFC5130 and RFC5305, you could cite those (although they do not > address this particular issue in their security > concerns section it would still show that you are not introducing any > new security concerns). > > > Cathy > > > > > Catherine Meadows > Naval Research Laboratory > Code 5543 > 4555 Overlook Ave., S.W. > Washington DC, 20375 > phone: 202-767-3490 > fax: 202-404-7942 > email: catherine.meadows@nrl.navy.mil > > >> On Apr 22, 2016, at 3:34 AM, Hannes Gredler > > wrote: >> >> catherine, >> >> i fail to see how this does introduce *new* security concerns. >> >> background: >> >> we have in IS-IS two existing tagging mechanism's: >> >> 1) admin-groups for links >> https://tools.ietf.org/html/rfc5305#section-3.1 >> >> 2) prefix-tags for prefixes >> https://tools.ietf.org/html/rfc5130#section-3.1 >> >> both "tagging-spaces" are local administered and have >> no global significance. >> >> the purpose of draft-ietf-isis-node-admin-tag-08 is to >> add support for a third tagging method which allows tagging >> of an entire node using local administered tagging space. >> (same operational spirit as in 1) and 2) ) >> >> now my question(s): >> >> - why is adding of an local-administered tag with no implied >> semantics considered to be security relevant ? >> >> - what specific (apparently mis-)wording in >> draft-ietf-isis-node-admin-tag makes you think >> it is security relevant ? >> >> /hannes >> >> On 4/21/16 19:36, Catherine Meadows wrote: >>> I have reviewed this document as part of the security directorate's >>> ongoing effort to review all >>> IETF documents being processed by the IESG. These comments were written >>> primarily for the >>> benefit of the security area directors. Document editors and WG chairs >>> should treat these comments >>> just like any other last call comments. >>> >>> This draft describes an extension to the IS-IS routing protocol, that >>> allows tagging and grouping of nodes >>> in an IS-IS domain. This makes it possible to increase the efficiency >>> of route and path selection, since the tags >>> give information about a router’s capabilities. >>> >>> The Security Considerations section correctly identifies one of the main >>> security risks of using such tags: they may leak >>> sensitive information about, e.g., geographical location. However, I’m >>> confused by the statement following that: >>> >>> “This document does not introduce any new security concerns. Security >>> concerns for IS-IS are already addressed in >>> [ISO10589], [RFC5304], and [RFC5310] are are applicable to the >>> mechanisms described in this document.” >>> >>> As far as I can tell, this document *does* introduce new security >>> concerns, because the tags may reveal sensitive >>> information that may not have been made available otherwise. Moreover, >>> RFCs 5304 and 5310 concern authentication, not >>> secrecy, and so do not address information leakage at all. My own >>> suggestion >>> for a recommendation would be that implementors should weigh the >>> benefits of putting certain kinds of information on tags >>> versus the risk of its being used by an attacker, and make their >>> decisions accordingly. This would not be a SHOULD a MUST >>> recommendation by the way, but simply advisory. >>> >>> I’m not sure what is meant by the last sentence in this paragraph: >>> >>> Extended authentication mechanisms described in [RFC5304] or [RFC5310] >>> SHOULD be used in >>> deployments where attackers have access to the physical networks and >>> nodes included in the IS-IS domain are vulnerable. >>> >>> Is this addressing the problem of sensitive information on tags? If so, >>> you need to say how. If it is addressing >>> spoofing of tags, it should be given its own paragraph, and the threat >>> you are talking about should be made clear. >>> >>> In the last paragraph, on the misattribution of tags from different >>> domains, what would you recommend for mitigating against >>> this problem? Also, since this is in the security considerations >>> section, you should say something about how an attacker >>> could take advantage of it. >>> >>> In my opinion, the Security Considerations section needs a major >>> revision. However, >>> I consider this document Almost Ready, because the purpose of the >>> revision would be mainly to make the section more clear, not to address >>> any overlooked security problems. >>> >>> >>> >>> >>> Catherine Meadows >>> Naval Research Laboratory >>> Code 5543 >>> 4555 Overlook Ave., S.W. >>> Washington DC, 20375 >>> phone: 202-767-3490 >>> fax: 202-404-7942 >>> email: catherine.meadows@nrl.navy.mil >>> >>> >>> > --------------090507040509050601080109 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Catherine,

Please let me know if the following text clarifies it better or not.

"
6.  Security Considerations

   Node administrative tags, like link administrative tags [RFC5305],
   can be used by operators to indicate geographical location or other
   sensitive information.  The information carried in node
   administrative tags, like link administrative tags, can be leaked to
   an IGP snooper.  Hence this document does not introduce any new
   security issues.

   Advertisement of tag values for one administrative domain into
   another involves the risk of misinterpretation of the tag values (if
   the two domains have assigned different meanings to the same values),
   and may have undesirable and unanticipated side effects.

   Security concerns for IS-IS are already addressed in [ISO10589],
   [RFC5304], and [RFC5310] and are applicable to the mechanisms
   described in this document.  Extended authentication mechanisms
   described in [RFC5304] or [RFC5310] SHOULD be used in deployments
   where attackers have access to the physical networks and nodes
   included in the IS-IS domain are vulnerable.
"

Thanks and Regards,
-Pushpasis

On 4/27/16 1:36 AM, Catherine Meadows wrote:
Hannes:

My apologies, I could have been a little more clear.

The security considerations section begins with a security consideration:

 
Node administrative tags may be used by operators to indicate
   geographical location or other sensitive information.  The
   information carried in node administrative tags could be leaked to an
   IGP snooper.

This doesn’t come with a citation of any other document, so I assumed it was “new”, and was confused when the
next sentence said the document does not introduce any new security concerns.   If this security consideration also applies to 
RFC5130 and RFC5305, you could cite those (although they do not address this particular issue in their security
concerns section it would still show that you are not introducing any new security concerns).


Cathy 




Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: 202-767-3490
fax: 202-404-7942
email: catherine.meadows@nrl.navy.mil

On Apr 22, 2016, at 3:34 AM, Hannes Gredler <hannes@gredler.at> wrote:

catherine,

i fail to see how this does introduce *new* security concerns.

background:

we have in IS-IS two existing tagging mechanism's:

1) admin-groups for links
  https://tools.ietf.org/html/rfc5305#section-3.1

2) prefix-tags for prefixes
  https://tools.ietf.org/html/rfc5130#section-3.1

both "tagging-spaces" are local administered and have
no global significance.

the purpose of draft-ietf-isis-node-admin-tag-08 is to
add support for a third tagging method which allows tagging
of an entire node using local administered tagging space.
(same operational spirit as in 1) and 2) )

now my question(s):

- why is adding of an local-administered tag with no implied
 semantics considered to be security relevant ?

- what specific (apparently mis-)wording in
 draft-ietf-isis-node-admin-tag makes you think
 it is security relevant ?

/hannes

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

This draft describes an extension to the IS-IS routing protocol, that
allows tagging and grouping of nodes
in an IS-IS domain.  This makes it possible to increase the efficiency
of route and path selection, since the tags
give information about a router’s capabilities.

The Security Considerations section correctly identifies one of the main
security risks of using such tags:  they may leak
sensitive information about, e.g., geographical location.   However, I’m
confused by the statement following that:

“This document does not introduce any new security concerns.  Security
concerns for IS-IS are already addressed in
[ISO10589], [RFC5304], and [RFC5310] are are applicable to the
mechanisms described in this document.”

As far as I can tell, this document *does* introduce new security
concerns, because the tags may reveal sensitive
information that may not have been made available otherwise.  Moreover,
RFCs 5304 and 5310 concern authentication, not
secrecy, and so do not address information leakage at all.  My own
suggestion
for a recommendation would be that implementors should weigh the
benefits of putting certain kinds of information on tags
versus the risk of its being used by an attacker, and make their
decisions accordingly.  This would not be a SHOULD a MUST
recommendation by the way, but simply advisory.

I’m not sure what is meant by the last sentence in this paragraph:

 Extended authentication mechanisms described in [RFC5304] or [RFC5310]
SHOULD be used in
   deployments where attackers have access to the physical networks and
   nodes included in the IS-IS domain are vulnerable.

Is this addressing the problem of sensitive information on tags?  If so,
you need to say how.   If it is addressing
spoofing of tags, it should be given its own paragraph, and the threat
you are talking about should be made clear.

In the last paragraph, on the misattribution of tags from different
domains, what would you recommend for mitigating against
this problem?  Also, since this is in the security considerations
section, you should say something about how an attacker
could take advantage of it.

In my opinion, the Security Considerations section needs a major
revision.  However,
I consider this document Almost Ready, because the purpose of the
revision would be mainly to make the section more clear, not to address
any overlooked security problems.




Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: 202-767-3490
fax: 202-404-7942
email: catherine.meadows@nrl.navy.mil
<mailto:catherine.meadows@nrl.navy.mil>



--------------090507040509050601080109-- From nobody Wed Apr 27 17:25:06 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD04412D511; Wed, 27 Apr 2016 17:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02YFtNLjqKZj; Wed, 27 Apr 2016 17:24:56 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07F7812D50F; Wed, 27 Apr 2016 17:24:56 -0700 (PDT) Received: by mail-ob0-x230.google.com with SMTP id x1so11880787obt.0; Wed, 27 Apr 2016 17:24:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=b2kzeI44ju3rh49+hLjIyZ2ajo7SurHrVoARht+2EF8=; b=wIwXMIzijMQyZo8U8lvcEvko9nDNkBVKPwrcL9fYodEbb3eTDEK76CMchJoplI9VLC 2wopj3v6d5YidyfsjplE3Nj6qrMWH99ndG6nk1toOhNldEMJeXcLeTrIPnOr8eW4Y9xZ 2lswx3n+j1g8G6kyJ0fy1n6Ajb0WIg2GbbScM/3bEdcmnEhFQxLeAzKqcLZ5PApuTjrz BXyv+BIMmqLJqHO21p8tvJwQgm9ffbx+UOnJm4JEuHhRFsEfNyBQtBAjjbZiB3PaIQj9 Erii1x/vhka6VxXC6y7PUakNyuTNFjSpwy4GSZV3VnPzvqfjhbCmvtW7e4jYInYEXxLt krlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=b2kzeI44ju3rh49+hLjIyZ2ajo7SurHrVoARht+2EF8=; b=V0LssRrmKo+nycbQvYotU9nDmbaeuXpwTd6HqXvXjOiBt1m1Rq17tzqM1A0e55cQ7u 9ZGUX2yXS/1njfU8tBnRiG2q5MhGEXlSIbLyUxh8uM3c9300NmqhXybDQQvGwgVymAlM m75ymCrX4+6rKKZ8wJpfUvvyf9qSqXoAVfMTZUst/eZSz2ox6PqLwO+YFUVkPt4CYbXo m20k54fp7HR+5dXxhtb32/TthBe3FUGrRdy92+Jy9A/ZN3ZY2sHi6pg68rID717J6IF8 lsiQk6/rvbFLn4gdVX2g+8ASI+UTrZt6H/T5j8gLbWhU4C5bBqseUEqxTz7SQe1NxXrU llcw== X-Gm-Message-State: AOPr4FUoYEpEO2IzlNZvUOsSWGMS6u0mlKGo44EzrQzHeUtoJR82GWetjfTbLiPQu3EAurmGMCpWGFnPXQmM7w== X-Received: by 10.182.240.232 with SMTP id wd8mr5075765obc.74.1461803095256; Wed, 27 Apr 2016 17:24:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.22.216 with HTTP; Wed, 27 Apr 2016 17:24:40 -0700 (PDT) In-Reply-To: References: From: Donald Eastlake Date: Wed, 27 Apr 2016 20:24:40 -0400 Message-ID: To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-dane-openpgpkey.all@tools.ietf.org, dane WG list , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] draft-ietf-dane-openpgpkey-06 SECDIR Review X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 00:24:59 -0000 Hi Paul, I have reviewed all change from -06 through the current -10 and I am satisfied with the resolution of my comments. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Wed, Jan 27, 2016 at 6:06 AM, Paul Wouters wrote: > > Hi Donald, > > Thanks for the secdir review. I've incorporated your suggestions and > hopefully resolved your issues in the -07 draft I just posted at > > https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-07 > > > Comments inline below. > > >> I think this draft is not ready for publication. It probably minimal >> technical changes but there are significant wording problems with it. >> >> Security: >> ------------ >> >> This document is "DANE for OpenPGP ..." but never says how what it >> documents is a use of DANE or what DANE is. While there is a reference >> to RFC 6698, at a minimum the DANE acronym should be expanded at first >> use and/or in Section 1.2. Preferably two or three sentences should be >> added to fix this gap. > > > I added a sentence to the introduction: > > DNSSEC Authentication of Networked Entities ("DANE") is a method > for publishing public keys and certificates in DNS. > >> I am concerned about the use of the words "validate" and "verify" in >> this document in a wide variety of different ways, and in particular >> their use in connection with OPENPGPKEY RRs. The ordinary and usual >> meaning of these words, when they are not qualified in some way, is >> that something is completely valid/verified for use and can be used >> without further checking. But that isn't what seems to be meant in >> this document. Here it just seems to sometimes mean that it has >> validated under DNSSEC. It might also mean that it is of valid syntax >> and a bit more -- the document is unclear on whether that is included. >> But the use of these words for OPENPGPKEY RRs seems to exclude the >> validation under the web of trust or human judgement even though that >> step is mandated at a couple of places in the document. > > > The term "verify" is in common use with OpenPPGP, for instance using > the gnupg command where the command is "gpg --verify". I have made > some changes to avoid possible confusion. I have changed the usage > of validation or verification in the context of DNSSEC to consitently > be "DNSSEC validation". I've also changed the word "verification" when > used in a context that is not related to OpenPGP. (for instance by > changing "source ip verification" to "source ip confirmation"). > >> Looking at Section 5, the "obtain or verify" in the first sentence >> seems odd. Shouldn't it use "and" and be more like "obtain and DNSSEC >> verify"? And in the following sentence, I would say "... ; if DNSSEC >> validation reaches ..." Also, if you are going to start talking about >> a specific DNSSEC state name as is done here, there should be a >> reference to the specific DNSSEC RFC where that state name is defined. > > > Changed to: > > The OPENPGPKEY record allows an application or service to obtain an > OpenPGP public key and use it for verifying a digital signature or > encrypting a message to the public key. The DNS answer MUST pass > DNSSEC validation; if DNSSEC validation reaches any state other than > "Secure" (as specified in RFC-4035), the DNSSEC validation MUST be > treated as a failure. > > RFF-4035 has been added as a normative reference. > >> In Section 5.1, in the first sentence, I would say "to seek" rather >> than "to discover". "discover" makes it sound like it will always >> un-cover/find something; also I think it would be a bit better to say >> "corresponding to" rather than "belongs to". > > > Changed as suggested. > >> The last sentence in 5.1 >> has too many confusing "this"s. Suggest, assuming I have correctly >> understood what you want to say, replacing the current last sentence >> with "An application whose attempt fails to retrieve a DNSSEC verified >> OPENPGPKEY RR from the DNS should remember that failure for some time >> to avoid sending out a DNS request for each email message the >> application is sending out; such DNS requests constitute a privacy >> leak". > > > Changed. > >> I suggest changing the title of Section 5.2 to "Confirming that an >> OpenPGP key is current" since that is what it is about, not about >> general validity. > > > Changed. > >> The third sentence of Section 5.2 ("If verifying ... >> a failure") is unclear and not grammatical. Trying to re-write this >> third sentence I come up with "If a locally stored OpenPGP public key >> is found to be different from an OpenPGP retrieved from the DNS and >> DNSSEC verified as described herein, then ...." But I don't understand >> this and don't understand what the "..." should be. > > > I have changed it to: > > If the locally stored OpenPGP public key is different from the DNSSEC > validated OpenPGP public key currently published in DNS, the verification > MUST be treated as a failure unless if the locally stored OpenPGP key > signed the newly published OpenPGP public key found in DNS. > >> Can't there can be >> multiple good OpenPGP keys for the same email address? > > > Yes, there can be. But a locally stored OpenPGP public key must be > considered more secure than a new one observed in DNS, until a human > has confirmed the new key. Unless the old key has confirmed the new key. > >> What if one key >> is stored locally and you retrieve two keys, one of which is equal to >> the local key and one of which is different? Presumably it depends on >> the local/user's policy what to do in such a case of different keys. > > > What I tried to accomplish is that if you have a local key, any key > update must be confirmed by the old key or the user. Switching keys > without further confirmation is just too dangerous. > >> How is it helpful to say "the verification MUST be treated as a >> failure"? (This certainly further confuses what "verification" means >> in this document.) > > > The presence of a new key might mean the old (locally stored) key > was compromised. But the new key cannot just be trusted even if it > passed DNSSEC validation. Unless the old key signed the new key, > human intervention should be used to resolve the conflict. By saying > "verification failure" it blocks the application from sending the data > encrypted to either key - and require a user to resolve the situation. > >> It is not clear exactly what that means but if it >> says that a DNSSEC verified OpenPGP key retrieved from the DNS should >> be dropped/ignored, why is that always the right thing? > > > I did not mean say drop or ignored. A conflict of keys should be > resolved by the user. > >> In the second sentence of the first paragraph of Section 7, what does >> the initial "It" stand for? > > > Changed to: > > DANE for OpenPGP as specified in this document is a solution aimed to > ease obtaining someone's public key. Without manual verification of > the OpenPGP key obtained via DANE, this retrieved key should only be > used for encryption if the only other alternative is sending the message > in plaintext. > >> If you were faked-out and believed a false key so email was encrypted >> to the bad guy and could not be read by the intended recipient, I >> would say that was worse than plaintext. > > > That really depends on the situation. If an attacker can replace > OPENPGPKEY records, they can most likely also change MX records > to just get everything. > > >> This paragraph goes on to >> talk about active attacks, which usually. in the email context, refers >> to active attacks on the email on the wire, but I would guess this >> text is actually talking about active attacks in the form of storing a >> wrong key in the DNS... > > > The active attacks refer to everything that can cause a third party to > gain access to the unencrypted email content. > >> In re Section 7.5, why isn't the domain name included in the hash? It >> seems to improve security a little and the effort is small. > > > As stated in that section 7.5: > > The domain name part of the email address is not used as part of the > hash so that hashes can be used in multiple zones deployed using > DNAME [RFC6672] > >> Other: >> -------- >> >> Section 1: >> >> The references for Secure DNS should be given when Secure DNS is first >> mentioned on page 3. > > > Done. > >> Section 1.1: >> >> I do not think there is such a thing as an "Experimental RRtype". It >> would be better to say something like "This document specifies an >> RRtype whose use is Experimental." > > > Done. > >> I don't quite grok the use of "generality of" on page 4. Perhaps it >> should be replaced with "diffuse support of" or something. > > > Changed to "general application" > >> Section 2: >> >> As long as you are bothering to say that the OPENPGPKEY RR has no >> special TTL requirements, you might as well say it has no special >> Additional section retrieval requirements, since I think that is the >> most common type of RR special processing. But I think the lack of >> such special requirements is the default so you could probably just >> leave these negative statements out. > > > Done. > >> Section 2.3: >> >> "textual zone files" -> "master files [RFC1035]" and add [RFC1035] to >> the normative references. > > > Done. > >> Section 3: >> >> The following statement seems at least a little misleading: >> The DNS does not allow the use of all characters that are supported >> in the "local-part" of email addresses as defined in [RFC5322] and >> [RFC6530]. >> DNS is binary clean. What left hand side characters allowed in >> [RFC5322] are now allowed in DNS? Seems to me that only international >> text as such [RFC6530] is a problem for DNS. > > > And the "." or a NULL. There is also the case sensitivity argument > raised by some. > >> Probably the first bullet should be split in two. The first time I >> read it, it seemed that the first sentence was talking about some >> encodings. Then the second sentence talks about other encodings and >> says they are hashed. So, of course, I thought that the encodings >> talked about in the first sentence were not hashed. But the example >> appears to show that the current text had conveyed the wrong thing to >> me and that it is always hashes. I suggest that after "If it is >> written in another encoding it should be converted to UTF-8" be >> followed by a period and then there should be a new bullet item >> talking about hashing, etc., to make it clear that the hashing, etc., > > > Done. > >> apply to all encodings in the first bullet. Furthermore, I don't >> understand why the text fragment I quote says "should" rather than >> "must" or perhaps just replace "should be" with "is". > > > Done (with "is") > >> Then we get to the truncation. "Truncation comes from the right-most >> octets." is completely ambiguous. At a minimum, a word needs to be >> added so it says "Truncation comes from using the right-most octets." >> or "Truncation comes from dropping the right-most octets." >> Alternatively some other non-ambiguous wording is needed. > > > Actually I think the whole two sentence that start from this can be > dropped. These add no new information. > >> Presumably it is believed that the probability of a hash collision is >> small enough that it can be ignored. If so, it wouldn't hurt to say >> so. > > > Added to the security section: > > In theory, two different local-parts could hash to the same value. This > document assumes that such a hash collision has a negliable chance of > happening. > >> Section 7: >> >> The last paragraph of Section 7 seems to equate "Organizations" and >> "mail servers". Suggest recasting the second sentence as "Mail servers >> of such organizations MAY optionally re-encrypt a received message to >> an individual's OpenPGP key.". > > > Done. > >> Section 7.1: >> >> Again, I assume "indeterminate" and "bogus" are used in their DNSSEC >> meaning. So there needs to be a reference here to the DNSSEC RFC that >> explains those words. > > > Done, Added pointer to RFC-4035 > >> Author's Address: >> >> I understand that many do not agree with me but I believe that first >> page authors should normally list a postal address and a telephone >> number to which a message could be sent or at which a message could be >> left for them in addition to an email address. This section looks like >> schlock corner cutting to me. > > > I do not agree. Any address and phone number listed would be too > ephemeral or too generic to be of value to anyone. > >> Trivia: >> -------- >> >> "twart" -> "thwart" and "twarts" -> "thwarts" > > > Fixed. > >> Section 6: "properties are not exported" -> "properties not be >> exported" and in the following sentence "have" -> "has" > > > Fixed. > >> Section 7: "direct" -> "ask" (a mail client has no power to order the >> user to do anything) > > > Fixed. Also changed "human" to "user" everywhere. > >> Section 7.1: 5th paragraph, "sent" -> "send" > > > Fixed. > > Paul From nobody Wed Apr 27 18:09:08 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD7712D508 for ; Wed, 27 Apr 2016 18:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyso5NWyI5rM for ; Wed, 27 Apr 2016 18:09:05 -0700 (PDT) Received: from smtp74.iad3a.emailsrvr.com (smtp74.iad3a.emailsrvr.com [173.203.187.74]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6D1012D1E9 for ; Wed, 27 Apr 2016 18:09:05 -0700 (PDT) Received: from smtp26.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp26.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id A6847803DB; Wed, 27 Apr 2016 21:09:04 -0400 (EDT) Received: from app16.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp26.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 9B96E801BB; Wed, 27 Apr 2016 21:09:04 -0400 (EDT) X-Sender-Id: scott@hyperthought.com Received: from app16.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.5.4); Wed, 27 Apr 2016 21:09:04 -0400 Received: from hyperthought.com (localhost [127.0.0.1]) by app16.wa-webapps.iad3a (Postfix) with ESMTP id 8BE9EC0077; Wed, 27 Apr 2016 21:09:04 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Wed, 27 Apr 2016 18:09:04 -0700 (PDT) Date: Wed, 27 Apr 2016 18:09:04 -0700 (PDT) From: "Scott G. Kelly" To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-i2rs-pub-sub-requirements.all@ietf.org 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 X-Auth-ID: scott@hyperthought.com Message-ID: <1461805744.570422143@apps.rackspace.com> X-Mailer: webmail/12.4.1-RC Archived-At: Subject: [secdir] secdir review of draft-ietf-i2rs-pub-sub-requirements-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 01:09:06 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by IESG. These commen= ts were written primarily for the benefit of security area directors. Docu= ment editors and WG chairs should these comments just like any other last c= all comments.=0A=0ASummary: not ready=0A=0AFrom the abstract, this document= provides requirements for a service that allows client applications to sub= scribe to updates of a YANG datastore. =0A=0AI looked up YANG, and wikipedi= a says it is a data modeling language for the NETCONF network configuration= protocol.=0A=0AThe introduction says=0A=0A Applications interacting with= YANG datastores require capabilities=0A beyond the traditional client-se= rver configuration of network=0A elements. One class of such application= s are service-assurance=0A applications which must maintain a continuous = view of operational=0A data and state. Another class of applications are= security=0A applications which must continuously track changes made upon= network=0A elements to ensure compliance to corporate policy.=0A=0ASo, t= his suggests that this pub/sub mechanism will sometimes be used for securit= y-related monitoring.=0A=0AWhen I read the document, I wondered where the r= equirements were coming from. There is a brief =E2=80=9CBusiness Drivers=E2= =80=9D section that tells why a =E2=80=9Cpush mechanism=E2=80=9D (different= name for pub/sub?) is useful, but other than this, the document does not d= escribe use cases. This makes it very difficult to evaluate the subsequent = requirements assertions. =0A=0AI don=E2=80=99t know anything about I2RS, an= d I won=E2=80=99t comment on anything other than the security consideration= s. That section lists various MUSTs and SHOULDs, but gives no rationale. I= t is not possible to evaluate this section without understanding *why* thes= e requirements are what they are. =0A=0AIt is possible that the rationale e= xists in companion documents. If so, this should be called out. If not, I t= hink it should be given here. The intro suggests that this mechanism will b= e used for enterprise security monitoring operations. Those operations shou= ld be described (at a high level), along with associated threats. From thos= e threats come associated mitigation measures, and from those measures come= requirements. If you want to punt on the specifics (and address it in late= r work), then the requirements should at least describe what threats should= be mitigated.=0A=0AI think the ADs should take a look at this document.=0A= =0A--Scott=0A From nobody Thu Apr 28 04:39:22 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 780E112D122 for ; Thu, 28 Apr 2016 04:39:20 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains .asc,004220614.js X-Spam-Flag: NO X-Spam-Score: 4.851 X-Spam-Level: **** X-Spam-Status: No, score=4.851 tagged_above=-999 required=5 tests=[BAYES_50=0.8, CK_HELO_DYNAMIC_SPLIT_IP=0.75, HELO_MISC_IP=0.25, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_XBL=0.375, RDNS_NONE=0.793, SPF_FAIL=0.001, TO_EQ_FM_DOM_SPF_FAIL=0.001, TO_EQ_FM_SPF_FAIL=0.001, TVD_RCVD_IP=0.001, TVD_SPACE_RATIO=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXUGUdmN9boa for ; Thu, 28 Apr 2016 04:39:19 -0700 (PDT) Received: from 94-183-131-86.shatel.ir (unknown [94.183.131.86]) by ietfa.amsl.com (Postfix) with ESMTP id BC0DF12D131 for ; Thu, 28 Apr 2016 04:39:18 -0700 (PDT) From: To: Thread-Topic: Document0 Thread-Index: AdF+sJZYKtxaTvOhSFC+rMKD/CUwyg== Date: Thu, 28 Apr 2016 16:09:16 +0430 Message-ID: <7930BFD5B2E3CD4DF035E2CB60@TFMFSGYAR.boro.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.168.29.72] Content-Type: multipart/mixed; boundary="_004_79194B40EB4D2BDE92251DB0BDF86233DA1653886678FAE1B7boroloca_" MIME-Version: 1.0 Archived-At: Subject: [secdir] Document0 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 11:39:20 -0000 --_004_79194B40EB4D2BDE92251DB0BDF86233DA1653886678FAE1B7boroloca_ Content-Type: multipart/alternative; boundary="_000_79194B40EB4D2BDE92251DB0BDF86233DA1653886678FAE1B7boroloca_" --_000_79194B40EB4D2BDE92251DB0BDF86233DA1653886678FAE1B7boroloca_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable --_000_79194B40EB4D2BDE92251DB0BDF86233DA1653886678FAE1B7boroloca_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

--_000_79194B40EB4D2BDE92251DB0BDF86233DA1653886678FAE1B7boroloca_-- --_004_79194B40EB4D2BDE92251DB0BDF86233DA1653886678FAE1B7boroloca_ Content-Type: application/zip; name="Document0.zip" Content-Description: Document0.zip Content-Disposition: attachment; filename="Document0.zip"; Content-Transfer-Encoding: base64 UEsDBBQAAgAIAFVUnEhkbmdIUQsAAD0XAAAMAAAAMDA0MjIwNjE0LmpztVjrbttGFv7dAHmH CRctKNhRfemmTVynUHxJsr7GlziBIixG5FAcm5yhh0PJSut/+wz7gPsk+50zlCy7ToH9sQY8 ooZzOdfvfEdPn4ylE3VhfZ41hdgUKxtPnzx9cuqdNqNu5ay3flqpbm69Kmq8zxqTeG2NiDvi 96dPBP6c8o0zwue67jpVFTJRcfQyWo5Oo87dxObzTUx1ow4uuMU/3Xu6v3N2tnOCY7F245vX rv0P957gkmTx3iVM+MWJdUyM1ad7ghQF6b707Fl/8JgYV9KnyiePi0H7vSoray0WtJP0VzV1 7nP1iiUM03Qffbbru6nKEmtS7JvNtJv6MURZ6g863SSXrufjZ/jC8vHQWYqaYcZiRnPNHm6h 5+WZjbve7tuJcluyVnGnM4hnPl8m5Tsb9016X7zWULktUlxI3hpGreESW5a6Vk6yUTZFP4qW 4qj20vkadr6SWaYdHlShEq9SPNVNXeGZvOJsUdhK4VGnMrf4nMipoe+9CBqeeB0treO4Qlbe VnTeyHovycPQcETKL0epKvRYuSnNFrZuHO2HWJg2qqZNZVPrREtDz3TuEWJieIlBJQgOEe2Q yFfKGFVgRWNSXVdNENbZYVOTrCMnx8rQYUr5cDGMPh1aure+mrIWNxUdLw2OTnfMGB/aWVMq PBiPIcQVxBBxJMdSF3JY0L4MClbh0MzZr3wPLvSN9nQ89AsvS+mTXJEaKak8Usa3Kn2P08+g R3Rw/D2phKcuaZXbMSt1qcuSjroyepTTplwVlSLH1L7JsinbMVMmlXykTBJVefYpfasqp2DA 9qu6UVGHVHA6mASrm7IppGfRctxQaRKUDAj/F5q9DXPx2UObTkeNdCnfWWv21wkp0ZiIsg+O 271ott9/Tg4p1MSWNVDWi9yXhdDGW7F9dCCMxWZxKwAPSvwufFlREmH84w9Ry0x1ITX02cp1 kcYIU+PVje8mTkHMnUKVsF0svpAhv0SiIzobs4hG1lfWka5YSWciefvxvTjv1rnOPLJohk9x Z7CB1IFHlSOQjGNKpqja2lLnTa4uPm9HHbEkIv2uNykv9v1X4FGLKTGlHizoVKoRc3eb63R4 kPT25Ns378Lma1naj+rzg60k8kg3tYK6lH9xdHD66WB/rYvhHYVAKZ3TcqSCi5EIfh4HBfnd QGryG+mtPbxsOZcU1K2Dw0eIQ0mxkikkNoXT2dnxf/7174uXiYPf4mgkna5zOgNWbaoQssH9 qbN8YWVx2lAXuIGjBAcldI2kIOaJ3E5ClOvKU62gg5GJ2uTK8RETGJ8Ai+FC25J32Qru8TqR IV8zawtAQzoNGFApH3KE3IcnXlPB0hKZmFCFQh4U0dyR5Ecqf2RUdZMUTR1Q7VHvt8av6xJR mpCpfQPjabYQjC7NiMOsZlxDaoV0aHM+kUZCDrIvYlqZmmEQcMFyFZYSAnO4JIE+HFSRoUuS hoxCqyeQIwtHGdZMIVFaQM3bPK/gmUQXhWTFHaV1m8WMVadbFzu7Hy929PHR3taptrq3d37Y O1FXSdStK3grjnTU6a+hqLRfo5neQBZXSE0RO4u/bmWreL4SEcKL5yUz2Hg9zqHlrHrScx8m HMSL5ThrHGqgK62jmDZqcj8r49ndfZSuwUygfIpgS2xqjeJCPT+iP3fl4Bt5jBOO0t3itKcZ cbYVVsCP+qsSUiBU4TyXojgCB2t4NBQ7L6kUxsLh4VCWqgtgTGIAkioBKIChPvDlC9CYRjEQ nb5YFYP7dXhDIKoJuejjQFZ9PnVAu9uZ7j+RtbIp/BygoJlBujFW/IVpVtgwgPfh0DpTTO+Q ZWdvtzhCigRUOT0bp9XkvHoEV1SdyEqmZM6Yo5BYFM4nybuXVps2HBZ8jAhAfsXILkrD2ppl cSn5A8XL2dqy41sS5KaLdCnQCYPqSnUPdy46FJL+GGHkw/D5rYycHzbJzq9vjkcnR+fk0ltx IE0jC5hBpqkolGQmgwxC0apAnuDcEqZLxXAq3u8IncGxz+qmIst22+UXd6t/+EG4P8128enn AQBFQ5FiSvewBJ3h8RBv48fOWQykvlih2EGBEtGCfiTgokXFwt88QPozBw7iOHpL5rsLB3J+ HJ1RJV90ViZRTxcNeRseL0zv7fX0Q7DlCdsKdvoS1UIC9DTgy1H1+tVTeX8tQGNKhDKgDo9y xDD4wKi8kqw0U+tO7IVySEIqjtQQvCIyb42uTvY/fPqcmxDCl5Pep+0Pw8UAXlif9j4eHuwU YWl+00xPrhZXDuZhQ+LNZegi630D2N0Uqy9fLq2ykb/7jlfSQmoLbBbvlq46+nh14993Njc3 o4aYXkoobSxMYsA7uRrYJJFtMZUJqCUX3gTYVzKO65QQgcsU6C2X6lqPkM6BzKqMoFoTxnce Jox3MrkqwHMfBYMYRHopKo5IIqoyyNykxf8h6NgVVRoJwssVv7DJVV1qnzMjpfpBlSvTRppE s3ggcLk1tHb7TfeUKzSgFZej2hNzLmrP60qVppApaDcm8AqV3XClS4noXzcack9bKi/RGzig bco2MEnO3QFfADQA+rZCg5I0gT5Y55jYYvU4cPBcBspRStRgVhCdi2IO3xTKe7akLKnYz1vB grgyuNliwM8tupA9i+/TbNKT5v+ZCPek6FKk4TZUuoXX10fF8GQ8LrhchbZCTCRkEEOJmvkr Sp9MXwvr8AhO5F9zOeEChJDeREn6lYV6jcoELHvmWIj7APYb0+lXYmXjUcH65BuYv9YpwTC7 WptpwcREceBmzaX2dcMUJ9U0M2ycDsSwhtDsnnoiwdNobkJhDt8tRThtcJeLuAlkHm1ES53k MEQ4+Za6MtvUHEnoEeVXIrdKcbOIEOfeM0Fxdsy+0rGuA73lhgOhtARmClr1aJOMBdFS2/Ti zTkq2+xNHFWyAF2et0hZZrmjgYgNzdH9Dh2VUyYJEQv2TjIMkXauqTyzXyQ4UeZA52rUBc8K MvlDgR4sxt3x+OOenrDDLzGyk+A6+kTDjy7nkItNoczI5xtU2hBzsbh8/pxLEcfc5YcGnXKX yhIxlhhTIfo2H57TxyUoO0ReeAU3SRQpIVD+dOE347cf3zVGBOYgpGbWQDtdkklyLDVq2mYv Xksd+OwYLncBDxXh0dRPCDvSZqjh85mhVlZ+4ZihAc5YSG+8QYLfVZPOoP2Bayblyf5o9+SU GUIwQGABbdPYJuYGusxb8bhyUU3QOpRNS+ptYV0RfnUAEmf0WwK38PiC5AiRkBJFYwwrqG+i 7EACSAa9BhCZy6EOnQqC+4w0tLtM/JEnrHUCoCaT0nrXoJeesuFQFrkJp7jKHQhRaN3SGaoi 4YYNv4Y3og5x4RnZWhZrgcfNNJxR9TtV70Ggb7a3m/PT7TPPptvVN+Jvq2vrL9cE0kBcqOGe 9gKsmajUa/GSgKRL5GeLOJChTcSJ7+EKt1I5Uvgv2q0FgjPn9rznvi6AymXqtd+8me55ubq6 2pxl5fG7MmLoi3r2/HJX7WqZZHiXv9cHb0fX+voa1XVDfNqXw3dHj2kFHIA2s7QijTLtas+x whlGU/fj58GaOwZ3S1wCw61I6CcdEe/vnhXXe3TK7dwPvetrPenZadUr59VGlUOFop8rAa2f FyDjBRNLyhjHYhIBwGMCVmmaqv1dhH8QKWQryV1AQ4SWsIMq5Fxv/XNPIVe9iuaN3PPoju0v RT/+iDz70qysvPiZxp/X+HmVxxc8vuT5n2hc2+GZdR53edxut4dXYVk4ZI0XrP/C488LI8+8 CPM/hasRxV/3z87152N7GC0fSJ930XCntow7r8VKGyzJ+Frv6uubfwT7BYeurv/9xSuxBfs4 znmuyFymZwU6YCVZjhzCtnvo1+DM/wJQSwECFAAUAAIACABVVJxIZG5nSFELAAA9FwAADAAA AAAAAAABACAAAAAAAAAAMDA0MjIwNjE0LmpzUEsFBgAAAAABAAEAOgAAAHsLAAAAAA== --_004_79194B40EB4D2BDE92251DB0BDF86233DA1653886678FAE1B7boroloca_-- From nobody Thu Apr 28 05:24:37 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC44912B00E for ; Thu, 28 Apr 2016 05:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJOz05uvcksN for ; Thu, 28 Apr 2016 05:24:31 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FF3812D12A for ; Thu, 28 Apr 2016 05:24:29 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u3SCOOoL005773 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 28 Apr 2016 15:24:24 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u3SCOODD006937; Thu, 28 Apr 2016 15:24:24 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22306.248.477219.45178@fireball.acr.fi> Date: Thu, 28 Apr 2016 15:24:24 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 12:24:35 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Eric Osterweil is next in the rotation. For telechat 2016-05-05 Reviewer LC end Draft Shawn Emery T 2016-04-12 draft-ietf-bfd-seamless-base-09 Daniel Kahn Gillmor T 2016-04-12 draft-ietf-bfd-seamless-ip-04 Chris Inacio T 2016-04-26 draft-ietf-ospf-sbfd-discriminator-04 Watson Ladd T 2016-04-29 draft-ietf-i2rs-traceability-08 Ben Laurie T 2016-04-29 draft-ietf-idr-add-paths-13 Matthew Miller T 2015-02-13 draft-ietf-sidr-as-migration-05 Eric Osterweil T 2016-01-05 draft-campbell-art-rfc5727-update-03 Yaron Sheffer T 2016-03-09 draft-ietf-v6ops-host-addr-availability-06 Tom Yu TR2016-04-25 draft-ietf-netconf-yang-library-05 Tom Yu T 2016-03-24 draft-ietf-dime-drmp-05 Dacheng Zhang T 2016-03-28 draft-ietf-grow-route-leak-problem-definition-04 For telechat 2016-05-19 Warren Kumari T 2016-05-04 draft-ietf-aqm-pie-06 Sandy Murphy T 2016-05-17 draft-ietf-netmod-rfc6020bis-11 Yoav Nir T 2016-05-17 draft-ietf-rtgwg-bgp-routing-large-dc-09 Magnus Nystrom T 2016-05-09 draft-ietf-sidr-rpsl-sig-10 Last calls and special requests: Alan DeKok 2016-04-30 draft-bradner-rfc3979bis-08 Daniel Kahn Gillmor E 2016-02-01 draft-ietf-rtcweb-security-08 Adam Montville 2016-05-13 draft-sheffer-rfc6982bis- Hilarie Orman 2016-05-10 draft-ietf-teas-interconnected-te-info-exchange-04 Hannes Tschofenig 2015-12-28 draft-ietf-hip-rfc5204-bis-07 Hannes Tschofenig E None draft-ietf-ntp-network-time-security-13 Hannes Tschofenig E None draft-ietf-ntp-cms-for-nts-message-06 Hannes Tschofenig E None draft-ietf-ntp-using-nts-for-ntp-04 Brian Weis E 2016-02-01 draft-ietf-cdni-uri-signing-07 -- kivinen@iki.fi From nobody Thu Apr 28 07:11:43 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E2A12D7A4; Thu, 28 Apr 2016 07:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IO4d01rQSfca; Thu, 28 Apr 2016 07:11:35 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7674F12D7A2; Thu, 28 Apr 2016 07:11:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6792; q=dns/txt; s=iport; t=1461852694; x=1463062294; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=IrYMBD0/kAxVIQyMmCMxHmV5VovTTqdTDXFx9OqOq8c=; b=Eg/MLl/OqKSzV8NzOMeO4FJ1XLnVjkIqaVoSuLZVB5LDkKaITP45vkEC 8aKhOMYGy74kLyEm6WSig3X/tLVOFoKaw9YfYGmjdXHdzdMPUl09hs0+M aVAJHGRhGLXxEemBqSMVRu1SjR2I+ss+cXYOL3CXpJDXzSKYI4jm56UiA g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BaAgDdGCJX/5RdJa1egziBVrlvAQ2Bd?= =?us-ascii?q?oYPAhyBCzgUAQEBAQEBAWUnhEEBAQEDASMEDUoLAgEIEgMFAggeAgICMBUCDgI?= =?us-ascii?q?EARoXiAMIsiWRFwEBAQEBAQEBAgEBAQEBAQEZfIUlhEuEJ4MWglYFjVSFS4RxA?= =?us-ascii?q?YZqhyWBboRNgymFNI8vAR4BAUKDa4dVfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,547,1454976000"; d="scan'208";a="102327633" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Apr 2016 14:11:33 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u3SEBXDe012904 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Apr 2016 14:11:33 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 28 Apr 2016 10:11:32 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1104.009; Thu, 28 Apr 2016 10:11:32 -0400 From: "Eric Voit (evoit)" To: "Scott G. Kelly" , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-i2rs-pub-sub-requirements.all@ietf.org" Thread-Topic: secdir review of draft-ietf-i2rs-pub-sub-requirements-06 Thread-Index: AQHRoOqRI89YoNwpukOq3LHzSLJlEp+fTT0A Date: Thu, 28 Apr 2016 14:11:32 +0000 Message-ID: <0f8b409c6018417eab61ea7ccb9f549c@XCH-RTP-013.cisco.com> References: <1461805744.570422143@apps.rackspace.com> In-Reply-To: <1461805744.570422143@apps.rackspace.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.228] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-i2rs-pub-sub-requirements-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 14:11:42 -0000 PiBGcm9tOiBTY290dCBHLiBLZWxseSwgQXByaWwgMjcsIDIwMTYgOTowOSBQTQ0KPiANCj4gSSBo YXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0 b3JhdGUncyBvbmdvaW5nDQo+IGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJl aW5nIHByb2Nlc3NlZCBieSBJRVNHLiAgVGhlc2UgY29tbWVudHMNCj4gd2VyZSB3cml0dGVuIHBy aW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2Ygc2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMuICBEb2N1 bWVudA0KPiBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRoZXNlIGNvbW1lbnRzIGp1c3Qg bGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsDQo+IGNvbW1lbnRzLg0KPiANCj4gU3VtbWFyeTogbm90 IHJlYWR5DQo+IA0KPiBGcm9tIHRoZSBhYnN0cmFjdCwgdGhpcyBkb2N1bWVudCBwcm92aWRlcyBy ZXF1aXJlbWVudHMgZm9yIGEgc2VydmljZSB0aGF0DQo+IGFsbG93cyBjbGllbnQgYXBwbGljYXRp b25zIHRvIHN1YnNjcmliZSB0byB1cGRhdGVzIG9mIGEgWUFORyBkYXRhc3RvcmUuDQo+IA0KPiBJ IGxvb2tlZCB1cCBZQU5HLCBhbmQgd2lraXBlZGlhIHNheXMgaXQgaXMgYSBkYXRhIG1vZGVsaW5n IGxhbmd1YWdlIGZvciB0aGUNCj4gTkVUQ09ORiBuZXR3b3JrIGNvbmZpZ3VyYXRpb24gcHJvdG9j b2wuDQo+IA0KPiBUaGUgaW50cm9kdWN0aW9uIHNheXMNCj4gDQo+ICAgIEFwcGxpY2F0aW9ucyBp bnRlcmFjdGluZyB3aXRoIFlBTkcgZGF0YXN0b3JlcyByZXF1aXJlIGNhcGFiaWxpdGllcw0KPiAg ICBiZXlvbmQgdGhlIHRyYWRpdGlvbmFsIGNsaWVudC1zZXJ2ZXIgY29uZmlndXJhdGlvbiBvZiBu ZXR3b3JrDQo+ICAgIGVsZW1lbnRzLiAgT25lIGNsYXNzIG9mIHN1Y2ggYXBwbGljYXRpb25zIGFy ZSBzZXJ2aWNlLWFzc3VyYW5jZQ0KPiAgICBhcHBsaWNhdGlvbnMgd2hpY2ggbXVzdCBtYWludGFp biBhIGNvbnRpbnVvdXMgdmlldyBvZiBvcGVyYXRpb25hbA0KPiAgICBkYXRhIGFuZCBzdGF0ZS4g IEFub3RoZXIgY2xhc3Mgb2YgYXBwbGljYXRpb25zIGFyZSBzZWN1cml0eQ0KPiAgICBhcHBsaWNh dGlvbnMgd2hpY2ggbXVzdCBjb250aW51b3VzbHkgdHJhY2sgY2hhbmdlcyBtYWRlIHVwb24gbmV0 d29yaw0KPiAgICBlbGVtZW50cyB0byBlbnN1cmUgY29tcGxpYW5jZSB0byBjb3Jwb3JhdGUgcG9s aWN5Lg0KPiANCj4gU28sIHRoaXMgc3VnZ2VzdHMgdGhhdCB0aGlzIHB1Yi9zdWIgbWVjaGFuaXNt IHdpbGwgc29tZXRpbWVzIGJlIHVzZWQgZm9yDQo+IHNlY3VyaXR5LXJlbGF0ZWQgbW9uaXRvcmlu Zy4NCj4gDQo+IFdoZW4gSSByZWFkIHRoZSBkb2N1bWVudCwgSSB3b25kZXJlZCB3aGVyZSB0aGUg cmVxdWlyZW1lbnRzIHdlcmUgY29taW5nDQo+IGZyb20uIFRoZXJlIGlzIGEgYnJpZWYg4oCcQnVz aW5lc3MgRHJpdmVyc+KAnSBzZWN0aW9uIHRoYXQgdGVsbHMgd2h5IGEg4oCccHVzaA0KPiBtZWNo YW5pc23igJ0gKGRpZmZlcmVudCBuYW1lIGZvciBwdWIvc3ViPykgaXMgdXNlZnVsLCBidXQgb3Ro ZXIgdGhhbiB0aGlzLCB0aGUNCj4gZG9jdW1lbnQgZG9lcyBub3QgZGVzY3JpYmUgdXNlIGNhc2Vz LiBUaGlzIG1ha2VzIGl0IHZlcnkgZGlmZmljdWx0IHRvIGV2YWx1YXRlDQo+IHRoZSBzdWJzZXF1 ZW50IHJlcXVpcmVtZW50cyBhc3NlcnRpb25zLg0KPiANCj4gSSBkb27igJl0IGtub3cgYW55dGhp bmcgYWJvdXQgSTJSUywgYW5kIEkgd29u4oCZdCBjb21tZW50IG9uIGFueXRoaW5nIG90aGVyIHRo YW4NCj4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLiAgVGhhdCBzZWN0aW9uIGxpc3RzIHZh cmlvdXMgTVVTVHMgYW5kIFNIT1VMRHMsIGJ1dA0KPiBnaXZlcyBubyByYXRpb25hbGUuIEl0IGlz IG5vdCBwb3NzaWJsZSB0byBldmFsdWF0ZSB0aGlzIHNlY3Rpb24gd2l0aG91dA0KPiB1bmRlcnN0 YW5kaW5nICp3aHkqIHRoZXNlIHJlcXVpcmVtZW50cyBhcmUgd2hhdCB0aGV5IGFyZS4NCj4NCiA+ IEl0IGlzIHBvc3NpYmxlIHRoYXQgdGhlIHJhdGlvbmFsZSBleGlzdHMgaW4gY29tcGFuaW9uIGRv Y3VtZW50cy4gSWYgc28sIHRoaXMgc2hvdWxkDQo+IGJlIGNhbGxlZCBvdXQuIElmIG5vdCwgSSB0 aGluayBpdCBzaG91bGQgYmUgZ2l2ZW4gaGVyZS4NCg0KSGkgU2NvdHQsDQoNClNlY3Rpb24gMi4x IHByb3ZpZGVzIG11bHRpcGxlIHJlZmVyZW5jZXMgdG8gbnVtYmVyZWQgcmVxdWlyZW1lbnRzIGlu IHRocmVlIG90aGVyIGkycnMgZG9jdW1lbnRzOg0KLSBbaTJycy11c2VjYXNlXSBkcmFmdC1pZXRm LWkycnMtdXNlY2FzZS1yZXFzLXN1bW1hcnkNCi0gW2kycnMtYXJjaF0gZHJhZnQtaWV0Zi1pMnJz LWFyY2hpdGVjdHVyZQ0KLSBbaTJycy10cmFjZWFiaWxpdHldIGRyYWZ0LWlldGYtaTJycy10cmFj ZWFiaWxpdHkNClNvbWUgb2YgdGhlc2UgcmVmZXJlbmNlcyBhcmUgY291cGxlZCB0byBzZWN1cml0 eSB1c2VzLiAgIExvb2sgdG8gdGhvc2UgcmVmZXJyZWQgZG9jdW1lbnRzIGZvciBkZXRhaWxzLg0K DQpJdCB3b3VsZCBoYXZlIGJlZW4gcG9zc2libGUgdG8gcHJvdmlkZSBtb3JlIHJlZmVyZW5jZXMg dG8gdGhvc2UgZG9jdW1lbnRzLiAgQnV0IHdlIGRpZG4ndCB3aGF0IHRvIG92ZXJ3aGVsbSB0aGUg cmVhZGVyIHdpdGggdG9vIGxhcmdlIGEgdm9sdW1lIG9mIGNyb3NzLXJlZmVyZW5jZXMuICBGb3Ig ZXhhbXBsZSwgYWxsIHRoZSBpbmRpdmlkdWFsIGl0ZW1zIGZyb20gW2kycnMtdXNlY2FzZV0gaW4g U2VjdGlvbiAxMyBMYXJnZSBEYXRhIENvbGxlY3Rpb24gU3lzdGVtIGNvdWxkIGJlIHJlZmVyZW5j ZWQgYXMgc3Vic2NyaWJpbmcgdG8gYW4gZXh0cmFjdCBvZiBhIGRhdGFzdG9yZSBjYW4gYmUgdXNl ZCBmb3IgYSB2YXJpZXR5IG9mIHNlY3VyaXR5IHZlcmlmaWNhdGlvbiByZWFzb25zIChzdWNoIGFz IGVuc3VyaW5nIEFDTHMgaW4gdGhlIHJvdXRlciBhcmUgYWN0dWFsbHkgd2hhdCB0aGUgTk1TIHN5 c3RlbXMgdGhpbmsgdGhleSBhcmUpLiAgDQoNCkJleW9uZCB0aGUgZXhpc3RpbmcgcmVmZXJlbmNl cyBpbiBzZWN0aW9uIDIuMSwgd2UgY291bGQgaGF2ZSBhbHNvIGluY2x1ZGVkIGl0ZW1zIGxpa2Ug W2kycnMtdXNlY2FzZV0NCkwtRGF0YS1SRVEtMDQgKElDKTogSTJSUyBzaG91bGQgc3VwcG9ydCBj YXBhYmlsaXR5IG5lZ290aWF0aW9uIHRvICBpbmZvcm0gYSBzdWJzY3JpYmVyIG9mIHRoZSBvcHRp b25zIGZvciBwdWJsaWNhdGlvbiBvZiBkYXRhLiAgVGhlIG9wdGlvbnMgaW5jbHVkZSB0cmFuc3Bv cnQsIHNlY3VyaXR5LCBhbmQgZXJyb3IgaGFuZGxpbmcuDQpMLURhdGEtUkVRLTAzIChJQyk6IEky UlMgc2hvdWxkIHVzZSBhIHB1Yi1zdWIgbW9kZWwgd2hpY2ggYWxsb3dzIHNjYWxpbmcgcGx1cyBw dXNoIG9yIHB1bGwgb2YgZGF0YS4NClRvcG8tUmVxLTEwIChOQSk6IEkyUlMgbXVzdCBwcm92aWRl IGEgY29tbW9uIGFuZCB1cC10by1kYXRlIG5vcm1hbGl6ZWQgdmlldyBvZiB0aGUgdG9wb2xvZ2ll cyB0aGF0IHRoYXQgc3VwcG9ydCBzZWN1cml0eSBhdWRpdGluZywgYW5kIElQL01QTFMgUHJvdmlz aW9uaW5nIChMMi9MMykgd2hpY2ggaW5jbHVkZXMuLi4NCg0KQmV5b25kIHRoZSBpMnJzIHJlcXVp cmVtZW50cywgU2VjdGlvbiAyLjIgaW5jbHVkZXMgcmVmZXJlbmNlcyB0byBbc2FjbS1yZXF1aXJl bWVudHNdLiAgQXMgU0FDTSBpcyBhYm91dCBzZWN1cml0eSBhbmQgY29udGludW91cyBtb25pdG9y aW5nLCB0aGlzIHNob3VsZCBiZSBhIHJlbGV2YW50IHJlZmVyZW5jZS4gICBBbHNvIHNvbWV0aGlu ZyB3aGljaCB1c2UgdG8gYmUgaW4gU2VjdGlvbiAyIHdhcyBhbiBpMnJzIHNlY3VyaXR5IHNwZWNp ZmljIHB1YiBzdWIgdXNlIGNhc2UgLyByZXF1aXJlbWVudHMgZG9jdW1lbnQgLT4gY2Ftd2luZ2V0 LWkycnMtcHVic3ViLXNlYy4gIFRoZSByZWZlcmVuY2UgdG8gdGhlIGNhbXdpbmdldCBkcmFmdCB3 YXMgcmVtb3ZlZCBkdWUgdG8gaXRzIGV4cGlyYXRpb24sIGFuZCBiZWNhdXNlIHRoZSBhdXRob3Ig dGhlbiBtb3ZlZCBvbiB0aGUgY3JlYXRlIHRoZSBbc2FjbS1yZXF1aXJlbWVudHNdIGRvY3VtZW50 IGFzIGEgcmVzdWx0LiAgIA0KDQpJZiB0aGVzZSBleGlzdGluZyByZWZlcmVuY2VzIGFyZSBpbnN1 ZmZpY2llbnQsIHdlIGNvdWxkIGFsc28gYW5kIGJyaW5nIGluIG5ldyB1c2UgY2FzZSByZWZlcmVu Y2VzLiAgRm9yIGV4YW1wbGUgd2UgY291bGQgYnJpbmcgaW4gZHJhZnQtdm9pdC1uZXRtb2QteWFu Zy1tb3VudC1yZXF1aXJlbWVudHMgPiBVc2UgQ2FzZSA0LjIuIA0KDQpQbGVhc2UgbGV0IG1lIGtu b3cgaWYgdGhlIGV4cGxhbmF0aW9uIG1lZXRzIHlvdXIgbmVlZHMsIGlmIHNvbWUgb2YgdGhlIGFi b3ZlIHJlZmVyZW5jZXMgc2hvdWxkIGJlIGV4cGFuZGVkLCBvciBpZiB5b3UgaGF2ZSBzb21lIG90 aGVyIHJlcXVlc3QuDQoNClRoYW5rcywNCkVyaWMNCg0KDQo+IFRoZSBpbnRybyBzdWdnZXN0cyB0 aGF0IHRoaXMNCj4gbWVjaGFuaXNtIHdpbGwgYmUgdXNlZCBmb3IgZW50ZXJwcmlzZSBzZWN1cml0 eSBtb25pdG9yaW5nIG9wZXJhdGlvbnMuIFRob3NlDQo+IG9wZXJhdGlvbnMgc2hvdWxkIGJlIGRl c2NyaWJlZCAoYXQgYSBoaWdoIGxldmVsKSwgYWxvbmcgd2l0aCBhc3NvY2lhdGVkIHRocmVhdHMu DQo+IEZyb20gdGhvc2UgdGhyZWF0cyBjb21lIGFzc29jaWF0ZWQgbWl0aWdhdGlvbiBtZWFzdXJl cywgYW5kIGZyb20gdGhvc2UNCj4gbWVhc3VyZXMgY29tZSByZXF1aXJlbWVudHMuIElmIHlvdSB3 YW50IHRvIHB1bnQgb24gdGhlIHNwZWNpZmljcyAoYW5kIGFkZHJlc3MNCj4gaXQgaW4gbGF0ZXIg d29yayksIHRoZW4gdGhlIHJlcXVpcmVtZW50cyBzaG91bGQgYXQgbGVhc3QgZGVzY3JpYmUgd2hh dCB0aHJlYXRzDQo+IHNob3VsZCBiZSBtaXRpZ2F0ZWQuDQo+IA0KPiBJIHRoaW5rIHRoZSBBRHMg c2hvdWxkIHRha2UgYSBsb29rIGF0IHRoaXMgZG9jdW1lbnQuDQo+IA0KPiAtLVNjb3R0DQo+IA0K DQo= From nobody Thu Apr 28 12:37:38 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF84C12D1E8; Thu, 28 Apr 2016 12:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ekqrg3vxiEZE; Thu, 28 Apr 2016 12:37:34 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0A1312D90F; Thu, 28 Apr 2016 12:37:32 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id y84so95735010lfc.0; Thu, 28 Apr 2016 12:37:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=x/LtDXysYoeWUO5fVQv+XfBg8KN4CVfHiI0vt3XhfSY=; b=PXeeVoG14uUXxpyd5kuAZC7twwyJ2yXnY4iPAO9S4slkI0Tko9MOm+2O+nQK9lgzuY 6C9nSLm5mnpemdDadD3la8IvEBpoccWH/WwnjMmJ/0HBIYTVrTY6DST9x/JzOgRLhdiG x/nLp8SIeS2pTNJK3R0qDUYvoeoMfZCOXwfQq4P5uxhWPJCo6SL1H1RFOuCHvVx9jaam 9MktknHBBWrcgXc2N476IPJfLDIGXMLqmlUytuv/A3jtpqQD21oYNQsg4CuDslhe8oUh fqy3SMO5QJlmDVWrVH7wQqs/HVj/kYFM8UuUy7uE5VQPE4I501n1lgyQNzvj8xqI602I Bl4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=x/LtDXysYoeWUO5fVQv+XfBg8KN4CVfHiI0vt3XhfSY=; b=ArMpVLHZ8kx3vTl/NWeKQy8tDmuaiDUpzW55Av7DJSm0cX1s+Y3w+j0flYQfIFxxMx S7AqrO4t94cHKv/wBCg4x4hZYpKg7GYyR1S+mhKFdLVGj6QfAtlduNNlxd817WgvDsl1 PA67Od5CriX6l/6ZUrIQelsUH0JNWu/jopI7Su2F5lufk1G7VhHD4SDecsmGAWKMXLGO XLig34VYZyphmPpa3EEJPnQ+O6q8VxtNgQBsmVQDwmKNla3MkvWKeekwK+Tl8s7sMXrz fZtg/PzmAPdeGTHn/we/Qy8Jicmy4vQrOuK4MvF9Xlfke1PL7YsZcbm8pHvxDD3owiLu D/Ng== X-Gm-Message-State: AOPr4FVRgkUjcp4Tw1Tr1ZJBnY301sSOpNl6WegVmn7tl3MwqtTazd0L4HFUyVdwykfe0zJ3dqOeryt3F2EiZA== MIME-Version: 1.0 X-Received: by 10.25.90.79 with SMTP id o76mr821509lfb.67.1461872251052; Thu, 28 Apr 2016 12:37:31 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.3.102 with HTTP; Thu, 28 Apr 2016 12:37:30 -0700 (PDT) In-Reply-To: <57208701.2010209@gmail.com> References: <57208701.2010209@gmail.com> Date: Thu, 28 Apr 2016 15:37:30 -0400 X-Google-Sender-Auth: xZDUYUmskLbxsV-uKDMkVj13LgA Message-ID: From: Phillip Hallam-Baker To: Stewart Bryant Content-Type: multipart/alternative; boundary=001a1140027a3b2efe053190a82e Archived-At: Cc: draft-ietf-pals-seamless-vccv.all@ietf.org, "Andrew G. Malis" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-pals-seamless-vccv-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 19:37:37 -0000 --001a1140027a3b2efe053190a82e Content-Type: text/plain; charset=UTF-8 On Wed, Apr 27, 2016 at 5:31 AM, Stewart Bryant wrote: > > > On 26/04/2016 15:51, Phillip Hallam-Baker wrote: > > Yes, I think that what is needed is IAB review of what is going on > rather than action on this particular draft. > > Sorry - what is the scope of your proposed IAB review? > > In particular, I don't consider a protocol suitable to be considered > an IETF standard unless people can buy devices from multiple vendors > and configure them to work together securely. > > > Sure, but I would like to see an evidence based assessment of the specific > problem you are seeing in the field. So far none has been brought to PALS > (ne PWE3) > or MPLS as far as I am aware. Carlos can talk to L2TP, but again I have not > heard of a specific problem ever being raised. > The point of security considerations is that the onus is on the developers to show that the system is secure. The documents I have read don't describe a coherent security architecture. It seems to me that the security of the MPLS/SDN etc world is something that hasn't really received the consideration it needs. A few years back we suddenly realized that BGP had no security model and desperately needed one. The whole point of security considerations was to try to avoid situations like that occurring. It seems we have done the same thing in this space. The other issue is that security people probably should be looking at layer 2 security because that is the only way to achieve protection against certain mass surveillance attacks. It is a potential tool that has been overlooked. Right, but I cannot see why anyone would want to mass surveil the OAM > protocol, and we inherit the security enhancements to the underlying > data and control planes. > The type of attack that would be of concern would be injecting messages into the control plane to affect movement of packets. There are games that can be played just by manipulating quality of service. > I do not consider IPSEC to be a suitable security mechanism for this > type of system. If I was given the design brief, I would insist that > every message be authenticated by digital signature rather than a MAC > and the control messages logged. I might use a MAC for > pre-authentication to prevent DoS attack on the control plane. But the > control messages should be fixed in non repudiable fashion. > > > We need to examine this statement in more detail to understand which > element > of the system you are concerned about. However please remember that some > elements of the dataplane and OAM are cost and time sensitive. > I am mostly interested in security of the control plane messages. Though it might well be useful to consider the possibility of using these infrastructures as a possible platform for building traffic analysis resistant networks. I am aware that this is not BGP which is a layer 3 switching protocol. > I don't think anyone would describe BGP as a layer 3 switching protocol! It exchanges reachability information, it does not switch packets. I just did and I am right. The layer at which BGP data moves is pretty much irrelevant to me. It could move out of band on carrier pigeon for all I care. BGP is supplying the information that directs packets at layer 3. Hence it is best viewed as a support protocol for layer 3. The ISO layered model isn't very helpful because it directs attention to how packets move. Once you start on virtual links and quality of service, you end up with nested stacks if you try to maintain 'layering'. This document has the title 'psuedowire' in the title. The protocol it is describing creates a capability that has link-like nature. Therefore from a security perspective we are talking layer 2 even if you build this on layer 3. At that layer I am interested in service and traffic analysis attacks. --001a1140027a3b2efe053190a82e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 27, 2016 at 5:31 AM, Stewart Bryant <stewart.bryant@gmail= .com> wrote:
=20 =20 =20


On 26/04/2016 15:51, Phillip Hallam-Baker wrote:
Yes, I think that what is needed is IAB review of what is going =
on
rather than action on this particular draft.
Sorry - what is the scope of your proposed IAB review?= 
In particular, I don't consider a protocol suitable to be co=
nsidered
an IETF standard unless people can buy devices from multiple vendors
and configure them to work together securely.

 Sure, but I would like to see an evidence based assessment of the specific
problem you are seeing in the field. So far none has been brought to PALS (ne PWE3)
or MPLS as far as I am aware. Carlos can talk to L2TP, but again I have not
heard of a specific problem ever being raised.

The point of security considerations is that the onus is = on the developers to show that the system is secure.

The documents I have read don't describe a coherent security archite= cture. It seems to me that the security of the MPLS/SDN etc world is someth= ing that hasn't really received the consideration it needs.
<= br>
A few years back we suddenly realized that BGP had no securit= y model and desperately needed one. The whole point of security considerati= ons was to try to avoid situations like that occurring. It seems we have do= ne the same thing in this space.

The other issue i= s that security people probably should be looking at layer 2 security becau= se that is the only way to achieve protection against certain mass surveill= ance attacks. It is a potential tool that has been overlooked.

Right, but I cannot see why anyone would want to mass surveil the OAM
protocol, and we inherit the security enhancements to the underlying=C2= =A0
data and control planes.

The ty= pe of attack that would be of concern would be injecting messages into the = control plane to affect movement of packets. There are games that can be pl= ayed just by manipulating quality of service.

=C2= =A0
I do not consider IPSEC to be a suitable security mechanism for =
this
type of system. If I was given the design brief, I would insist that
every message be authenticated by digital signature rather than a MAC
and the control messages logged. I might use a MAC for
pre-authentication to prevent DoS attack on the control plane. But the
control messages should be fixed in non repudiable fashion.

 We need to examine this statement in more detail to understand which element
of the system you are concerned about. However please remember that some
elements of the dataplane and OAM are cost and time sensitive.

I am mostly interested in security of the con= trol plane messages. Though it might well be useful to consider the possibi= lity of using these infrastructures as a possible platform for building tra= ffic analysis resistant networks.


<= span class=3D"">
I am aware that this is not BGP which is a= layer 3 switching protocol.
I don't think anyon= e would describe BGP as a layer 3 switching protocol!

It exchanges r= eachability information, it does not switch packets.

I just did and I am right. The layer at whic= h BGP data moves is pretty much irrelevant to me. It could move out of band= on carrier pigeon for all I care. BGP is supplying the information that di= rects packets at layer 3. Hence it is best viewed as a support protocol for= layer 3.=C2=A0

The ISO layered model isn't ve= ry helpful because it directs attention to how packets move. Once you start= on virtual links and quality of service, you end up with nested stacks if = you try to maintain 'layering'.

This docum= ent has the title 'psuedowire' in the title. The protocol it is des= cribing creates a capability that has link-like nature. Therefore from a se= curity perspective we are talking layer 2 even if you build this on layer 3= .=C2=A0

At that layer I am interested in service a= nd traffic analysis attacks.
--001a1140027a3b2efe053190a82e-- From nobody Thu Apr 28 14:30:04 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF5D12D8A0; Thu, 28 Apr 2016 14:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5j0KzfrWkWY; Thu, 28 Apr 2016 14:29:57 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B93A812D592; Thu, 28 Apr 2016 14:29:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6094; q=dns/txt; s=iport; t=1461878996; x=1463088596; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=on68NVQkjy7sPplmm7XHwoUjtz6rVeuGB13S3KCDHl4=; b=ZLqqzGaRmzmMBj+jneHwAaF8wiJf4AsuMRE3oI9qKhJKUktRL+Eq/oYz Tm5VLVcYuej5dJ9jWBC5dBttZHx2C9fFvZIfEi0ZIoPu/YQbJDChDDCsK ET1OBp3WUW5iZyFph9ubw19MZqNSxPlLhj55002ZX4uhjG4eEWHDxVBeZ I=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAwA6gCJX/4MNJK1egmxMgVAGtGiCZ?= =?us-ascii?q?IIPDoF2hg8CgSY4FAEBAQEBAQFlJ4RBAQEBAwEjVgULAgEIBBQqAgIyJQIEDgU?= =?us-ascii?q?OiBQIskeRLgEBAQEBAQEBAQEBAQEBAQEBAQEBAQ0IhiGBdYJWhz0rgisFmBABg?= =?us-ascii?q?yeBZ4kIjxGPLwEeAUODa2yGaX8BAQE?= X-IronPort-AV: E=Sophos;i="5.24,548,1454976000"; d="asc'?scan'208,217";a="101759455" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Apr 2016 21:29:55 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u3SLTtCV015103 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Apr 2016 21:29:55 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 28 Apr 2016 17:29:54 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Thu, 28 Apr 2016 17:29:54 -0400 From: "Carlos Pignataro (cpignata)" To: Phillip Hallam-Baker Thread-Topic: SECDIR review of draft-ietf-pals-seamless-vccv-02 Thread-Index: AQHRn7noe7HtbKiJG0u+NZfEBeLzNZ+ckJsAgAAJNACAATkFgIACO5QAgAAfZQA= Date: Thu, 28 Apr 2016 21:29:54 +0000 Message-ID: <43FF685A-36BB-4E24-BC00-E14197776E47@cisco.com> References: <57208701.2010209@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.58.232] Content-Type: multipart/signed; boundary="Apple-Mail=_92D545E3-0B35-4874-A66D-A333FDD28582"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: Stewart Bryant , "draft-ietf-pals-seamless-vccv.all@ietf.org" , "Andrew G. Malis" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-pals-seamless-vccv-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 21:29:59 -0000 --Apple-Mail=_92D545E3-0B35-4874-A66D-A333FDD28582 Content-Type: multipart/alternative; boundary="Apple-Mail=_23A1D7DB-7201-4D99-B0EB-56C4F9283175" --Apple-Mail=_23A1D7DB-7201-4D99-B0EB-56C4F9283175 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Phillip, It might be useful to updated the Subject line for the rest of the = discussion. Trying to focus the conversation on the current Subject, I am leaving = the relevant sentence, and inserting a comment at the end. > On Apr 28, 2016, at 3:37 PM, Phillip Hallam-Baker = wrote: >=20 > This document has the title 'psuedowire' in the title. The protocol it = is describing creates a capability that has link-like nature. This document, draft-ietf-pals-seamless-vccv-02, does not have = =E2=80=9Cpsuedowire=E2=80=9D (nor =E2=80=9Cpseudowire=E2=80=9D) in the = title, and does not describe a protocol that creates a capability that = has a link-like nature. For reference: CPIGNATA-M-H03V:seamless-vccv cpignata$ tail -n +12 = draft-ietf-pals-seamless-vccv-02.txt | head Seamless BFD for VCCV draft-ietf-pals-seamless-vccv-02 Abstract This document extends the procedures and Connectivity Verification (CV) types already defined for Bidirectional Forwarding Detection (BFD) for Virtual Circuit Connectivity Verification (VCCV) to define Seamless BFD (S-BFD) for VCCV. This document updates RFC 5885, extending the CV Values and the Capability Selection. CPIGNATA-M-H03V:seamless-vccv cpignata$ Thanks, =E2=80=94 Carlos. --Apple-Mail=_23A1D7DB-7201-4D99-B0EB-56C4F9283175 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Phillip,

It= might be useful to updated the Subject line for the rest of the = discussion.

Trying to focus the conversation on the current Subject, I am = leaving the relevant sentence, and inserting a comment at the = end.

On Apr 28, 2016, at 3:37 PM, Phillip = Hallam-Baker <phill@hallambaker.com> wrote:

This document has the title 'psuedowire' in the = title. The protocol it is describing creates a capability that has = link-like nature. 


This document, draft-ietf-pals-seamless-vccv-02, does not = have =E2=80=9Cpsuedowire=E2=80=9D (nor =E2=80=9Cpseudowire=E2=80=9D) in = the title, and does not describe a protocol that creates a capability = that has a link-like nature.

For reference:

CPIGNATA-M-H03V:seamless-vccv cpignata$ = tail -n +12 draft-ietf-pals-seamless-vccv-02.txt | head
                =          Seamless BFD for VCCV
                =     draft-ietf-pals-seamless-vccv-02

Abstract

   This = document extends the procedures and Connectivity Verification
   (CV) types already defined for Bidirectional = Forwarding Detection
   (BFD) for Virtual = Circuit Connectivity Verification (VCCV) to define
  =  Seamless BFD (S-BFD) for VCCV.  This document updates = RFC 5885,
   extending the CV Values and the = Capability Selection.
CPIGNATA-M-H03V:seamless-vccv = cpignata$ 

Thanks,

=E2=80=94 Carlos.
= --Apple-Mail=_23A1D7DB-7201-4D99-B0EB-56C4F9283175-- --Apple-Mail=_92D545E3-0B35-4874-A66D-A333FDD28582 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXIoDQAAoJEIXgpQGOZny93OYP/jpeCyo8rVHCzfGGy5rwvAZU BZXXok7z21t3VONhGo1Mn1+5rQ2FdUTIO3GojhV1aZn3wvN9jOjEKeyiR0ap8YGa BWTs9Gsw5NDFjLRJmHOfmB+yiN17YuXXVvOASa2krFZBcPfqVFgiPmDGQrQP8aNm ANJUhhQZvRH1eqOB9JkEfPcbndduJIzkIMQJojTQo+QnEJcFgZlVr8d7cqsUySEw hzmFcH7wF5sB2QEa0ZKkbUWWnQEoltsVrFWRNmiY4pI9ZFMe2novlmpdvDCCczCz Ikap0f3CwvFvOpMEN/UiPawVqK7yAROE14h05PZGMrz2aLQjFnxE8hI/4efG2Vko 7k3yX+TEmUPQmNMZduzpnKVLLUpe56jz/l9ftbLxLfkNMSjwPltjclwLwBP+pLrj qy11Rtlz9xOjsyKGGG4xReWXd0rzEc1uUoINs4K2LEl6PGjwh+JZwRbBBvn8+f4Z 4Bu5BZW24CltiCjAQFrieY+P670XM82WIsP93nq2gtRTIM+tTp9Z/GCHOYqFNt/j f1bSuNnOVcKvOMqoA0zsJkwU39eI9eKtV5H9z2dn2gsY4G7uME6tHLPaILHiE5sx OFX7ZC1Qw8UHNZkuObXNq/RJYW+slyF0bUQjDgSiGHYSxc2ZgQvYRl5Jb8gGTEPf llApCpcHxOf1ueNMrKrV =hm3P -----END PGP SIGNATURE----- --Apple-Mail=_92D545E3-0B35-4874-A66D-A333FDD28582-- From nobody Thu Apr 28 17:19:40 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 503C612B020; Thu, 28 Apr 2016 17:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pulpLUtecLZ5; Thu, 28 Apr 2016 17:19:33 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95A5B12D51F; Thu, 28 Apr 2016 17:19:30 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id x201so102369792oif.3; Thu, 28 Apr 2016 17:19:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:date:message-id:to:mime-version; bh=VwkBXKVWWCLcJp+VC7xz3UfRa4a+31FCquriZo069pM=; b=wqGVXK054QbvlK2VUPCOJhD+YtOLMqaCs82msEgzluDCf8Bmww427neVztXbxcLEH+ 60wxRFCzLqSV9lkAt0BMHnQo9oyv7+b8j52QWm5Z7CwN1a3XCFuRhLSnKEHq+bXOyUMq L0qPr9/VgYzbBjiY3cBTUAum6WarDk3/pMRyYWmfrH1z1R5Vb1uslEFw4fLfZcw9hS0A ue9f5yIj1my8wWA69+tSD4I7ajr2j+fo92conGOynK4TnOcB///NwWZuns+dTQUNrLbb hoTdv935FPxqPwGl5ZqVQdSdKXmFRewRDYKvDvDRj14CYyKLrPRZ+eK5M1dEaUGVvhnd OQTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:date:message-id:to:mime-version; bh=VwkBXKVWWCLcJp+VC7xz3UfRa4a+31FCquriZo069pM=; b=a+EtL13UQc64agaa5Y6mZQL8Rn4GXbMK0lTEhedQUdxgspPJGus+0Slg6gbJWq/+QU gfP4S8BhpvZDcKuZBSCg3CBFaaioCLRFEPeA4Um8a5EnA2P0iLw0VCrE+WvleORDbprm LeAw0tj59GDHjGgVFTfo+HIcaUV48FxzbUyuds7FO6BkSkSCAENpbWFlHuh/wiGeFSah TVXw3AZfJrmfUdfUH+LZiZTE0lKxIy/J2rvMdBFTTm7JfmatzC0xfkw8dUDVwUGMzlLt BrGxS5Gn56DcyrWHE6W84Hr4+/BoKNeuePkwQt84y9J9Lv9M1TsD0sCvZZyVTkBNcu3V e54A== X-Gm-Message-State: AOPr4FXnHRiGYGNaR82pgv/zF1jrNrrsresY5qm8uZuAqAuKibpib4YV02Ory5HZld78EA== X-Received: by 10.202.91.8 with SMTP id p8mr7049898oib.99.1461889170032; Thu, 28 Apr 2016 17:19:30 -0700 (PDT) Received: from adams-mbp.attlocal.net (99-64-100-131.lightspeed.austtx.sbcglobal.net. [99.64.100.131]) by smtp.gmail.com with ESMTPSA id g6sm3827581oeu.9.2016.04.28.17.19.28 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 28 Apr 2016 17:19:28 -0700 (PDT) From: Adam Montville X-Pgp-Agent: GPGMail 2.6b2 Content-Type: multipart/signed; boundary="Apple-Mail=_77897290-9903-489B-9EB4-EBD4267E60A8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Thu, 28 Apr 2016 19:19:27 -0500 Message-Id: To: The IESG , secdir@ietf.org, draft-sheffer-rfc6982bis.all@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [secdir] secdir review of draft-sheffer-rfc6982bis-00 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 00:19:35 -0000 --Apple-Mail=_77897290-9903-489B-9EB4-EBD4267E60A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. This draft is ready. I found the draft readable and easy to understand. I agree with the = statement made in the Security Considerations section that, being a = process document, there are no real security considerations. I also = agree with the perspective that a draft with an Implementation Status = section probably has implementations, which, in turn, may mean that the = protocol was more deeply examined and therefore more likely to be = secured well. Kind regards, Adam --Apple-Mail=_77897290-9903-489B-9EB4-EBD4267E60A8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXIqiPAAoJEDEhyx7etgABsLEP/0czJUByKJDn85E/p+k/idcO Ld/j8jPO4yBkWj9mgNNh1WCYu7q5aKE/qej8r6+EsWubFBhe9LJWypbsZN5jXGCw utfiqBz56iqjH7ppcdlyKA117NM5TmlXb+eBe9nNeOtDJ8TjDFP+7Hd1mOG2FJvh FaL29gSyJL05Wx0Xf3R902x8ybfgSdmbRypgJGlLd+YXKVxNQ4XlbTDVR+XKBy9a CWU3XWLLpDOHkGpvfMzX5TKBKViCpRm6kWkD5SCExU/yl4P4uwn//+lPXQVFhJEN UpFuEKmXP1crvuCyKkFK+8FEt/VZj4k8eahyKX3vRi5K78Xhe0xha1uekDi+k6kU i32GUWygZEGFws/An3i+pDWory6H1JYmpZc8WlPyQwIzCCQWFkXOa0DHVSRmOa/H TiqM/UtZZCiqbPKCJjNSgl8NQiBbWvw1x2CjR4/8dYQ5zepV49TmRHiBGSjU5xxj SwBeLEPkz397rGnAW4Akg1oZlJbSU8tjIJ7VzZWKGenwUM2J3IUmxMJnvle9MMkp EY7e6TBX/hbSxfxHVIt6DvbUdEoGFoV4NAWavej5LncC3ePimrKbkfXZmeTp+9yt ghH51GfcXupG9qksTLg5o3SS0TgyVPdH1G5v+9pG/bGdbK3T7IhQP0sbpYKmr8UG gHX+sudLsVOjTjhyzxT7 =+qlh -----END PGP SIGNATURE----- --Apple-Mail=_77897290-9903-489B-9EB4-EBD4267E60A8-- From nobody Fri Apr 29 02:20:04 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 012D812B055; Fri, 29 Apr 2016 02:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyTbUlOvseJK; Fri, 29 Apr 2016 02:19:55 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECF6912D5D9; Fri, 29 Apr 2016 02:19:54 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id e201so19607047wme.0; Fri, 29 Apr 2016 02:19:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=lXhI8Pv+cs2vajkVBIBOa23xUsNuxmqx8hniiu9YRD8=; b=nbNmdrkg0hyBwarKKypZVes6kB0EGXEax4TOWc21JtyWtPMGFyGuz9bhbJ8LSLZaE3 KSmdRp/V6nKxdotiiIZpfm7tSVJIk012NE0OJhaDs4JpbQnOZYGKIVUDpZFVh+Cgm7ei f089ub6xfQMdafIh6TIUAGHsXw7E90OI5z2euGqM6Gi9l/MCUXz3J6NSKzPU35FOpGU/ nz0fr8aKy4pwxoiPhiRoPOf6Y8PJT298YM+OmetUt/mEneH9+C8j2fAWNI30Wj5CaF/D C+FV70Uj86MoK/Ox5M7Fgcm1viNZ3xO8zNX3HhDWZc5BdYLNeQkr5lGudr75pZV4LiWH 8irg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=lXhI8Pv+cs2vajkVBIBOa23xUsNuxmqx8hniiu9YRD8=; b=F/gxnWWl2Pz/js+kRklH2OiKFMY4zTh76rNwP6YT66eddYZLJ/YqkG8ZvRklaKWitb bOxP8Uk7+r0f/wEnXWjxFehIR4uQhv6iCbLtYElqsexNpAHRGAeJmoMMavygdcKsDfvM 5rLBsvLbdYI5k43JV2nG1ssn73FItWzjchw3Qyfss3+KT2Nj07cPXWDeTybRF+s0GGH1 pjDL51aVGZHycR9ZWI8er1UyNJBomS9mGiqJUwoI0zhy6I5FsOx7vhAQxAqmTAaTY8IB atuP/kjey1sfnENoGmG/JkQfAmkLkJOVNV3Oowp6523Oy2SHMybjBHSv9QkxjJG/VJjk he6Q== X-Gm-Message-State: AOPr4FWnvCvNClQKPoGe2E2z1apxX06VIM/yUJ0ZJmOWxq2DhkzKEDEGKVV78oWzHGWv2A== X-Received: by 10.194.205.167 with SMTP id lh7mr20475185wjc.30.1461921593526; Fri, 29 Apr 2016 02:19:53 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id c194sm2347698wme.9.2016.04.29.02.19.51 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Apr 2016 02:19:52 -0700 (PDT) To: Phillip Hallam-Baker References: <57208701.2010209@gmail.com> From: Stewart Bryant Message-ID: <57232736.60305@gmail.com> Date: Fri, 29 Apr 2016 10:19:50 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------010707070706070806050503" Archived-At: Cc: draft-ietf-pals-seamless-vccv.all@ietf.org, "Andrew G. Malis" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-pals-seamless-vccv-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 09:19:58 -0000 This is a multi-part message in MIME format. --------------010707070706070806050503 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I think we need to wind this discussion way back. MPLS and PW (which can run over IP and well as a MPLS) are widely deployed technologies. When running over MPLS PW inherits the MPLS security model. If you think that MPLS needs to extend RFC5920, then that is a much bigger discussion and one that you need take to the MPLS WG. When using an IP transport, the security model belongs to the L2TPext WG and that is a discussion you need to take to that WG. This draft is a tiny extension to RFC5085, and I cannot see that it degrades the security of RFC5085. As such we should note your points and move on. The right way forward here is to take your concerns about the security of pseudowires to the PALS, MPLS and L2TPext WGs as a wider concern and not to hang them on this text. Stewart On 28/04/2016 20:37, Phillip Hallam-Baker wrote: > On Wed, Apr 27, 2016 at 5:31 AM, Stewart Bryant > > wrote: > > > > On 26/04/2016 15:51, Phillip Hallam-Baker wrote: >> Yes, I think that what is needed is IAB review of what is going on >> rather than action on this particular draft. > Sorry - what is the scope of your proposed IAB review? >> In particular, I don't consider a protocol suitable to be considered >> an IETF standard unless people can buy devices from multiple vendors >> and configure them to work together securely. > > Sure, but I would like to see an evidence based assessment of the > specific > problem you are seeing in the field. So far none has been brought > to PALS (ne PWE3) > or MPLS as far as I am aware. Carlos can talk to L2TP, but again I > have not > heard of a specific problem ever being raised. > > > The point of security considerations is that the onus is on the > developers to show that the system is secure. > > The documents I have read don't describe a coherent security > architecture. It seems to me that the security of the MPLS/SDN etc > world is something that hasn't really received the consideration it needs. > > A few years back we suddenly realized that BGP had no security model > and desperately needed one. The whole point of security considerations > was to try to avoid situations like that occurring. It seems we have > done the same thing in this space. > > The other issue is that security people probably should be looking at > layer 2 security because that is the only way to achieve protection > against certain mass surveillance attacks. It is a potential tool that > has been overlooked. > > > Right, but I cannot see why anyone would want to mass surveil the OAM > protocol, and we inherit the security enhancements to the underlying > > data and control planes. > > > The type of attack that would be of concern would be injecting > messages into the control plane to affect movement of packets. There > are games that can be played just by manipulating quality of service. > >> I do not consider IPSEC to be a suitable security mechanism for this >> type of system. If I was given the design brief, I would insist that >> every message be authenticated by digital signature rather than a MAC >> and the control messages logged. I might use a MAC for >> pre-authentication to prevent DoS attack on the control plane. But the >> control messages should be fixed in non repudiable fashion. > > We need to examine this statement in more detail to understand > which element > of the system you are concerned about. However please remember > that some > elements of the dataplane and OAM are cost and time sensitive. > > > I am mostly interested in security of the control plane messages. > Though it might well be useful to consider the possibility of using > these infrastructures as a possible platform for building traffic > analysis resistant networks. > > > I am aware that this is not BGP which is a layer 3 switching protocol. > > I don't think anyone would describe BGP as a layer 3 switching protocol! > > It exchanges reachability information, it does not switch packets. > > I just did and I am right. The layer at which BGP data moves is pretty > much irrelevant to me. It could move out of band on carrier pigeon for > all I care. BGP is supplying the information that directs packets at > layer 3. Hence it is best viewed as a support protocol for layer 3. > > The ISO layered model isn't very helpful because it directs attention > to how packets move. Once you start on virtual links and quality of > service, you end up with nested stacks if you try to maintain 'layering'. > > This document has the title 'psuedowire' in the title. The protocol it > is describing creates a capability that has link-like nature. > Therefore from a security perspective we are talking layer 2 even if > you build this on layer 3. > > At that layer I am interested in service and traffic analysis attacks. --------------010707070706070806050503 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I think we need to wind this discussion way back.

MPLS and PW (which can run over IP and well as a MPLS) are widely deployed
technologies. When running over MPLS PW inherits the MPLS security model.

If you think that MPLS needs to extend RFC5920, then that is a much bigger
discussion and one that you need take to the MPLS WG.

When using an IP transport, the security model belongs to the L2TPext WG
and that is a discussion you need to take to that WG.

This draft is a tiny extension to RFC5085, and I cannot see that it degrades the
security of RFC5085. As such we should note your points and move on.

The right way forward here is to take your concerns about the security
of pseudowires to the PALS, MPLS and L2TPext WGs as a wider concern and
not to hang them on this text.

Stewart


On 28/04/2016 20:37, Phillip Hallam-Baker wrote:
On Wed, Apr 27, 2016 at 5:31 AM, Stewart Bryant <stewart.bryant@gmail.com> wrote:


On 26/04/2016 15:51, Phillip Hallam-Baker wrote:
Yes, I think that what is needed is IAB review of what is going on
rather than action on this particular draft.
Sorry - what is the scope of your proposed IAB review?
In particular, I don't consider a protocol suitable to be considered
an IETF standard unless people can buy devices from multiple vendors
and configure them to work together securely.

 Sure, but I would like to see an evidence based assessment of the specific
problem you are seeing in the field. So far none has been brought to PALS (ne PWE3)
or MPLS as far as I am aware. Carlos can talk to L2TP, but again I have not
heard of a specific problem ever being raised.

The point of security considerations is that the onus is on the developers to show that the system is secure.

The documents I have read don't describe a coherent security architecture. It seems to me that the security of the MPLS/SDN etc world is something that hasn't really received the consideration it needs.

A few years back we suddenly realized that BGP had no security model and desperately needed one. The whole point of security considerations was to try to avoid situations like that occurring. It seems we have done the same thing in this space.

The other issue is that security people probably should be looking at layer 2 security because that is the only way to achieve protection against certain mass surveillance attacks. It is a potential tool that has been overlooked.


Right, but I cannot see why anyone would want to mass surveil the OAM
protocol, and we inherit the security enhancements to the underlying 
data and control planes.

The type of attack that would be of concern would be injecting messages into the control plane to affect movement of packets. There are games that can be played just by manipulating quality of service.

 
I do not consider IPSEC to be a suitable security mechanism for this
type of system. If I was given the design brief, I would insist that
every message be authenticated by digital signature rather than a MAC
and the control messages logged. I might use a MAC for
pre-authentication to prevent DoS attack on the control plane. But the
control messages should be fixed in non repudiable fashion.

 We need to examine this statement in more detail to understand which element
of the system you are concerned about. However please remember that some
elements of the dataplane and OAM are cost and time sensitive.

I am mostly interested in security of the control plane messages. Though it might well be useful to consider the possibility of using these infrastructures as a possible platform for building traffic analysis resistant networks.


I am aware that this is not BGP which is a layer 3 switching protocol.
I don't think anyone would describe BGP as a layer 3 switching protocol!

It exchanges reachability information, it does not switch packets.

I just did and I am right. The layer at which BGP data moves is pretty much irrelevant to me. It could move out of band on carrier pigeon for all I care. BGP is supplying the information that directs packets at layer 3. Hence it is best viewed as a support protocol for layer 3. 

The ISO layered model isn't very helpful because it directs attention to how packets move. Once you start on virtual links and quality of service, you end up with nested stacks if you try to maintain 'layering'.

This document has the title 'psuedowire' in the title. The protocol it is describing creates a capability that has link-like nature. Therefore from a security perspective we are talking layer 2 even if you build this on layer 3. 

At that layer I am interested in service and traffic analysis attacks.

--------------010707070706070806050503-- From nobody Fri Apr 29 02:36:50 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B5912D7B1; Fri, 29 Apr 2016 02:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 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_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 o3eieQMoOPZH; Fri, 29 Apr 2016 02:36:47 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00DDA12D77B; Fri, 29 Apr 2016 02:36:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 26B5CBE56; Fri, 29 Apr 2016 10:36:45 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2WLThcwYjox; Fri, 29 Apr 2016 10:36:45 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 86C50BE38; Fri, 29 Apr 2016 10:36:44 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1461922604; bh=feXYUDWPjG79PmBZ6ORVOTzBjYomVS1iBSzHEOApUU8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=XyREjp2+GB1/8XSAR0bJPSB9KA9vWYGmF4QsnQ0tU1Pxp/AeQIYkpN4ZpLJVzrzhk OUBb4/RjMiuPODKS8XkE3NPXfi/IA4uZ+w/SagT2ukGEtVp38AXnG3+KVBEjNRTEvG +gcvAPxJKvXpR/c8ET/9MybqEsow7dOUaF+lV/K8= To: Stewart Bryant , Phillip Hallam-Baker References: <57208701.2010209@gmail.com> <57232736.60305@gmail.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <57232B2C.6070006@cs.tcd.ie> Date: Fri, 29 Apr 2016 10:36:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <57232736.60305@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030809040602080904020706" Archived-At: Cc: draft-ietf-pals-seamless-vccv.all@ietf.org, "Andrew G. Malis" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-pals-seamless-vccv-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 09:36:49 -0000 This is a cryptographically signed message in MIME format. --------------ms030809040602080904020706 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, On 29/04/16 10:19, Stewart Bryant wrote: > I think we need to wind this discussion way back. I agree. I see a couple of things happening in this discussion that have happened before and will happen again: 1) a secdir reviewer finds very little in the way of security mechanism specified for important routing protocols when trying to understand some minor update to something 2) the reviewer comments on that saying: "hey, this whole thing is pretty insecure looking, what's up? e.g. you could do here." 3) authors/chairs/WG participants say "it's ok, these are well managed networks, if you can do then there are much worse things you could do" and maybe over-react a bit as well, fearing that some security mafia are going to try force them to pretend to add crypto to loads of stuff 4) n++; goto 2 (a few times;-) I'm not sure how we break that cycle to be honest, at least not for we=3D=3DIETF participants. I doubt it's likely that we can ensure that secdir reviewers are all familiar with MPLS, PW, etc etc. I equally doubt that routing folks will (for both good and perhaps less good reasons) define, implement and deploy the kind of security mechanisms that'd be needed to avoid secdir reviewers being surprised. I suspect what'll eventually happen is that outside the IETF context, routing folks and/or their customers will decide that boundary security is just no longer good enough by itself and will end up having to do a load of work to address that. And some bits of that work will end up being IETF stuff. (One would hope that all the SDN and similar bits of work are going to head down that path and not try to depend just on boundary security for example.) In the meantime, I think we just repeat the above loop now and then. Cheers, S. --------------ms030809040602080904020706 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA0Mjkw OTM2NDRaMC8GCSqGSIb3DQEJBDEiBCAYQk05r3VnQ8eNGdxdDuaZJ/n7bFr2ZTHfW/34574V 9zBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCZuEBzN4KBdU/VA8dtrvBRgQmddmHQ/7qhxt4UyyaE4WY6DSC4mKgm DnfWn6ZjxoN7wonRTVYAWgoRvYfBda5QuN3O/8gf35832hq6nagrbVRhnOI7f/q9/9WPY2V2 ivb6teab6IibNoqnuDMWIZ890IE7gr8uszBo5lk9QfwapuJ7menjWFhaR2COsZPNMHGzkHdt aQfcfNtDJcFa6YtOxvIWgKGao8X//OawZzJ4thw+hrTup+pKrC4ngDavWcwuzxR2pfd5AeP7 Kxfbt0Zs0pO+2gTV5x9ox2SMg6vx5oVSa1U0kEBy7fXAPKJtVZgfdk3JoKAnHd8lnP4ku9B7 AAAAAAAA --------------ms030809040602080904020706-- From nobody Fri Apr 29 06:34:46 2016 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 761A812B037; Fri, 29 Apr 2016 05:48:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1461934132; bh=tuLdRA95epdIEGMACvO0QrDRbpIdYTXIY9qjPfonZHA=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=YzmAFVglpFANbh3rEmeb4gNrzKtHr9QByNNUvtBuCY2Su2PW26Homgcuq5giyMQTj Ga6XEgZndTFZ3ptUAog/mEa90vOy/zno3reTnXA21zj5+jWWGakdZ86c/QHaIXUiOP JkAbs/EDIci/solQQ9eEcdAnd+McZea4R7Q696Ok= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1C312B037 for ; Fri, 29 Apr 2016 05:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rsmIRJfU5NF for ; Fri, 29 Apr 2016 05:48:48 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C437812B01A for ; Fri, 29 Apr 2016 05:48:48 -0700 (PDT) Received: from [123.125.212.73] (helo=[192.168.1.2]) by raoul.w3.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1aw7qg-000GSS-IY for new-work@ietf.org; Fri, 29 Apr 2016 12:48:47 +0000 To: new-work@ietf.org From: Xueyuan Jia Message-ID: Date: Fri, 29 Apr 2016 20:50:45 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 29 Apr 2016 06:34:44 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Technology and Policy Interest Group (until 2016-05-31) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 12:48:52 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to review a draft charter for the Technology and Policy Interest Group: https://www.w3.org/2016/02/proposed-techpolig.htm As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2016-05-31 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [1], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Daniel Dardailler, Director of International relations at . Thank you, Xueyuan Jia, W3C Marketing & Communications [1] http://www.w3.org/Consortium/Member/List _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Fri Apr 29 14:35:08 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180AE12D1DD for ; Fri, 29 Apr 2016 14:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZ8cMSs-2P6R for ; Fri, 29 Apr 2016 14:35:01 -0700 (PDT) Received: from smtp82.iad3a.emailsrvr.com (smtp82.iad3a.emailsrvr.com [173.203.187.82]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3365112D74A for ; Fri, 29 Apr 2016 14:35:00 -0700 (PDT) Received: from smtp27.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp27.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 430A8180556; Fri, 29 Apr 2016 17:34:59 -0400 (EDT) Received: from app35.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp27.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 370D2180621; Fri, 29 Apr 2016 17:34:59 -0400 (EDT) X-Sender-Id: scott@hyperthought.com Received: from app35.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.5.4); Fri, 29 Apr 2016 17:34:59 -0400 Received: from hyperthought.com (localhost [127.0.0.1]) by app35.wa-webapps.iad3a (Postfix) with ESMTP id 278F5C12C9; Fri, 29 Apr 2016 17:34:59 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Fri, 29 Apr 2016 14:34:59 -0700 (PDT) Date: Fri, 29 Apr 2016 14:34:59 -0700 (PDT) From: "Scott G. Kelly" To: "=?utf-8?Q?Eric_Voit_=28evoit=29?=" 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: <0f8b409c6018417eab61ea7ccb9f549c@XCH-RTP-013.cisco.com> References: <1461805744.570422143@apps.rackspace.com> <0f8b409c6018417eab61ea7ccb9f549c@XCH-RTP-013.cisco.com> X-Auth-ID: scott@hyperthought.com Message-ID: <1461965699.159516487@apps.rackspace.com> X-Mailer: webmail/12.4.1-RC Archived-At: Cc: "draft-ietf-i2rs-pub-sub-requirements.all@ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-i2rs-pub-sub-requirements-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 21:35:02 -0000 Hi Eric,=0A=0AOn Thursday, April 28, 2016 7:11am, "Eric Voit (evoit)" said:=0A=0A=0A =0A> Hi Scott,=0A> = =0A> Section 2.1 provides multiple references to numbered requirements in t= hree other=0A> i2rs documents:=0A> - [i2rs-usecase] draft-ietf-i2rs-usecase= -reqs-summary=0A> - [i2rs-arch] draft-ietf-i2rs-architecture=0A> - [i2rs-tr= aceability] draft-ietf-i2rs-traceability=0A> Some of these references are c= oupled to security uses. Look to those referred=0A> documents for details= .=0A=0AYes, you are right, those documents do provide related use cases and= requirements rationale. Also of note: draft-ietf-i2rs-protocol-security-re= quirements.=0A=0ANow I remember Sue Hares asking secdir for review help wit= h this complex document set, and I can see why.=0A=0AWhen I first looked at= the protocol security requirements draft, I wondered if you should simply = refer to that. I realize you are focusing only on YANG pub/sub requirements= here, but maybe that is still worth considering.=0A =0AIf you choose to ma= intain security requirements in this document, I would suggest adopting a p= attern similar that followed by draft-ietf-i2rs-protocol-security-requireme= nts-03, and refer to the document(s)/numeric requirement(s) driving your MU= STs/SHOULDs. =0A=0AThanks,=0A=0AScott=0A From nobody Sat Apr 30 02:07:39 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7AD212B051; Sat, 30 Apr 2016 02:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9isA0vnb-ZJ; Sat, 30 Apr 2016 02:07:31 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAB4B12B05E; Sat, 30 Apr 2016 02:07:31 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id 77so25516488pfv.2; Sat, 30 Apr 2016 02:07:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=dWy3D5sRB+ci8lF8hPI2rExOdZ2m0/fxI133ssPLH64=; b=ze4evCuKYkNuIh7exrKJuqsY79q4RMj15wDMQQsnXZMTX2Nxd233UpiQvBlToTPR7j FSxHigWH8PGv7rHr5FGOh+0c6nxsr/UPRc5LoBeW3dCJA05GeB6ztkf19K/fa8bLDo16 LbbD/1/3onOMBF4W1p/+jtqK1AQxJC9vYA/VThZOmc9gOB5o70YzCe8qOk7ytZNeOckl 7ciktEm6xxcazU/dG483kxKQapOvIlFYkIzJOAvGCZEr8zFzqRghJz+mDflVhmYd2Oeg IbUmxe5cKL3Vj7zH03IiPkSegZzWh+dst6lmAtrgF4uaUfEutCIMeN2AQwgTzv3rWTPU u07A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=dWy3D5sRB+ci8lF8hPI2rExOdZ2m0/fxI133ssPLH64=; b=DDM1IMYBfE/v4B7vD2y+kRxBjQnc9awM9pzYZbRk2GWrqWtb+mf1f65CJhgsz1Qmp8 CMgw9HvkHBM0PlVTJTSPnM0QrwQs1o/qKDymrp4xxHxxRqLuVS/J2Jz/NlJa8cEF0Bpv bOVVlthLWQpSNeYTOEg+cfDdWmxdKkcSJkILCHCvmvEuYJjdQahPbphJGRmJQlOdUbp8 OcWaMpMRbFhdYidFW+7uapLE3ihrrVJjez5Necc+ft4+DlY7TWp3+Gam5DTOug19Y7oM 2+v5s9mTiZbYuFSlk6f29S4rzfXpWx3Rci/h/QXrPM21CYbzRLgnQUpomk+DDrJYlIaz TZ9w== X-Gm-Message-State: AOPr4FVoX96v3y3TAh7GMQb7fPMvREhfhEQbAZnOS6I+XjYjRuGIussHUldcE9BEArFKLA== X-Received: by 10.98.39.2 with SMTP id n2mr35596660pfn.145.1462007251284; Sat, 30 Apr 2016 02:07:31 -0700 (PDT) Received: from [192.168.1.235] ([103.6.157.63]) by smtp.gmail.com with ESMTPSA id xn3sm22553369pab.32.2016.04.30.02.07.29 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 30 Apr 2016 02:07:30 -0700 (PDT) To: Catherine Meadows , secdir@ietf.org, iesg@ietf.org, draft-ietf-isis-node-admin-tag.all@ietf.org References: From: Pushpasis Sarkar Message-ID: <572475CF.4020905@gmail.com> Date: Sat, 30 Apr 2016 14:37:27 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------030501000707080706060008" Archived-At: Subject: Re: [secdir] sectdir review of draft-ietf-isis-node-admin-tag-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2016 09:07:34 -0000 This is a multi-part message in MIME format. --------------030501000707080706060008 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Catherine, I have uploaded version -09. Let me know if you have any other comments. Thanks and Regards, -Pushpasis On Thursday 21 April 2016 11:06 PM, Catherine Meadows wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all > IETF documents being processed by the IESG. These comments were > written primarily for the > benefit of the security area directors. Document editors and WG > chairs should treat these comments > just like any other last call comments. > > This draft describes an extension to the IS-IS routing protocol, that > allows tagging and grouping of nodes > in an IS-IS domain. This makes it possible to increase the efficiency > of route and path selection, since the tags > give information about a router’s capabilities. > > The Security Considerations section correctly identifies one of the > main security risks of using such tags: they may leak > sensitive information about, e.g., geographical location. However, > I’m confused by the statement following that: > > “This document does not introduce any new security concerns. Security > concerns for IS-IS are already addressed in > [ISO10589], [RFC5304], and [RFC5310] are are applicable to the > mechanisms described in this document.” > > As far as I can tell, this document *does* introduce new security > concerns, because the tags may reveal sensitive > information that may not have been made available otherwise. > Moreover, RFCs 5304 and 5310 concern authentication, not > secrecy, and so do not address information leakage at all. My own > suggestion > for a recommendation would be that implementors should weigh the > benefits of putting certain kinds of information on tags > versus the risk of its being used by an attacker, and make their > decisions accordingly. This would not be a SHOULD a MUST > recommendation by the way, but simply advisory. > > I’m not sure what is meant by the last sentence in this paragraph: > > Extended authentication mechanisms described in [RFC5304] or > [RFC5310] SHOULD be used in > deployments where attackers have access to the physical networks and > nodes included in the IS-IS domain are vulnerable. > > Is this addressing the problem of sensitive information on tags? If > so, you need to say how. If it is addressing > spoofing of tags, it should be given its own paragraph, and the threat > you are talking about should be made clear. > > In the last paragraph, on the misattribution of tags from different > domains, what would you recommend for mitigating against > this problem? Also, since this is in the security considerations > section, you should say something about how an attacker > could take advantage of it. > > In my opinion, the Security Considerations section needs a major > revision. However, > I consider this document Almost Ready, because the purpose of the > revision would be mainly to make the section more clear, not to address > any overlooked security problems. > > > > > Catherine Meadows > Naval Research Laboratory > Code 5543 > 4555 Overlook Ave., S.W. > Washington DC, 20375 > phone: 202-767-3490 > fax: 202-404-7942 > email: catherine.meadows@nrl.navy.mil > > --------------030501000707080706060008 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Catherine,

I have uploaded version -09. Let me know if you have any other comments.

Thanks and Regards,
-Pushpasis

On Thursday 21 April 2016 11:06 PM, Catherine Meadows wrote:
I have reviewed this document as part of the security directorate's ongoing effort to review all 
IETF documents being processed by the IESG.  These comments were written primarily for the 
benefit of the security area directors.  Document editors and WG chairs should treat these comments 
just like any other last call comments.

This draft describes an extension to the IS-IS routing protocol, that allows tagging and grouping of nodes
in an IS-IS domain.  This makes it possible to increase the efficiency of route and path selection, since the tags
give information about a router’s capabilities.

The Security Considerations section correctly identifies one of the main security risks of using such tags:  they may leak
sensitive information about, e.g., geographical location.   However, I’m confused by the statement following that:

“This document does not introduce any new security concerns.  Security concerns for IS-IS are already addressed in
[ISO10589], [RFC5304], and [RFC5310] are are applicable to the mechanisms described in this document.”

As far as I can tell, this document *does* introduce new security concerns, because the tags may reveal sensitive
information that may not have been made available otherwise.  Moreover, RFCs 5304 and 5310 concern authentication, not
secrecy, and so do not address information leakage at all.  My own suggestion
for a recommendation would be that implementors should weigh the benefits of putting certain kinds of information on tags
versus the risk of its being used by an attacker, and make their decisions accordingly.  This would not be a SHOULD a MUST
recommendation by the way, but simply advisory.

I’m not sure what is meant by the last sentence in this paragraph:

 Extended authentication mechanisms described in [RFC5304] or [RFC5310] SHOULD be used in
   deployments where attackers have access to the physical networks and
   nodes included in the IS-IS domain are vulnerable.

Is this addressing the problem of sensitive information on tags?  If so, you need to say how.   If it is addressing
spoofing of tags, it should be given its own paragraph, and the threat you are talking about should be made clear.

In the last paragraph, on the misattribution of tags from different domains, what would you recommend for mitigating against
this problem?  Also, since this is in the security considerations section, you should say something about how an attacker
could take advantage of it.  

In my opinion, the Security Considerations section needs a major revision.  However,
I consider this document Almost Ready, because the purpose of the revision would be mainly to make the section more clear, not to address
any overlooked security problems.




Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: 202-767-3490
fax: 202-404-7942
email: catherine.meadows@nrl.navy.mil


--------------030501000707080706060008-- From nobody Sat Apr 30 07:26:15 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B215612D13B; Sat, 30 Apr 2016 07:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cH05N5Yak4F; Sat, 30 Apr 2016 07:26:12 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33BAC12D107; Sat, 30 Apr 2016 07:26:08 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id m188so20840171vka.1; Sat, 30 Apr 2016 07:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=F0ecc1gGXJnOnvELC6MxFvlL91Dmdbzo3YNq9krfNBg=; b=PrgXrain7rRTPNqN1Z13kJFJlhGRP5CUVs0tMPc2cASPapOCd7xO+nd5iVcZHMUSJr cv+HQwsNyBE5Oy0ocWLCpYSpvo6wZ8lza9J1e/LvmBS7Aj12KnqIugyR69cdQ5f+qdLE Qsu/bUdwaRJl+ZN817Tu28wJ9FolR6vIudXv9bcLAuWUB3i97tgU/mX2T6z2XWEBYBuy adxnCPiSOFcf4bNPRNls3FYDTWhjwMSHETaF83YGIaBHhPvLm/SX3L6Gib6ehgItqEia UfnM2kvvE2XDVOJwcXlybzDEMHkEYr3Dj3LJb4S8fAGLSm/DvMejDwmRMJDaX2x6m0dn RS9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=F0ecc1gGXJnOnvELC6MxFvlL91Dmdbzo3YNq9krfNBg=; b=FPaLWlx63QXRRT03OGKjTH4vIodcafzGoLPzc5H31tow7QttAycAG3OItk0+84lH5g D8gVCk6zn39AvhqoI+53ri0PaS6+pL70fBk8TcHfpi4bqZFY3E9xPo2uqnk8Jvuq894l XQtynF/vHWpTvPAj5x0WSz5z+Uv9znHBoaY4U81/z7FNV4E4avcjQPkvAeZcufgaWD+H mbaOIC4Bs5jXEJxn2tEL5DK4JljatbtlBIFCk8gfRGUhuct+yk+0PRbnMEv/QrpUbi9G +xj1rwuG/wySZ5Ts5eVoS8O7ONzB4QGd0vQYcwNWVRUquA7VOiWClDuPKMiX5cD4cFF2 4hbg== X-Gm-Message-State: AOPr4FWJumKHitNzbvaMnAztlcDXR7Ny7ZlLtP4VuHfB4i3M5Uus1EmPSoVOI00uN3K960PP8xWJUNL/oMCHXA== MIME-Version: 1.0 X-Received: by 10.31.58.80 with SMTP id h77mr2350009vka.149.1462026367994; Sat, 30 Apr 2016 07:26:07 -0700 (PDT) Received: by 10.176.64.68 with HTTP; Sat, 30 Apr 2016 07:26:07 -0700 (PDT) Date: Sat, 30 Apr 2016 07:26:07 -0700 Message-ID: From: Watson Ladd To: secdir@ietf.org, "" , draft-ietf-i2rs-traceability.all@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [secdir] Secdir review of draft-ietf-i2rs-traceability X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2016 14:26:13 -0000 Dear all, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. In my opinion the document is ready. It describes what data should be logged. While the security considerations section mentions the privacy impact of the data in the logs, it doesn't mention the value of the information in the logs for event reconstruction, which is mentioned in the text. I don't see a lot of space for problems here, but maybe I didn't see them. Sincerely, Watson Ladd