From nobody Tue Jun 3 10:15:40 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E69B1A02FB; Tue, 3 Jun 2014 10:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eysO6jsxXIWj; Tue, 3 Jun 2014 10:11:16 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9BBA1A0234; Tue, 3 Jun 2014 10:11:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2979; q=dns/txt; s=iport; t=1401815471; x=1403025071; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=wU7JG2eS/AjTwkmYELyVDmpR7ZSTLLt7YyyM0PoiMsg=; b=UUa1SyV7U3VlONCt7VncpECT6o34h1ce22VJYY5N/v5CcegKLGVRRjmQ BJYuc8DlR51zRdqtLPGsED6TkGRDHO2lcETKpG0718CyKgvpTFy2igzRg XSANBLNWCm8V24jP1dYCsGuhD51m5t+b7DIHsGNZLi0nYoahg8MJItI5f w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoILAHABjlOtJV2U/2dsb2JhbABZgweBKqo4AwEBAQUBmBwBgQwWdIIsgQsBCHglAgQBEohC0yMXhVWJBIRABIlvjBOECJMzgziCLw X-IronPort-AV: E=Sophos;i="4.98,966,1392163200"; d="scan'208";a="327072448" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-9.cisco.com with ESMTP; 03 Jun 2014 17:11:02 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s53HB2id002972 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jun 2014 17:11:02 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.72]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Tue, 3 Jun 2014 12:11:02 -0500 From: "Keyur Patel (keyupate)" To: "Zhangdacheng (Dacheng)" , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-idr-bgp-enhanced-route-refresh.all@tools.ietf.org" Thread-Topic: SECDIR Review of draft-ietf-idr-bgp-enhanced-route-refresh-06 Thread-Index: AQHPfJ7p3QZODynSR0imiS0zqxqnM5tfhdsA Date: Tue, 3 Jun 2014 17:11:02 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [128.107.163.125] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <23156A0CE73DAF41A1A6784C736770DF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/qda3uli6RPoaOSDHUPvo-WC26ig X-Mailman-Approved-At: Tue, 03 Jun 2014 10:15:38 -0700 Subject: Re: [secdir] SECDIR Review of draft-ietf-idr-bgp-enhanced-route-refresh-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 17:11:25 -0000 Hi Dacheng, Thanks a lot for the draft review. My comments are inlined. #Keyur On 5/31/14 12:06 AM, "Zhangdacheng (Dacheng)" 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 short document tries to enhance the existing BGP route refresh >mechanisms to provide for the demarcation of the beginning and the ending >of a route refresh. In order to achieve this, the "Reserved" field of the >ROUTE-REFRESH message is redefined to indicate the beginning and the >ending of a route refresh. I agree this extension will not introduce new >security issues to the BGP protocol. > >The document is clear. I consider it ready with a few issues: > >I suggest defining how a BGP speaker should handle a EoRR without >receiving the associated BoRR especially when the peer does not support >graceful start. #Keyur: The received EoRR message without an associated BoRR message would pretty much be a no-op operation (as no routes are marked Stale). This behavior is consistent with/without GR. How about if we add the following line (Section 4, end of 5th paragraph after: "Such purged routes MAY be logged for future analysis.") A BGP speaker MAY ignore any EoRR message received without a prior receipt of an associated BoRR message. Such messages MAY be logged for future analysis. >=20 > >The description in the last paragraph of section 4 is not very clear. It >would be better to briefly explain why the introduced procedures can >simplify the interaction with the BGP Graceful Restart. In addition, the >EOR and EoR messages (the typos of EoRR?) mentioned in this paragraph are >not defined elsewhere. Keyur: Good Point. How about adding the 2nd (clarification) line to the last paragraph of section 4: The following procedures are specified in order to simplify the interaction with the BGP Graceful Restart [RFC4724]. In particular, these procedures ensure that End-of-RIB (=B3EoR=B2) defined in Graceful Restart and EoRR as defined in this specification are kept separate, thereby avoiding any premature cleanup of stale routes. For a BGP speaker that supports the BGP Graceful Restart, it MUST NOT send a BoRR for an AFI/SAFI to a neighbor before it sends the EoR for the AFI/SAFI to the neighbor. A BGP speaker that has received the Graceful Restart Capability from its neighbor, MUST ignore any BoRRs for an AFI/SAFI from the neighbor before the speaker receives the EoR for the given AFI/SAFI from the neighbor. The BGP speaker SHOULD log an error of the condition for further analysis. Regards, Keyur > >Cheers > >Dacheng > From nobody Wed Jun 4 06:46:39 2014 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 937D81A023E; Wed, 4 Jun 2014 06:38:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1401889138; bh=NNVPivqjGX7qnKTpa4e+akdh4sFXnJw/edFoz0o8q7U=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=UnW4jNusM1LaPnFIZub0hBsz9Vr70yrBa6Tz1T7sUJ9tC45WPZPy3yJgk60bpGiiX 78ayWPIJmXWsIQinIF0oLB89VU7AqtWNtTi+y6sAO19MmgDg2QSOVpsb0PLC1sORBd 05H4E3jW9qjpZ8ulwAgr80hXicrRXoPLHsOJIdH8= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86A7D1A027E; Wed, 4 Jun 2014 06:38:54 -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 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 ShsklFWi9_OP; Wed, 4 Jun 2014 06:38:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5477A1A01E1; Wed, 4 Jun 2014 06:38:52 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140604133852.16004.62071.idtracker@ietfa.amsl.com> Date: Wed, 04 Jun 2014 06:38:52 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/new-work/NrC_gfk9L0wyBGYxwZkxFVDdDzY X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/N54nBWFiQrzbiXWGHZE8Wr_IesI X-Mailman-Approved-At: Wed, 04 Jun 2014 06:46:37 -0700 Cc: jonne.soininen@broadcom.com, marc.blanchet@viagenie.ca, mglt.biz@gmail.com, Russ.Mundy@sparta.com Subject: [secdir] [new-work] WG Review: Domain Name System Operations (dnsop) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 13:38:58 -0000 From: The IESG To: IETF-Announce Cc: dnsop WG Subject: The Domain Name System Operations (dnsop) working group in the Operations and Management 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 at ietf.org) by 2014-06-14. Domain Name System Operations (dnsop) ------------------------------------------------ Current Status: Active WG Chairs: Suzanne Woolf Tim Wicinski Assigned Area Director: Joel Jaeggli Mailing list Address: dnsop@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/dnsop Archive: http://www.ietf.org/mail-archive/web/dnsop Charter: The DNS Operations Working Group will develop guidelines for the operation of DNS software and services and for the administration of DNS zones. These guidelines will provide technical information relating to the implementation of the DNS protocol by the operators and administrators of DNS zones. The group will perform the following activities: 1. Describe practices by which Domain Name System (DNS) software may be efficiently and correctly administered, configured, and operated on Internet networks. This will include root zone name servers, TLD name servers, or any other resolver or server functioning as part of the global DNS. As part of this effort, the group will produce documents explaining to the general Internet community what processes and mechanisms should be employed for the effective management and operation of DNS software and services, including root, TLD, and recursive servers. 2. Publish documents concerning DNSSEC operational procedures. 3. Publish documents concerning DNS operational procedures in IPv6 and mixed IPv6-IPv4 networks, and provide documentation and guidance on DNS-related IPv6 transition and coexistence issues. 4. Publish documents that extend or perform protocol maintenance to the address operational issues with the DNS Protocols. Act as focal-point for operator discussion and provide advice to the Ops ADs and other WGs on EDNS0 options, new RRTYPEs, DNSSEC, record synthesis, or other mechanics of extending DNS to support other applications. 5. Serve as a home for drafts that document the problem space around existing or new DNS issues. The group, with the advice and consent of the responsible AD in coordination with other areas, will then decide whether these issues belong in DNSOP under the existing charter and, if not, will work with the authors and appropriate ADs to determine the proper place for the work to be carried out. 6. Publish documents that attempt to better define the overlapping area among the public DNS root, DNS-like names as used in local or restricted naming scopes, and the 'special names' registry that IETF manages, perhaps including how they might interact. This work must take into consideration issues that are strictly beyond the operation of the DNS itself, and the working group will consult with IETF liaisons to other organizations as appropriate. Milestones: Done - Submit I-D: revised Root Server Requirements. Done - Submit I-D: first version of Servers Sharing IP#. Done - Submit I-D: first version of Performance and Measuring. Done - Submit I-D: revised version of Key Handling. Done - Submit I-D: revised version of Servers Sharing IP#. Done - Submit Root Server Requirements to the IESG for consideration as Informational (BCP?). Done - Submit I-D: 2nd revised version of Servers Sharing IP#. Done - Distributing Authoritative Name Servers via Shared Unicast Addresses to the IESG for Informational Done - Submit Observed DNS Resolution Misbehavior to the IESG for Informational Done - Submit document describing the outstanding problems and issues with DNS discovery for IPv6 to the IESG for Informational. Done - Submit Operational Guidelines for 'local' zones in the DNS to IESG. Category to be determined. Done - Submit Operational Considerations and Issues with IPv6 DNS to the IESG for Informational Done - Submit Common Misbehavior against DNS Queries for IPv6 Addresses to the IESG for Informational Done - Submit DNSSEC Operational Procedures to IESG for BCP Done - Submit Identifying an Authoritative Name Server to IESG for Informational Sep 2007 - Submit I-D: revised version of Considerations for the use of DNS Reverse Mapping Done - Submit I'm Being Attacked by PRISONER.IANA.ORG! to IESG for FYI Done - Submit Locally-served DNS Zones to IESG for BCP Oct 2007 - Submit DNS Response Size Issues to IESG for Informational Dec 2007 - Submit Considerations for the use of DNS Reverse Mapping to IESG for BCP Done - Submit AS112 Nameserver Operations to IESG for Informational Feb 2008 - Submit Initializing a DNS Resolver with Priming Queries to IESG for BCP _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Thu Jun 5 03:29:57 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C9B1A0436 for ; Thu, 5 Jun 2014 03:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.127 X-Spam-Level: X-Spam-Status: No, score=0.127 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JV0XmaTt55W5 for ; Thu, 5 Jun 2014 03:29:53 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 6349C1A0438 for ; Thu, 5 Jun 2014 03:29:52 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s55ATg96018139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 5 Jun 2014 13:29:42 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s55ATg8s006982; Thu, 5 Jun 2014 13:29:42 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21392.18070.410133.988364@fireball.kivinen.iki.fi> Date: Thu, 5 Jun 2014 13:29:42 +0300 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/GgKHfjoLKPof6G7GV6iJrvzyI8s Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 10:29:55 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Sam Hartman is next in the rotation. For telechat 2014-06-12 Reviewer LC end Draft Derek Atkins T 2014-06-03 draft-ietf-isis-fs-lsp-02 Rob Austein T 2014-06-04 draft-ietf-nvo3-framework-07 Dorothy Gellert T 2014-06-10 draft-ietf-mmusic-udptl-dtls-07 Sam Hartman T 2014-04-08 draft-ietf-l2vpn-vpls-ldp-mac-opt-12 Melinda Shore T 2014-05-26 draft-ietf-dnsop-delegation-trust-maintainance-13 Tom Yu T 2014-05-30 draft-ietf-6man-multicast-scopes-06 For telechat 2014-06-26 Shaun Cooley T 2014-06-12 draft-ietf-appsawg-sieve-duplicate-06 Last calls and special requests: Alan DeKok 2014-06-11 draft-ietf-hip-rfc4843-bis-05 Donald Eastlake 2014-06-11 draft-ietf-hip-rfc5201-bis-14 Shawn Emery 2014-06-11 draft-ietf-hip-rfc5202-bis-05 Steve Hanna 2014-06-09 draft-ietf-v6ops-enterprise-incremental-ipv6-05 Dan Harkins 2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-14 David Harrington 2014-06-16 draft-ietf-ppsp-peer-protocol-09 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-06 Julien Laganier E 2013-11-21 draft-ietf-websec-key-pinning-13 Julien Laganier 2014-04-29 draft-ietf-dhc-dhcpv4-over-dhcpv6-08 Russ Mundy 2014-03-24 draft-mahalingam-dutt-dcops-vxlan-09 Sandy Murphy 2013-12-17 draft-ietf-netmod-iana-timezones-03 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Ondrej Sury 2014-05-28 draft-ietf-ipfix-text-adt-05 David Waltermire 2014-06-10 draft-salgueiro-dispatch-websocket-sipclf-01 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-11 -- kivinen@iki.fi From nobody Thu Jun 5 08:54:51 2014 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A4DE71A03CC; Wed, 4 Jun 2014 12:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1401909280; bh=9D3c9/OXAdzzTyXk8ibLJy3HBQ0ALWtyhr8/v9m+Xu0=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=TimsbE/41PQxeMxn3QYWpBUBv4VKHEhXhZ6iWL5xSnPdj8uoWgxjpPqn69otmMIVM x8RUADjdnZq2Woj+qySrLxMsTutAkXCYklehaLnHpFdfVzWtb7MZTqW6Q+pTC6PZAZ +0HcQKtHdzk2tiMVgkmqQ4JFRF7JWKlC/mB8XLpU= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B33F1A03A1; Wed, 4 Jun 2014 12:14:29 -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 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 jSryTp0TfjKh; Wed, 4 Jun 2014 12:14:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A09EF1A0390; Wed, 4 Jun 2014 12:14:17 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140604191417.685.53890.idtracker@ietfa.amsl.com> Date: Wed, 04 Jun 2014 12:14:17 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/new-work/EJ3bnUBk6YMb5f_cg5flH-3Nw2c X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/_9Seq2g_Lj9upFvZ54awJRSRy8k X-Mailman-Approved-At: Thu, 05 Jun 2014 08:54:48 -0700 Subject: [secdir] [new-work] WG Review: Authentication and Authorization for Constrained Environments (ace) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 19:14:40 -0000 A new IETF working group has been proposed in the Security Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2014-06-14. Authentication and Authorization for Constrained Environments (ace) ------------------------------------------------ Current Status: Proposed WG Chairs: Hannes Tschofenig Kepeng Li Assigned Area Director: Kathleen Moriarty Mailing list Address: ace@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ace Archive: http://www.ietf.org/mail-archive/web/ace/current/maillist.html Charter: Authentication and Authorization for Constrained Environment (ACE) The IETF has recently developed protocols for use in constrained environments, where network nodes are limited in CPU, memory and power. REST architecture is widely used for such constrained environments. It has been observed that Internet protocols can be applied to these constrained environments, often only requiring minor tweaking and profiling. In other cases, new protocols have been defined to address the specific requirements of constrained environments. An example of such a protocol is the Constrained Application Protocol (CoAP). As in other environments, authentication and authorization questions also arise in constrained environments. For example, a door lock has to authorize the person seeking access using a "digital key". Where is the authorization policy stored? How does the digital key communicate with the lock? Does the lock interact with an authorization server to obtain authorization information? How can access be temporarily granted to other persons? How can access be revoked? These types of questions have been answered by existing protocols for use cases outside constrained environments, however in constrained environments, additional and different requirements pose challenges for the use of various security protocols. In particular, the need arises for a dynamic and fine grained access control mechanism, where clients and/or resource servers are constrained. The IETF has a long history in developing three-party authentication and authorization protocols for distributed environments. Examples include Kerberos, the Public Key Infrastructure (PKI), the Authentication, Authorization and Accounting (AAA) infrastructure, and the Web Authorization Protocol (OAuth). All these protocols enjoy widespread deployment on the Internet. Although they all aim to solve a similar goal, at an abstract level, they offer quite different functions and utilize different message exchanges. These differences result from the main deployment use cases they were designed for respectively. Requirements derived from use cases may indicate that existing work is useful as basis for a solution for constrained environments. These protocols, however, were not optimized for constrained environments. Additional requirements that need to be taken into account are the lack of a suitable user-interface and the inability of embedded devices to contact an authorization server in real-time with every resource access request due to intermittent connectivity, etc. This working group therefore aims to produce a standardized solution for authentication and authorization to enable authorized access (Get, Put, Post, Delete) to resources identified by a URI and hosted on a resource server in constrained environments. As a starting point, the working group will assume that access to resources at a resource server by a client device takes place using CoAP and is protected by DTLS. Both resource server and client may be constrained. This access will be mediated by an authorization server, which is not considered to be constrained. Existing authentication and authorization protocols will be evaluated and used where applicable to build the constrained-environment solution. This requires relevant specifications to be reviewed for suitability, selecting a subset of them and restricting the options within each of the specifications. Some functionality, however, may not be available in existing protocols, in which case the solution may also involve new protocol work. Leveraging existing work means the working group benefits from available security analysis, implementation, and deployment experience. Moreover, a standardized solution for federated authentication and authorization will help to stimulate the deployment of constrained devices that provide increased security. Once progress in identifying suitable candidate solutions has been made, the working group will verify whether the same mechanisms are also applicable beyond the use of CoAP and DTLS, which are the two main protocols the group will focus on for access to resources. In particular, the ability to use the developed solution over HTTP and TLS will be investigated. Note that the initial focus is on CoAP and HTTP with DTLS and TLS. Other security protocols may be considered as long as the primary focus is maintained. The group is scoped to work only on the web protocols and data carried within them. Furthermore, to guarantee smooth transition, the integration with existing deployments will be studied, particularly concerning the use of protocol translation proxies. This work does not make the assumption that the party offering application layer services is always the same party offering network access services. The working group has the following tasks: 1) Produce use cases and requirements 2) Identify authentication and authorization mechanisms suitable for resource access in constrained environments. Milestones: Jul 2014 Submit "Use cases and Requirements" as a WG item. Dec 2014 Submit "Authentication and Authorization Solution" as a WG item. Apr 2015 Optionally, submit "Use cases and Requirements" document to the IESG for publication as an Informational RFC. Jul 2016 Submit "Authentication and Authorization Solution" specification to the IESG for publication as a Proposed Standard. _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Fri Jun 6 08:13:13 2014 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E901A0359; Thu, 5 Jun 2014 14:31:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1402003884; bh=7RR/C0/eppIkZYWg3fnTAK6UmTynS3atIfIow38UWgg=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=Xl2hWPnkFg1kiuF4KCUzcuadKsy4ej8hqiK3hUswwqrysytpvforTOZMPzyIr/Za9 mODrH07cY4VgvCWGwaWB3y9yHPjtLaOM+zfOcvSZ1iWlUo55V6O9XdPPLpTRLObyOb UvPXlNBBmsxqZw0XgWgKWNgXyoZqcv3r+2tu6FkI= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D10591A0336; Thu, 5 Jun 2014 14:31:22 -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 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 Su5trDfXPj2p; Thu, 5 Jun 2014 14:31:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 048461A034B; Thu, 5 Jun 2014 14:31:20 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140605213120.25084.97055.idtracker@ietfa.amsl.com> Date: Thu, 05 Jun 2014 14:31:20 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/new-work/INUbzDrdsOOQ8WYPdRZNM70O76c X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/sZFMYJHdUiCDRRonk-VzsiG1WBU X-Mailman-Approved-At: Fri, 06 Jun 2014 08:13:11 -0700 Subject: [secdir] [new-work] WG Review: TCP Increased Security (tcpinc) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 21:31:24 -0000 A new IETF working group has been proposed in the Transport Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2014-06-15. TCP Increased Security (tcpinc) ------------------------------------------------ Current Status: Proposed WG Technical advisors: Stephen Farrell Assigned Area Director: Martin Stiemerling Mailing list Address: tcpcrypt@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/tcpcrypt Archive: http://www.ietf.org/mail-archive/web/tcpcrypt/ Charter: The TCPINC WG will develop the TCP extensions to provide unauthenticated encryption and integrity protection of TCP streams. The WG will define an unauthenticated key exchange mechanism. In addition, the WG will define the TCP extensions to utilize unauthenticated keys, resulting in encryption and integrity protection without authentication. This is better than plain-text because it thwarts passive eavesdropping, but is weaker than using authenticated keys, because it is vulnerable to man- in-the-middle attacks during the initial unathenticated key exchange. This work is part of the IETF effort to evolve the Internet architecture given the latest events of pervasive monitoring (see BCP 188). The goal of this WG is to provide an additional security tool that complements existing protocols at other layers in the stack. The WG will be looking for the designs that find the right tradeoff spot between conflicting requirements: to provide reasonable security for the majority of connections. This work will deal with unprotected connections, and therefore will focus more on improvements from a baseline of no security than on achieving the high standard of security that is already available to users of authenticated TLS. Providing unauthenticated encryption and integrity protection at the TCP layer will provide a set of features that cannot be achieved with existing tools. Those features include: - encryption and integrity protection without modifications to the upper layers (no API changes), - encryption and integrity protection with forward secrecy with a per-connection granularity, - simple NAT and firewall traversal capabilities, - key rollover without significant impact to the TCP connection, - lower overhead compared to solutions relying in stacking multiple protocols to achieve different features, - no manual configuration required. A more detailed description of the motivations for TCP-based solutions can be found in draft-bellovin-tcpsec-01 and in RFC5925. The working group will produce documents specifying the required TCP extensions and additional documents needed. The high-level requirements for the protocol for providing TCP unauthenticated encryption and integrity protection are: - It should work over the vast majority of paths that unmodified TCP works over, in particular it must be compatible with NATs (at the very minimum with the NATs that comply with BEHAVE requirements as documented in RFC4787, RFC5382 and RFC5508). - The protocol must be usable by unmodified applications. This effort is complementary to other security protocols developed in the IETF (such as TLS) as it protects those applications and protocols that are difficult to change or may even not be able to be changed in a backward compatible way. It also provides some protection in scenarios where application developers are unwilling to change their applications (e.g., by configuring encryption) solely for the sake of improving security. - The protocol must provide cryptographic algorithm agility. - The protocol must gracefully fall-back to TCP if the remote peer does not support the proposed extensions. - When encryption is enabled, it must at least provide protection against passive eavesdropping by default, - Any required TCP option should use a minimum amount of TCP option space, especially in SYN segments. - The protocol must not require any authentication or configuration from applications or users. However, hooks for external authentication must be made available. The WG will not work on new authentication mechanisms. - The protocol must have acceptable performance, including acceptable latency and processing overheads. For example, the protocol may try to re-use existing cryptographic material for future communication between the same endpoints to avoid expensive public key operations on connection set up. When encryption is enabled, then the protocol: - must always provide forward secrecy. - must always provide integrity protection of the payload data (it is open for discussion for the WG if the TCP header should or should not be protected). - must always provide payload encryption. - must not provide extra linkability: when encryption is enabled, the TCP traffic should not give a third party observer any extra way to associate those packets with the specific peers beyond information that would have been present in a cleartext session. - must allow the initiator of the connection to avoid fingerprinting: some initiators may want to avoid appearing as the same endpoint when connecting to a remote peer on subsequent occasions. This should either be the default or some mechanism should be available for initiators to drop or ignore shared state to avoid being fingerprintable any more than would be the case for a cleartext session. Security features at the TCP-level can benefit other TCP extensions. For example, both Multipath TCP and TCP Fast Open require proof that some connections are related. Session resumption and Message Authentication Codes (MACs) can provide this evidence. The working group should identify synergies and design the security protocol in such a way that other TCP efforts can benefit from it. Of course, TCP extensions that break must be identified too, and kept to a minimum. The working group will produce the following documents: - A framework for unauthenticated encryption and integrity protection of TCP connections. This document will describe basic design considerations, including the motivation and the applicability of the proposed mechanism, the interaction with other security mechanisms in different layers of the stack, the interaction with external authentication mechanisms, the expected protection, privacy considerations and residual threats. - Definition of the unauthenticated key exchange mechanism and the extensions to current TCP to utilize unauthenticated key to provide encryption and integrity protection. This covers all the protocol changes required. This will be an experimental document. - An extended API describing how applications can obtain further benefits of the proposed extensions. In particular, the hooks for supporting external authentication will be defined in this document. This will be an informational document. Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Sun Jun 8 05:53:10 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830121A03C0; Sun, 8 Jun 2014 05:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.652 X-Spam-Level: X-Spam-Status: No, score=-102.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOz3J7nYcDSl; Sun, 8 Jun 2014 05:53:06 -0700 (PDT) Received: from www.gondrom.org (www.gondrom.org [91.250.114.153]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BC9C1A03BF; Sun, 8 Jun 2014 05:53:06 -0700 (PDT) X-No-Relay: not in my network DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=sXk67JIrTDaAGzsK3uVJgJH/5VdJjlcvdrGagrwYB5zWka80jDNQ/Jeu6ZjjGan9bMfd04ioIhR9qkB+zPGg8RSKLQnKZavpuP3LXXQe0vaiOPSopvWslbfKwy8g+OmL+E1ZnrJama/N5l1zkGRimHfAMcwiKYRutFOD1csfg50=; h=X-No-Relay:X-No-Relay:X-No-Relay:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-Priority:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.169.100.115] (249.Red-81-44-81.dynamicIP.rima-tde.net [81.44.81.249]) by www.gondrom.org (Postfix) with ESMTPSA id 290C21539004E; Sun, 8 Jun 2014 14:52:55 +0200 (CEST) Message-ID: <53945CA4.2050108@gondrom.org> Date: Sun, 08 Jun 2014 13:52:52 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: jouni.maenpaa@ericsson.com, draft-ietf-p2psip-self-tuning.all@tools.ietf.org X-Priority: 4 (Low) References: <53823E4A.6080106@gondrom.org> <5389CF23.8020007@gondrom.org> <27112A697EB8204D9943EAB8A0E16B711080CB41@ESESSMB305.ericsson.se> In-Reply-To: <27112A697EB8204D9943EAB8A0E16B711080CB41@ESESSMB305.ericsson.se> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/F5jYZYcv84jE-6CWcH-ipCKDYuc Cc: iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-p2psip-self-tuning-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 12:53:08 -0000 Hi Jouni, thanks a lot for the explanation. That answers my question. Best wishes, Tobias On 08/06/14 10:37, Jouni Mäenpää wrote: > Hi, > > Thanks for the comments! > >> How did you determine the value of 75th percentile? Is this based on research >> or experience or derived from some other estimates? > We implemented the mechanisms specified in draft-p2psip-self-tuning in our P2PSIP prototype and ran an extensive set of simulations and PlanetLab experiments to determine appropriate values for the parameters. We found that the 75th percentile was a slightly better choice than for instance using the median. This is because if the received estimates happen to vary greatly, it is safer to pick a value that is higher than the median to ensure that the stabilization rate that will be used will be sufficiently high. Using the 75th percentile also enables faster reaction to increasing churn rate. > >> Is this choice influenced by number of peers or churn in certain environments. > The choice of using the 75th percentile is not influenced by the number of peers or the churn rate - we have found the 75th percentile to perform well regardless of the size of the overlay network and the churn rate. > > Regards, > Jouni > > From: Tobias Gondrom [mailto:tobias.gondrom@gondrom.org] > Sent: 31. toukokuuta 2014 15:46 > To: draft-ietf-p2psip-self-tuning.all@tools.ietf.org > Cc: iesg@ietf.org; secdir@ietf.org > Subject: secdir review of draft-ietf-p2psip-self-tuning-11 > > 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 is standards track and describes how the default topology plugin of RELOAD can be extended to support self-tuning, that is, to adapt to changing operating conditions such as churn and network size. It extends the mandatory-to-implement chord-reload algorithm by making it self-tuning. > > The document appears ready for publication. > > With one note for the IESG: This security review did only consider this specification, but did not verify the scientific data and research that lead to this algorithm. > > The Security Consideration Section 8 seems appropriate for the draft. It also refers to the security considerations of RFC6940 (RELOAD Base). > > One personal question to the authors: > In section 8 and 6.5, you introduce the concept of "the statistical mechanisms applied in Section 6.5 (i.e., the use of 75th percentiles) to process the shared estimates a peer obtains help ensuring that estimates that are clearly different from..." > How did you determine the value of 75th percentile? Is this based on research or experience or derived from some other estimates? Is this choice influenced by number of peers or churn in certain environments. > Thank you and best regards. > > Tobias > From nobody Sun Jun 8 09:31:02 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43EB51A0089; Sun, 8 Jun 2014 09:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.352 X-Spam-Level: X-Spam-Status: No, score=-1.352 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kSDGZuieRWF; Sun, 8 Jun 2014 09:30:55 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B1F11A0114; Sun, 8 Jun 2014 09:30:55 -0700 (PDT) X-AuditID: 1209190c-f79946d000000c3b-9a-53948fbe2ba4 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 8B.9D.03131.EBF84935; Sun, 8 Jun 2014 12:30:54 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s58GUqCT028412; Sun, 8 Jun 2014 12:30:53 -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 s58GUnbM025816; Sun, 8 Jun 2014 12:30:50 -0400 From: Tom Yu To: iesg@ietf.org, secdir@ietf.org, draft-ietf-6man-multicast-scopes.all@tools.ietf.org Date: Sun, 08 Jun 2014 12:30:49 -0400 Message-ID: Lines: 59 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrAIsWRmVeSWpSXmKPExsUixG6nrruvf0qwQdNiEYsp9+ayWsz4M5HZ 4sPChywOzB5Llvxk8vhy+TNbAFMUl01Kak5mWWqRvl0CV8aMhnPsBe1SFT17ljI3MK4W7WLk 5JAQMJF49/g+K4QtJnHh3nq2LkYuDiGB2UwSr28uZoVwNjBKbPy7ECrzmlHizPnvLF2MHBxs AtISRxeXgXSLCCRIPD+6jwXEFhawlbj+aimYzSKgKjHr7m4mEJtXQFdiRdtjJpBWHgFOiSVL 4yHCghInZz4BK2cW0JK48e8l0wRG3llIUrOQpBYwMq1ilE3JrdLNTczMKU5N1i1OTszLSy3S NdTLzSzRS00p3cQICihOSZ4djG8OKh1iFOBgVOLhTeieHCzEmlhWXJl7iFGSg0lJlFekakqw EF9SfkplRmJxRnxRaU5q8SFGCQ5mJRFelyagHG9KYmVValE+TEqag0VJnPettVWwkEB6Yklq dmpqQWoRTFaGg0NJgndRH1CjYFFqempFWmZOCUKaiYMTZDgP0HBzkBre4oLE3OLMdIj8KUZF KXHeBb1ACQGQREZpHlwvLOJfMYoDvSLMqw7SzgNMFnDdr4AGMwEN/pU5EWRwSSJCSqqBkc2O 1ffVP7slv3duVr9btGrRhW3R5TurnYQDnpxfwL2OZffUDfvYE2bUaGr8b950Z1OW/5xKt7db 8p0rz7qHy7nJpDy6kLipYcuMC3f0lsdtmG8+LV4pjO9Nhf+F+W7c9ffjvtw4WjNl4vF1/zr+ yV19KHDZaoZHrnTXbGO3/fpn9thPuPN660YlluKMREMt5qLiRAAYyLuK0wIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/y0Of3fFOHdw2PUrNm948CgZ3wws Subject: [secdir] secdir review of draft-ietf-6man-multicast-scopes-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 16:30:57 -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 minor issues. This document defines the previously reserved IPv6 multicast scop value 3 to mean "realm-local scope". The intent appears to be that specifications about how to use IPv6 on top of the underlying link layer technology define the extent of realm-local scope. A potential minor security issue is whether a router that does not understand scop 3 addresses (as specified by this draft) and receives a packet with a scop 3 destination address will forward the packet more widely than it should, or otherwise behave unexpectedly. This could be a problem for some resource-constrained deployment scenarios envisioned for this specification. The Security Considerations section of this draft states "This document has no security considerations beyond those in RFC 4007 [RFC4007] and RFC 4291 [RFC4291]." I think this document potentially increases the security consequences of behavior that was previously unspecified by RFC 4007 and RFC 4291. RFC 4291 specifies the behavior of a node that receives a packet with a multicast destination address with scop values 0 or F, but not for scop 3. Packets with scop 0 destination addresses must be dropped, and packets with scope F addresses must be treated as if they had global (scop E) multicast addresses. I can find no such previous specification for behavior for scop 3 packets. This raises the question of how existing implementations would behave if they were to receive packets destined to an address of scop 3, and whether this poses any security exposure. A conservative implementation might drop the packets, or treat them as if they had scop 2 (link-local). The requirements on scope zone boundaries specified in Section 5 of RFC 4007 appear to make this latter behavior safe. On the other hand, Section 4 of this draft updates RFC 4007 to resolve an ambiguity about whether scope 3 is automatically or administratively configured. Existing text in RFC 4007 implies that scop 3 zone boundaries are administratively configured, while RFC 4291 implies that scop 4 (admin-local) is the smallest scope whose boundaries are administratively configured. I don't know whether existing implementation behavior creates any practical security impact from this ambiguity. Because one stated use for realm-local scope is for multicast traffic in mesh networks, which seem likely to be resource constrained (in power, bandwidth, latency, error rate, etc.), I think it would be useful to analyze the resource exhaustion or denial of service potential of mixed deployments, where some routers understand the newly specified behavior for scop 3 addresses and some do not. I'm willing to believe that the consequences are negligible. It would be helpful to have a summary of known or predicted behaviors of existing implementations regarding scop 3 addresses, along with some analysis of how acceptable the security consequences of these behaviors are. From nobody Mon Jun 9 02:29:08 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88C11A0027; Mon, 9 Jun 2014 02:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvVLyX4efBE6; Mon, 9 Jun 2014 02:29:02 -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 8EC3E1A0026; Mon, 9 Jun 2014 02:29:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFF46558; Mon, 09 Jun 2014 09:28:59 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Jun 2014 10:28:59 +0100 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.167]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Mon, 9 Jun 2014 17:28:54 +0800 From: "Zhangdacheng (Dacheng)" To: "Keyur Patel (keyupate)" , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-idr-bgp-enhanced-route-refresh.all@tools.ietf.org" Thread-Topic: SECDIR Review of draft-ietf-idr-bgp-enhanced-route-refresh-06 Thread-Index: AQHPfJ7p3QZODynSR0imiS0zqxqnM5tfhdsAgAkLBBA= Date: Mon, 9 Jun 2014 09:28:54 +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.111.98.139] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/7rlZyeNNnhuemC_Ux3jr1-PYKZo Subject: Re: [secdir] SECDIR Review of draft-ietf-idr-bgp-enhanced-route-refresh-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 09:29:03 -0000 > -----Original Message----- > From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] > Sent: Wednesday, June 04, 2014 1:11 AM > To: Zhangdacheng (Dacheng); iesg@ietf.org; secdir@ietf.org; > draft-ietf-idr-bgp-enhanced-route-refresh.all@tools.ietf.org > Subject: Re: SECDIR Review of draft-ietf-idr-bgp-enhanced-route-refresh-0= 6 >=20 > Hi Dacheng, >=20 > Thanks a lot for the draft review. My comments are inlined. #Keyur >=20 > On 5/31/14 12:06 AM, "Zhangdacheng (Dacheng)" > > 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. > > > >This short document tries to enhance the existing BGP route refresh > >mechanisms to provide for the demarcation of the beginning and the > >ending of a route refresh. In order to achieve this, the "Reserved" > >field of the ROUTE-REFRESH message is redefined to indicate the > >beginning and the ending of a route refresh. I agree this extension > >will not introduce new security issues to the BGP protocol. > > > >The document is clear. I consider it ready with a few issues: > > > >I suggest defining how a BGP speaker should handle a EoRR without > >receiving the associated BoRR especially when the peer does not support > >graceful start. >=20 > #Keyur: The received EoRR message without an associated BoRR message > would pretty much be a no-op operation (as no routes are marked Stale). T= his > behavior is consistent with/without GR. >=20 > How about if we add the following line (Section 4, end of 5th paragraph > after: "Such purged routes MAY be logged for future analysis.") >=20 > A BGP speaker MAY ignore any EoRR message received without a prior receip= t > of an associated BoRR message. Such messages MAY be logged for future > analysis. >=20 [Dacheng Zhang:] That is good.=20 >=20 > > > > > >The description in the last paragraph of section 4 is not very clear. > >It would be better to briefly explain why the introduced procedures can > >simplify the interaction with the BGP Graceful Restart. In addition, > >the EOR and EoR messages (the typos of EoRR?) mentioned in this > >paragraph are not defined elsewhere. >=20 > Keyur: Good Point. How about adding the 2nd (clarification) line to the l= ast > paragraph of section 4: >=20 >=20 > The following procedures are specified in order to simplify the > interaction with the BGP Graceful Restart [RFC4724]. In particular, > these procedures ensure that > End-of-RIB (=B3EoR=B2) defined in Graceful Restart and EoRR as defined > in this specification > are kept separate, thereby avoiding any premature cleanup of stale rou= tes. > For a BGP > speaker that supports the BGP Graceful Restart, it MUST NOT send a > BoRR for an AFI/SAFI to a neighbor before it sends the EoR for the > AFI/SAFI to the neighbor. A BGP speaker that has received the > Graceful Restart Capability from its neighbor, MUST ignore any BoRRs > for an AFI/SAFI from the neighbor before the speaker receives the EoR > for the given AFI/SAFI from the neighbor. The BGP speaker SHOULD log > an error of the condition for further analysis. >=20 [Dacheng Zhang:] The new paragraph is much better. Thanks. ^_^ >=20 > Regards, > Keyur >=20 > > > >Cheers > > > >Dacheng > > From nobody Mon Jun 9 05:30:31 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFE31A00EF; Mon, 9 Jun 2014 05:30:30 -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 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 UpbKtmIX52lr; Mon, 9 Jun 2014 05:30:27 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4EA61A0095; Mon, 9 Jun 2014 05:30:27 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 788BA880E2; Mon, 9 Jun 2014 05:30:27 -0700 (PDT) Received: from 102523917.rudm2.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id E014371C0002; Mon, 9 Jun 2014 05:30:26 -0700 (PDT) Message-ID: <5395A8D9.2070006@innovationslab.net> Date: Mon, 09 Jun 2014 08:30:17 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Tom Yu , iesg@ietf.org, secdir@ietf.org, draft-ietf-6man-multicast-scopes.all@tools.ietf.org References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="SSoQ3hkrRcjlQfmlLMUdjd3nA5krmgdHq" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/q0d_7kh2_Uy7Qs3WeL8okxcjt_A Subject: Re: [secdir] secdir review of draft-ietf-6man-multicast-scopes-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 12:30:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SSoQ3hkrRcjlQfmlLMUdjd3nA5krmgdHq Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Tom, Thanks for the review. I do think that the rules in RFC 4007 adequately cover the boundary handling for realm-scoped multicast addresses. The general rule defined in 4007 is that a multicast packet is forwarded if there is forwarding state and a scope boundary is configured on the router that is equal to or greater than the scope contained in the multicast packet. Since scope=3D3 has not been explicitly defined in another RFC, the handling is strictly driven by 4007. This draft is creating a more tightly controlled use of scope=3D3 since it allows for the automatic creation of a scope boundary where before (i.e., RFC 4007) an administrator had to manually create the scope boundary. I am not sure what we would add to this document, but that is my $0.02 on the issue. SEC ADs? Regards, Brian On 6/8/14 12:30 PM, Tom Yu wrote: > I have reviewed this document as part of the security directorate's=20 > ongoing effort to review all IETF documents being processed by the=20 > IESG. These comments were written primarily for the benefit of the=20 > security area directors. Document editors and WG chairs should treat=20 > these comments just like any other last call comments. >=20 > Summary: ready with minor issues. >=20 > This document defines the previously reserved IPv6 multicast scop value= > 3 to mean "realm-local scope". The intent appears to be that > specifications about how to use IPv6 on top of the underlying link laye= r > technology define the extent of realm-local scope. A potential minor > security issue is whether a router that does not understand scop 3 > addresses (as specified by this draft) and receives a packet with a sco= p > 3 destination address will forward the packet more widely than it > should, or otherwise behave unexpectedly. This could be a problem for > some resource-constrained deployment scenarios envisioned for this > specification. >=20 > The Security Considerations section of this draft states >=20 > "This document has no security considerations beyond those in RFC > 4007 [RFC4007] and RFC 4291 [RFC4291]." >=20 > I think this document potentially increases the security consequences o= f > behavior that was previously unspecified by RFC 4007 and RFC 4291. RFC= > 4291 specifies the behavior of a node that receives a packet with a > multicast destination address with scop values 0 or F, but not for scop= > 3. Packets with scop 0 destination addresses must be dropped, and > packets with scope F addresses must be treated as if they had global > (scop E) multicast addresses. >=20 > I can find no such previous specification for behavior for scop 3 > packets. This raises the question of how existing implementations woul= d > behave if they were to receive packets destined to an address of scop 3= , > and whether this poses any security exposure. A conservative > implementation might drop the packets, or treat them as if they had sco= p > 2 (link-local). The requirements on scope zone boundaries specified in= > Section 5 of RFC 4007 appear to make this latter behavior safe. >=20 > On the other hand, Section 4 of this draft updates RFC 4007 to resolve > an ambiguity about whether scope 3 is automatically or administratively= > configured. Existing text in RFC 4007 implies that scop 3 zone > boundaries are administratively configured, while RFC 4291 implies that= > scop 4 (admin-local) is the smallest scope whose boundaries are > administratively configured. I don't know whether existing > implementation behavior creates any practical security impact from this= > ambiguity. >=20 > Because one stated use for realm-local scope is for multicast traffic i= n > mesh networks, which seem likely to be resource constrained (in power, > bandwidth, latency, error rate, etc.), I think it would be useful to > analyze the resource exhaustion or denial of service potential of mixed= > deployments, where some routers understand the newly specified behavior= > for scop 3 addresses and some do not. I'm willing to believe that the > consequences are negligible. It would be helpful to have a summary of > known or predicted behaviors of existing implementations regarding scop= > 3 addresses, along with some analysis of how acceptable the security > consequences of these behaviors are. >=20 --SSoQ3hkrRcjlQfmlLMUdjd3nA5krmgdHq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTlajeAAoJEBOZRqCi7goq6LUIAIeZZe2Etn+idvJVlQw20XqS RWy/6G42WLs0kGZKMFfLfeoOG7AdCj4uEjau6P/n5PQ28ln4P6Jb0xQrWCAk1W1K vJ37cl9AY1ETfEjYFDCllxdYC3N8a+aVjloZ5tKivFrWZ30uY3yT5/3Opdd224Lv 4NfNPYv0dWb3IlTHWjq4WV0BjIsFHoxreGepSWdMzZACyR1Q0HzmEUfJ3gAmNYh6 zUlDNMx2WmaQ/zeX3AdGqki21+rFL5SoUFpUWscVT4bD9WMFpRI/sa0MlcqOcZdj Knx8RnQGWkBAzVKcc0XzQPaeMZ/LBLROzAB6uiWX8X/gDUNE+hLhjm8T6BoAQTk= =SCNq -----END PGP SIGNATURE----- --SSoQ3hkrRcjlQfmlLMUdjd3nA5krmgdHq-- From nobody Mon Jun 9 08:18:38 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9461A030A; Sun, 8 Jun 2014 02:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jP-RREUM1wsT; Sun, 8 Jun 2014 02:37:28 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 498A61A02F7; Sun, 8 Jun 2014 02:37:27 -0700 (PDT) X-AuditID: c1b4fb30-f79a56d000006536-e7-53942ece4b9b Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id E2.96.25910.ECE24935; Sun, 8 Jun 2014 11:37:18 +0200 (CEST) Received: from ESESSMB305.ericsson.se ([169.254.5.52]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0174.001; Sun, 8 Jun 2014 11:37:18 +0200 From: =?iso-8859-1?Q?Jouni_M=E4enp=E4=E4?= To: Tobias Gondrom , "draft-ietf-p2psip-self-tuning.all@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-p2psip-self-tuning-11 Thread-Index: AQHPfM6P2ObWwRutakGSq/fTjwpe/Ztm+wVQ Date: Sun, 8 Jun 2014 09:37:17 +0000 Message-ID: <27112A697EB8204D9943EAB8A0E16B711080CB41@ESESSMB305.ericsson.se> References: <53823E4A.6080106@gondrom.org> <5389CF23.8020007@gondrom.org> In-Reply-To: <5389CF23.8020007@gondrom.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM+Jvje45vSnBBp23tS2WfrnPajHjz0Rm iw8LH7JY3Fown9GBxePBnflMHkuW/GTy+HL5M1sAcxSXTUpqTmZZapG+XQJXxtPnK9gLFotX /Lw5l7GBsVm4i5GTQ0LAROL4tBeMELaYxIV769m6GLk4hASOMkps2NTNDOEsYpRo6elmB6li E3CXOHzzJytIQkRgFqPE9d4Gli5GDg5mAQ+J7if6IDXCAnYS136fZQGxRQTsJZ4/2cEIYRtJ TO3YyQxiswioSKybvAOshlfAV2L64jY2EFtIwFOiccZlsBpOAW2JC/u+s4LYjEDXfT+1hgnE ZhYQl7j1ZD4TxNUCEkv2nGeGsEUlXj7+xwphK0ksuv0Zql5P4sbUKWwQtrbEsoWvmSH2Ckqc nPmEZQKj2CwkY2chaZmFpGUWkpYFjCyrGEWLU4uTctONjPRSizKTi4vz8/TyUks2MQLj6+CW 3wY7GF8+dzzEKMDBqMTDm9A9OViINbGsuDL3EKM0B4uSOO9FjepgIYH0xJLU7NTUgtSi+KLS nNTiQ4xMHJxSDYyShxNUc851zsl7PdPKx8jhut+BLK1p/7LXOB4tyjA9MnlKsMSMjluWLW9k VX+cUDlSMMHylsZDg6RdwSrxy7Ic96yYvdWMtW0ue+IK68WGmqnqTEwlqxRKg7xUvvlujJtY z+qw9kudeZL/sadn72ouD8z5nhO2KoG58fDxTQGZp4w2xOu0hSqxFGckGmoxFxUnAgC/KeR/ kAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/WSuUrjHEKUoJWhU1l5fPxMniMSU X-Mailman-Approved-At: Mon, 09 Jun 2014 08:18:36 -0700 Cc: "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-p2psip-self-tuning-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 09:37:29 -0000 Hi, Thanks for the comments! > How did you determine the value of 75th percentile? Is this based on rese= arch > or experience or derived from some other estimates?=20 We implemented the mechanisms specified in draft-p2psip-self-tuning in our = P2PSIP prototype and ran an extensive set of simulations and PlanetLab expe= riments to determine appropriate values for the parameters. We found that t= he 75th percentile was a slightly better choice than for instance using the= median. This is because if the received estimates happen to vary greatly, = it is safer to pick a value that is higher than the median to ensure that t= he stabilization rate that will be used will be sufficiently high. Using th= e 75th percentile also enables faster reaction to increasing churn rate. > Is this choice influenced by number of peers or churn in certain environm= ents. The choice of using the 75th percentile is not influenced by the number of = peers or the churn rate - we have found the 75th percentile to perform well= regardless of the size of the overlay network and the churn rate. Regards, Jouni From: Tobias Gondrom [mailto:tobias.gondrom@gondrom.org]=20 Sent: 31. toukokuuta 2014 15:46 To: draft-ietf-p2psip-self-tuning.all@tools.ietf.org Cc: iesg@ietf.org; secdir@ietf.org Subject: secdir review of draft-ietf-p2psip-self-tuning-11 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG.=A0 These = comments were written primarily for the benefit of the security area direct= ors.=A0 Document editors and WG chairs should treat these comments just lik= e any other last call comments. The draft is standards track and describes how the default topology plugin = of RELOAD can be extended to support self-tuning, that is, to adapt to chan= ging operating conditions such as churn and network size. It extends the ma= ndatory-to-implement chord-reload algorithm by making it self-tuning. The document appears ready for publication. With one note for the IESG: This security review did only consider this spe= cification, but did not verify the scientific data and research that lead t= o this algorithm. The Security Consideration Section 8 seems appropriate for the draft. It al= so refers to the security considerations of RFC6940 (RELOAD Base).=A0=20 One personal question to the authors:=20 In section 8 and 6.5, you introduce the concept of "the statistical mechani= sms applied in Section 6.5 (i.e., the use of 75th percentiles) to process t= he shared estimates a peer obtains help ensuring that estimates that are cl= early different from..." How did you determine the value of 75th percentile? Is this based on resear= ch or experience or derived from some other estimates? Is this choice influ= enced by number of peers or churn in certain environments.=20 Thank you and best regards.=20 Tobias=20 From nobody Mon Jun 9 10:02:18 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D44C1A0274; Mon, 9 Jun 2014 10:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENyo5wNHFcCm; Mon, 9 Jun 2014 10:02:13 -0700 (PDT) Received: from hannas.com (hannas.com [206.130.105.83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52B2E1A0286; Mon, 9 Jun 2014 10:02:12 -0700 (PDT) Received: from [192.168.1.4] (c-50-164-134-218.hsd1.ma.comcast.net [50.164.134.218]) (authenticated bits=0) by hannas.com (8.13.1/8.13.1) with ESMTP id s59H29LJ019933; Mon, 9 Jun 2014 11:02:09 -0600 Message-ID: <5395E891.7090505@hannas.com> Date: Mon, 09 Jun 2014 13:02:09 -0400 From: Steve Hanna User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: iesg@ietf.org, secdir@ietf.org, draft-ietf-v6ops-enterprise-incremental-ipv6.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/UzI2Uzmz83BKBiVHCNCq-Rf_ri4 Subject: [secdir] secdir review of draft-ietf-v6ops-enterprise-incremental-ipv6-05.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 17:02:15 -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 provides advice for enterprise administrators working on deploying IPv6 in their networks. I don't have much experience in this area (deploying IPv6 on an enterprise network) and I'm not even an IPv6 security expert but... I found the document easy to understand, thorough, and apparently based on real experiences. I was happy to see that security issues were thoroughly covered throughout and that simple, practical recommendations were given. I did find a few tiny typos and possible clarifications that are listed at the end of this email. In my view, this document is Ready with nits. The nits are tiny so they can be handled in AUTH48 or whenever the next draft is posted. Thanks, Steve ----------- Small Typos in draft-ietf-v6ops-enterprise-incremental-ipv6-05.txt * At the bottom of page 12, there is an extra close parenthesis after the word "implemented". * On page 17, "outside worlds" should be "outside world". * On page 20, at the end of section 3.5, "included both" should be "including both". At least, I think so. It's not quite clear what this parenthetical comment means. If it means that use of NPTv6 can be chosen independently of whether PA or PI addresses are used, this text might be better: Use of NPTv6 can be chosen independently from how addresses are assigned and routed within the internal network, how prefixes are routed towards the Internet, or whether PA or PI addresses are used. From nobody Mon Jun 9 21:24:29 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6C51A0396; Mon, 9 Jun 2014 21:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVS-W9oyR2EN; Mon, 9 Jun 2014 21:24:24 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 091DB1A0398; Mon, 9 Jun 2014 21:24:23 -0700 (PDT) X-AuditID: 1209190e-f79946d000000c39-d7-53968876d6f8 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 7E.7C.03129.67886935; Tue, 10 Jun 2014 00:24:23 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s5A4OLf8025995; Tue, 10 Jun 2014 00:24:22 -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 s5A4OIVd001227; Tue, 10 Jun 2014 00:24:19 -0400 From: Tom Yu To: Brian Haberman References: <5395A8D9.2070006@innovationslab.net> Date: Tue, 10 Jun 2014 00:24:18 -0400 In-Reply-To: <5395A8D9.2070006@innovationslab.net> (Brian Haberman's message of "Mon, 9 Jun 2014 08:30:17 -0400") Message-ID: Lines: 20 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixG6nolveMS3YYHE7s8XMnn+MFlPuzWW1 mPFnIrPFh4UPWRxYPJYs+cnkMfP4FxaPL5c/swUwR3HZpKTmZJalFunbJXBlHDiXXfCKo6Kj p4mtgXE6excjJ4eEgInEtYYdjBC2mMSFe+vZuhi5OIQEZjNJbOnaxgLhbGSUuHHlLyOE84ZR 4s2HJUBlHBxsAtISRxeXgXSLCOhKNHasYAGxmQXSJO6d3MwMYgsLOEpMXLQRbIOQQKjEhS3X weIsAqoSRzv7weKcAsUSzc03mEFG8gLNmT0xAiTMI8Apsej3PDYQm1dAUOLkzCdQ47Ukbvx7 yTSBUWAWktQsJKkFjEyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdI31cjNL9FJTSjcxgkKVU5Jv B+PXg0qHGAU4GJV4eC0OTA0WYk0sK67MPcQoycGkJMqbVDYtWIgvKT+lMiOxOCO+qDQntfgQ owQHs5IIL+tHoHLelMTKqtSifJiUNAeLkjjvW2urYCGB9MSS1OzU1ILUIpisDAeHkgSvcTvQ UMGi1PTUirTMnBKENBMHJ8hwHqDhvm1ANbzFBYm5xZnpEPlTjIpS4rx7QRICIImM0jy4Xlgq ecUoDvSKMK8byAoeYBqC634FNJgJaLBoBMjVxSWJCCmpBsb8+10rWSLaoyw3Tue+3LfviOH+ xn2uejX+R/jvsa9La9lqyqD42HxdbclKuQOehyucJlgtiXo9x+eq5wk+nlkeXx8uyJ7DO8Fh JesFje64xNPTvrzfFZX0f/O35mcRTkY9pq7fZxhPvfTB/ua5F/nCrDbSp1nCymZtjXphY74z +PX8FraFgo+VWIozEg21mIuKEwFqeU4XAAMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/xuvY8CrQkclV5WRHuQeKBNG_PQo Cc: iesg@ietf.org, draft-ietf-6man-multicast-scopes.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-6man-multicast-scopes-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 04:24:25 -0000 Brian Haberman writes: > I do think that the rules in RFC 4007 adequately cover the boundary > handling for realm-scoped multicast addresses. The general rule defined > in 4007 is that a multicast packet is forwarded if there is forwarding > state and a scope boundary is configured on the router that is equal to > or greater than the scope contained in the multicast packet. I'm not sure I see where that behavior is defined in RFC 4007, but perhaps I lack context or am misreading something. What happens when a router receives a packet destined for an address having scope=3, but the router doesn't have an explicitly-configured zone boundary for that scope and also doesn't understand realm-local scope? Would it drop the packet (no routing information for the unconfigured zone of scope=3) or restrict it to the largest zone of lower scope (protect inter-zone integrity)? Wouldn't forwarding that packet within a larger zone and scope cause the packet to possibly leave its intended zone, where its destination address might have a meaning unintended by the sender? From nobody Tue Jun 10 05:20:34 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04891A007F; Tue, 10 Jun 2014 05:20:31 -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 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 aFzVmjJ28Z1m; Tue, 10 Jun 2014 05:20:27 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE7851A009C; Tue, 10 Jun 2014 05:20:13 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 96B37880E2; Tue, 10 Jun 2014 05:20:13 -0700 (PDT) Received: from clemson.local (nat-gwifi.jhuapl.edu [128.244.87.132]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 1B3C113680F2; Tue, 10 Jun 2014 05:20:13 -0700 (PDT) Message-ID: <5396F7F4.8030507@innovationslab.net> Date: Tue, 10 Jun 2014 08:20:04 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Tom Yu References: <5395A8D9.2070006@innovationslab.net> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7Tw40QAwjFRh8e9vGB5126agqtiW048gL" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/eDbQCgsK6SrZChHk648fFsnaDCI Cc: iesg@ietf.org, draft-ietf-6man-multicast-scopes.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-6man-multicast-scopes-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 12:20:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7Tw40QAwjFRh8e9vGB5126agqtiW048gL Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Tom, On 6/10/14 12:24 AM, Tom Yu wrote: > Brian Haberman writes: >=20 >> I do think that the rules in RFC 4007 adequately cover the bounda= ry >> handling for realm-scoped multicast addresses. The general rule defin= ed >> in 4007 is that a multicast packet is forwarded if there is forwarding= >> state and a scope boundary is configured on the router that is equal t= o >> or greater than the scope contained in the multicast packet. >=20 > I'm not sure I see where that behavior is defined in RFC 4007, but > perhaps I lack context or am misreading something. What happens when a= > router receives a packet destined for an address having scope=3D3, but = the > router doesn't have an explicitly-configured zone boundary for that > scope and also doesn't understand realm-local scope? Would it drop the= > packet (no routing information for the unconfigured zone of scope=3D3) = or > restrict it to the largest zone of lower scope (protect inter-zone > integrity)? I think the context needed is in the second list in section 5 of 4007. If a router does not have a boundary instantiated for scope=3D3 *or larger*, the packet would be forwarded if forwarding state exists for the multicast address. If no forwarding state exists for that address or a boundary exists for scope>=3D3, the packet is dropped. >=20 > Wouldn't forwarding that packet within a larger zone and scope cause th= e > packet to possibly leave its intended zone, where its destination > address might have a meaning unintended by the sender? >=20 There are two rules in 4007 that cover this... o Zones of the same scope cannot overlap; i.e., they can have no links or interfaces in common. o A zone of a given scope (less than global) falls completely within zones of larger scope. That is, a smaller scope zone cannot include more topology than would any larger scope zone with which it shares any links or interfaces. Regards, Brian --7Tw40QAwjFRh8e9vGB5126agqtiW048gL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTlvf7AAoJEBOZRqCi7goqUw4H/1p446pjvUi+0tCmSh7QQ0iO in7vUzOJ2YemVjXl9pKsjV6Jtba1Lakj1RHfPOt5vgKsSeYwEJuaLX7wRQpzdn/f Vs0eGUQ0IDldpGKb35Gz+E+vypZXo2g3jevA9VMzmZo2KHeSG9vxENS0OQ8FvRoc JQITIpUJ0qBB570AfQNiQDfI5fBb6+S4SnKi3pmilCQkjINRu5LLI4ldD6CCNc69 cILEtxTQilC1rPMtJrTOaFvCBmG8In2FVN5tQa+3+vc3DBoHTJdZwzUEhI1ccybb ZwBpvj7FHzxmmfEJ/b8Kh8VVkKmhVRTHYu7W+lbCGUQY1/DeJGfiio6axhFx/j8= =3Zew -----END PGP SIGNATURE----- --7Tw40QAwjFRh8e9vGB5126agqtiW048gL-- From nobody Thu Jun 12 03:03:08 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1E151B2820 for ; Thu, 12 Jun 2014 03:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.772 X-Spam-Level: X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvbNeqYpLJ8B for ; Thu, 12 Jun 2014 03:03:04 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 658801A0325 for ; Thu, 12 Jun 2014 03:03:04 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s5CA31rt001093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 12 Jun 2014 13:03:01 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s5CA30DZ029909; Thu, 12 Jun 2014 13:03:00 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21401.31444.799552.481247@fireball.kivinen.iki.fi> Date: Thu, 12 Jun 2014 13:03:00 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/dQ1zNO8JcrpZ7w8diKcUINQI-2E Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 10:03:06 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Charlie Kaufman is next in the rotation. For telechat 2014-06-12 Reviewer LC end Draft Derek Atkins T 2014-06-03 draft-ietf-isis-fs-lsp-02 Rob Austein T 2014-06-04 draft-ietf-nvo3-framework-07 Dorothy Gellert T 2014-06-10 draft-ietf-mmusic-udptl-dtls-07 Sam Hartman T 2014-04-08 draft-ietf-l2vpn-vpls-ldp-mac-opt-12 Melinda Shore T 2014-05-26 draft-ietf-dnsop-delegation-trust-maintainance-14 For telechat 2014-06-26 Shaun Cooley T 2014-06-12 draft-ietf-appsawg-sieve-duplicate-06 Alan DeKok T 2014-06-11 draft-ietf-hip-rfc4843-bis-05 Donald Eastlake T 2014-06-11 draft-ietf-hip-rfc5201-bis-14 Shawn Emery T 2014-06-11 draft-ietf-hip-rfc5202-bis-05 Simon Josefsson T 2014-06-25 draft-ietf-tram-stun-dtls-03 For telechat 2014-07-10 David Harrington T 2014-06-16 draft-ietf-ppsp-peer-protocol-09 Last calls and special requests: Dan Harkins 2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-14 Sam Hartman 2014-06-23 draft-ietf-dnsop-child-syncronization-01 Paul Hoffman 2014-06-20 draft-ietf-tls-encrypt-then-mac-02 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-06 Jeffrey Hutzelman 2014-06-20 draft-ietf-mmusic-rtsp-nat-21 Chris Inacio 2014-06-23 draft-ietf-mpls-smp-requirements-06 Leif Johansson 2014-06-24 draft-ietf-netext-wifi-epc-eap-attributes-08 Julien Laganier E 2013-11-21 draft-ietf-websec-key-pinning-13 Julien Laganier 2014-04-29 draft-ietf-dhc-dhcpv4-over-dhcpv6-08 Russ Mundy 2014-03-24 draft-mahalingam-dutt-dcops-vxlan-09 Sandy Murphy 2013-12-17 draft-ietf-netmod-iana-timezones-03 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Ondrej Sury 2014-05-28 draft-ietf-ipfix-text-adt-05 David Waltermire 2014-06-10 draft-salgueiro-dispatch-websocket-sipclf-01 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-11 -- kivinen@iki.fi From nobody Thu Jun 12 07:30:32 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC0B1A01EB; Thu, 12 Jun 2014 07:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9NewIanewVF; Thu, 12 Jun 2014 07:30:30 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AA711A012D; Thu, 12 Jun 2014 07:30:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id CBFCAE2033; Thu, 12 Jun 2014 10:30:28 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 17738-10; Thu, 12 Jun 2014 10:30:26 -0400 (EDT) Received: from mocana.ihtfp.org (unknown [IPv6:fe80::224:d7ff:fee7:8924]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id C6A96E2031; Thu, 12 Jun 2014 10:30:26 -0400 (EDT) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.7/8.14.7/Submit) id s5CEUOcV014332; Thu, 12 Jun 2014 10:30:24 -0400 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Date: Thu, 12 Jun 2014 10:30:24 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Lz5LH-gLMzLav_hb1sliGnPcG0o Cc: ginsberg@cisco.com, isis-chairs@tools.ietf.org, yiya@cisco.com, sprevidi@cisco.com Subject: [secdir] sec-dir review of draft-ietf-isis-fs-lsp-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 14:30:31 -0000 Hi, (Sorry for the late review) I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. 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 see no issues with this document. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Jun 12 11:56:05 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBDC21B27D4 for ; Thu, 12 Jun 2014 11:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.352 X-Spam-Level: X-Spam-Status: No, score=-3.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLrWPPDvLMgX for ; Thu, 12 Jun 2014 11:56:01 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D4D21B27C5 for ; Thu, 12 Jun 2014 11:56:01 -0700 (PDT) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5CItwv3024420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jun 2014 14:56:00 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s5CItwv3024420 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1402599360; bh=wgIlyLpo2d6+JuMQzYMXuQHSIA0=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=TFYSNCPohCiNZ+gc03+LLc3Cm/KVEVVXqbZwSs7o9iFgLwgexeiEfzkQ54wxbe2Ei /Vx6z5cztdSaWf0Xubar+dYssuSiWAfotF2Qr59oPRqiuo5rqSKb4x0z+LJo0HsS09 CL2ny1/HN7hqTtLO75qQqOiGyr3EvYNtr9ylN68Y= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s5CItwv3024420 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd06.lss.emc.com (RSA Interceptor); Thu, 12 Jun 2014 11:55:44 -0700 Received: from mxhub11.corp.emc.com (mxhub11.corp.emc.com [10.254.92.106]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5CItim1006731 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Jun 2014 14:55:44 -0400 Received: from mx15a.corp.emc.com ([169.254.1.248]) by mxhub11.corp.emc.com ([10.254.92.106]) with mapi; Thu, 12 Jun 2014 14:55:44 -0400 From: "Moriarty, Kathleen" To: "secdir-secretary@mit.edu" Date: Thu, 12 Jun 2014 14:55:44 -0400 Thread-Topic: [secdir] Assignments Thread-Index: Ac+Gb+m13a5LqMy1S4CC64g7i0uLkA== Message-ID: <244FEBC3-D4A8-4CA2-808E-D112ECA7480F@emc.com> References: <21401.31444.799552.481247@fireball.kivinen.iki.fi> In-Reply-To: <21401.31444.799552.481247@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/qoFNkw_rXNrV1GiTuqJBAXRNwsw Cc: "secdir@ietf.org" Subject: Re: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 18:56:04 -0000 Thank you to each of you assisting with SecDir reviews. The next telechat = (2 weeks) is already starting to pile up, so your timely reviews will be ve= ry much appreciated! We didn't get many reviews this past week. Where it seems to help most is = that you have found and sorted through some important issues, reducing what= has to get discussed for the telechat. Thanks again! Thanks, Kathleen & Stephen Sent from my iPhone > On Jun 12, 2014, at 6:03 AM, "Tero Kivinen" wrote: >=20 > Review instructions and related resources are at: > http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >=20 > Charlie Kaufman is next in the rotation. >=20 > For telechat 2014-06-12 >=20 > Reviewer LC end Draft > Derek Atkins T 2014-06-03 draft-ietf-isis-fs-lsp-02 > Rob Austein T 2014-06-04 draft-ietf-nvo3-framework-07 > Dorothy Gellert T 2014-06-10 draft-ietf-mmusic-udptl-dtls-07 > Sam Hartman T 2014-04-08 draft-ietf-l2vpn-vpls-ldp-mac-opt-12 > Melinda Shore T 2014-05-26 draft-ietf-dnsop-delegation-trust-mai= ntainance-14 >=20 >=20 > For telechat 2014-06-26 >=20 > Shaun Cooley T 2014-06-12 draft-ietf-appsawg-sieve-duplicate-06 > Alan DeKok T 2014-06-11 draft-ietf-hip-rfc4843-bis-05 > Donald Eastlake T 2014-06-11 draft-ietf-hip-rfc5201-bis-14 > Shawn Emery T 2014-06-11 draft-ietf-hip-rfc5202-bis-05 > Simon Josefsson T 2014-06-25 draft-ietf-tram-stun-dtls-03 >=20 >=20 > For telechat 2014-07-10 >=20 > David Harrington T 2014-06-16 draft-ietf-ppsp-peer-protocol-09 >=20 > Last calls and special requests: >=20 > Dan Harkins 2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation= -14 > Sam Hartman 2014-06-23 draft-ietf-dnsop-child-syncronization= -01 > Paul Hoffman 2014-06-20 draft-ietf-tls-encrypt-then-mac-02 > Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-s= oap-06 > Jeffrey Hutzelman 2014-06-20 draft-ietf-mmusic-rtsp-nat-21 > Chris Inacio 2014-06-23 draft-ietf-mpls-smp-requirements-06 > Leif Johansson 2014-06-24 draft-ietf-netext-wifi-epc-eap-attrib= utes-08 > Julien Laganier E 2013-11-21 draft-ietf-websec-key-pinning-13 > Julien Laganier 2014-04-29 draft-ietf-dhc-dhcpv4-over-dhcpv6-08 > Russ Mundy 2014-03-24 draft-mahalingam-dutt-dcops-vxlan-09 > Sandy Murphy 2013-12-17 draft-ietf-netmod-iana-timezones-03 > Zach Shelby 2014-06-06 draft-housley-implementer-obligations= -02 > Ondrej Sury 2014-05-28 draft-ietf-ipfix-text-adt-05 > David Waltermire 2014-06-10 draft-salgueiro-dispatch-websocket-si= pclf-01 > Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-1= 1 > --=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 Fri Jun 13 06:00:48 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B651B2824 for ; Fri, 13 Jun 2014 06:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztfXafNIJEf6 for ; Fri, 13 Jun 2014 06:00:38 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0A78B1B283F for ; Fri, 13 Jun 2014 06:00:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 61964BEF1; Fri, 13 Jun 2014 14:00:37 +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 0Y7AVIUMdGcc; Fri, 13 Jun 2014 14:00:37 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3F610BE56; Fri, 13 Jun 2014 14:00:37 +0100 (IST) Message-ID: <539AF5F5.3060202@cs.tcd.ie> Date: Fri, 13 Jun 2014 14:00:37 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "secdir@ietf.org" References: <21401.31444.799552.481247@fireball.kivinen.iki.fi> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/RxpR1d5cMwh6SwZCV8G5v4RQ-iU Cc: Samuel Weiler Subject: Re: [secdir] rtg area wiki v. sec area X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 13:00:39 -0000 Thanks Sam. Folks - take a peek and we can chat in Toronto and/or on the list about whether this is worth doing. Cheers, S. On 13/06/14 13:44, Samuel Weiler wrote: > The routing area has one-upped us in terms of public info on their > directorate. I'm not sure the gain is worth the effort, but I encourage > you to look at what they've done. Specifically: > > Brief bios of directorate members: > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirExperience > (in a wiki, self-editted) > > AD's own version of id-nits: > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgADNits > > Scheduled reconsideration of directorate membership: > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirMember > > A directorate charter: > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirCharter > > Their own version of guidance to reviewers: > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirGuidance > From nobody Fri Jun 13 06:31:43 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E8E1B2880 for ; Fri, 13 Jun 2014 06:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YX2tHFvUKczg for ; Fri, 13 Jun 2014 06:31:37 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 989201B2884 for ; Fri, 13 Jun 2014 06:31:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1323; q=dns/txt; s=iport; t=1402666298; x=1403875898; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GcpEjQI9f9jx9dU02huJ4KCyrRYYWA9Uh2haF1l9aQY=; b=RUJqTDwNxNuu66pmgb0hgMrNsu34twAtewaeuuku6pbCl5iz663lJDwY kWsEj6ytoJuvbBxsXo8wdz2UzqH3Z0s9a+4mz6EpEm7XLiz/mRuR+on6D YwGJNgSSbKI1ZYalsgKGWFr96BhuzrS7gDZ6WRejcyOFflIVep1lGNKDl s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQGAKP8mlOtJV2d/2dsb2JhbABagw1SWalaAQQBBQGRY4ZrUQGBAxZ1hAMBAQEDAQEBATcyAggDEAIBCBgeECcLJQIEDgWIOggN0hcXhVyITTMHgyuBFgSaNoFDkhGDPGyBQw X-IronPort-AV: E=Sophos;i="5.01,471,1400025600"; d="scan'208";a="332704199" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 13 Jun 2014 13:31:37 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s5DDVahS009428 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Jun 2014 13:31:36 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.80]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Fri, 13 Jun 2014 08:31:36 -0500 From: "Klaas Wierenga (kwiereng)" To: Stephen Farrell Thread-Topic: [secdir] rtg area wiki v. sec area Thread-Index: AQHPhwefLsKtXCDfsU2A/NjX2KQoBptvXVgA Date: Fri, 13 Jun 2014 13:31:36 +0000 Message-ID: <39C064F6-20C3-4A1C-84AF-8E2C971F1E79@cisco.com> References: <21401.31444.799552.481247@fireball.kivinen.iki.fi> <539AF5F5.3060202@cs.tcd.ie> In-Reply-To: <539AF5F5.3060202@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.111.3] Content-Type: text/plain; charset="us-ascii" Content-ID: <37DEB871C6FF8F469518A667CDF59D89@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/vKv8n5ht4cPMGZzdjRLK7oLyU5E Cc: Samuel Weiler , "secdir@ietf.org" Subject: Re: [secdir] rtg area wiki v. sec area X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 13:31:42 -0000 On 13 Jun 2014, at 15:00, Stephen Farrell wrote= : >=20 > Thanks Sam. Folks - take a peek and we can chat in Toronto > and/or on the list about whether this is worth doing. >=20 > Cheers, > S. >=20 > On 13/06/14 13:44, Samuel Weiler wrote: >> The routing area has one-upped us in terms of public info on their >> directorate. I'm not sure the gain is worth the effort, but I encourage >> you to look at what they've done. Specifically: >>=20 >> Brief bios of directorate members: >> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirExperience >> (in a wiki, self-editted) >>=20 >> AD's own version of id-nits: >> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgADNits >>=20 >> Scheduled reconsideration of directorate membership: >> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirMember what? is there a way out? ;-) >>=20 >> A directorate charter: >> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirCharter >>=20 >> Their own version of guidance to reviewers: >> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirGuidance >>=20 >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Fri Jun 13 18:02:55 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8121B2ACC; Fri, 13 Jun 2014 17:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPhBu5eSoMxL; Fri, 13 Jun 2014 17:51:01 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1390E1B2ACA; Fri, 13 Jun 2014 17:51:00 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id n3so1673622wiv.14 for ; Fri, 13 Jun 2014 17:50:59 -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-type; bh=+3IO2Uvg41zvYvqgeaSa1Ff/J0P/zW6uiE6OGKO96dA=; b=v2O4jWxhlzg/oaPofZrHMcxn86vMRIVJyzZBA3Zb8rRpVZio2ldd3JaGmEUURTCski SMF5eTwH412duswlyfpmtfHb6EWj690dbofuZHZ7oMBz5OV940pV6NsP1TSYxGVjVi0L 6/B+KH6uXgjxANFs+hadeF5RkDDrgEoO2Wzdyjg5VkTqY5wQOHvo/uXAJnN8PtwShSnj 7iKkDaIa04g5OJVEc9efflaR7BepXuQkRsV559derkSqWSSabx8SCGoUdCKmAfkih4j/ nTf8zqp2Qon8zKZyzXSn5l4HrENaYEQVdycbM2XOzWKFYplj0yjCuTILxLcs8r60MJXp oE6A== MIME-Version: 1.0 X-Received: by 10.194.1.164 with SMTP id 4mr8567313wjn.17.1402707059538; Fri, 13 Jun 2014 17:50:59 -0700 (PDT) Sender: ghanwani@gmail.com Received: by 10.216.182.67 with HTTP; Fri, 13 Jun 2014 17:50:59 -0700 (PDT) In-Reply-To: <0D637AC0-FD4F-4865-8D14-ADB75BAB072E@gmail.com> References: <0D637AC0-FD4F-4865-8D14-ADB75BAB072E@gmail.com> Date: Fri, 13 Jun 2014 17:50:59 -0700 X-Google-Sender-Auth: tfHnIjJUE-YnBMQ6867iADTNr2k Message-ID: From: Anoop Ghanwani To: Yoav Nir Content-Type: multipart/alternative; boundary=047d7b3a817602056a04fbc13079 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/gLqHIig9gxq95FIQ_YSSjy1x-nc X-Mailman-Approved-At: Fri, 13 Jun 2014 18:02:53 -0700 Cc: "draft-ietf-opsawg-large-flow-load-balancing.all@tools.ietf.org" , " IESG" , "" Subject: Re: [secdir] Secdir review of draft-ietf-opsawg-large-flow-load-balancing-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 00:51:03 -0000 --047d7b3a817602056a04fbc13079 Content-Type: text/plain; charset=ISO-8859-1 Yoav, Thanks for the review. We have just posted an updated version. On Mon, Apr 28, 2014 at 6:47 AM, Yoav Nir 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. > > tl;dr version: the document is ready. > > I was a little surprised by the way the document is organized, and I'm not > sure who the target audience is. On the one hand it is very verbose on > explanations (that's a good thing!) and I could very well understand it > even though I lack any background on the matter. On the other hand, the > order in which things are explained seems strange: > > The introduction talks about large flows vs small flows, long-lived flows > vs short-lived flows, and Large flows vs Small flows (no, I'm not repeating > myself, capitalize Large is different from lower-case large and in fact > means both "large" and "long-lived"). This is actually explained in the introduction. We only use large flow (no capitalization needed) to mean large, long-lived flow. Everything else is a small flow. > But three things are totally missing: What is a flow? How large does a > flow have to be to be considered "large" (lower case), and how long must a > flow continue to be considered "long-lived". Even the terminology section > (1.2) defines Large, Small and small again, but not what a flow is. These > concepts are finally explained in sections 4.1, 4.3.1, and 4.3.2. > The document describes how load balancing can be achieved by moving large > flows around between links and by removing loaded links from the hash > table, so that Small (or actually un-classified) new flows will not go to > overloaded links. This is an improvement over the assumed default that is > statically assigning flows to links based on a hash. > > The document has a short security considerations section that says that it > does not impact the security of the Internet infrastructure or > applications. I tend to agree, because the parts of the network where these > protocols tends to be mostly stateless, so moving flows from one component > to another should not make a difference. It would be different if there > were supposed to be firewalls on the nodes. > The security considerations also says that load balancing might help in > resisting DoS attacks, for example if an attacker can create traffic where > the hash would collide with some Large flow. With load balancing either the > attacker's flow or the Large flow is moved, eliminating the contention. > Again, I tend to agree, although this will allow a more powerful attacker > to overload all the links, not just the ones they can target with the hash > function. Still, an attacker powerful enough to overload all the links is > likely to be able to create traffic that collides with all links anyway. > We have added to the security section based on comments from the GEN-ART review. > > I don't think there's anything missing from the security considerations. > > Hope this helps > > Yoav > Thanks, Anoop --047d7b3a817602056a04fbc13079 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yoav,

Thanks for the review.  We h= ave just posted an updated version. 

On Mon, Apr 28, 2014 at 6:47 AM, Yoav Nir <ynir.= ietf@gmail.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<= br> these comments just like any other last call comments.

tl;dr version: the document is ready.

I was a little surprised by the way the document is organized, and I’= m not sure who the target audience is. On the one hand it is very verbose o= n explanations (that’s a good thing!) and I could very well understan= d it even though I lack any background on the matter.  On the other ha= nd, the order in which things are explained seems strange:

The introduction talks about large flows vs small flows, long-lived flows v= s short-lived flows, and Large flows vs Small flows (no, I’m not repe= ating myself, capitalize Large is different from lower-case large and in fa= ct means both “large” and “long-lived”).  

This is actually explained in the introduction.  W= e only use large flow (no capitalization needed) to mean large, long-lived = flow.  Everything else is a small flow.
 
But three things are totally missing: What is a flow? How large does a flow= have to be to be considered “large” (lower case), and how long= must a flow continue to be considered “long-lived”. Even the t= erminology section (1.2) defines Large, Small and small again, but not what= a flow is.  These concepts are finally explained in sections 4.1, 4.3= .1, and 4.3.2. 

The document describes how load balancing can be achieved by moving large f= lows around between links and by removing loaded links from the hash table,= so that Small (or actually un-classified) new flows will not go to overloa= ded links. This is an improvement over the assumed default that is statical= ly assigning flows to links based on a hash.

The document has a short security considerations section that says that it = does not impact the security of the Internet infrastructure or applications= . I tend to agree, because the parts of the network where these protocols t= ends to be mostly stateless, so moving flows from one component to another = should not make a difference. It would be different if there were supposed = to be firewalls on the nodes.
The security considerations also says that load balancing might help in res= isting DoS attacks, for example if an attacker can create traffic where the= hash would collide with some Large flow. With load balancing either the at= tacker’s flow or the Large flow is moved, eliminating the contention.= Again, I tend to agree, although this will allow a more powerful attacker = to overload all the links, not just the ones they can target with the hash = function. Still, an attacker powerful enough to overload all the links is l= ikely to be able to create traffic that collides with all links anyway.

We have added to the security section base= d on comments from the GEN-ART review. 

I don’t think there’s anything missing from the security consid= erations.

Hope this helps

Yoav
 
Thanks,
Anoop =
--047d7b3a817602056a04fbc13079-- From nobody Fri Jun 13 18:02:59 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E50F1B2ACA; Fri, 13 Jun 2014 17:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxwUfoTIae15; Fri, 13 Jun 2014 17:57:21 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A113C1A025A; Fri, 13 Jun 2014 17:57:20 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id u56so3328122wes.8 for ; Fri, 13 Jun 2014 17:57:19 -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-type; bh=0IkMu6dHn4H0OkDDFge3yAGxWDsWJ/uqlupF5lrVtXc=; b=Gcpu0NFiz6bLt1NeCF37+LlGs7vWBLzktpDmrwA9dW0OO/R9CsZBgY+SAK4I3m2OdD ENM4EY5JcnSivT6FOyWOP6kQ6GKTsZ5CahmRF0bIm3nAbbZRVyqH+octw9d3cX/OIi7q mB2Mi151+OMo2glT/y2UWbGFkSuvL4LuS+pg+G7X4kszLHOulzwqTsFvA8vuuXDJUPB+ YlTljgZQcCj2EoH3q17dqw+CDRTT+w+MqFt5Q/wcMe1CFqjo2WOkEvu4x3DslpuNRWuV XPFAcFLxoHee3eLQCWIkv+0H4zSOUL8EYeCJDom4dDlSx/9oYSaPWlfMOmOFsI0BGDrC qIVA== MIME-Version: 1.0 X-Received: by 10.180.208.13 with SMTP id ma13mr6018180wic.45.1402707438896; Fri, 13 Jun 2014 17:57:18 -0700 (PDT) Sender: ghanwani@gmail.com Received: by 10.216.182.67 with HTTP; Fri, 13 Jun 2014 17:57:18 -0700 (PDT) In-Reply-To: References: <0D637AC0-FD4F-4865-8D14-ADB75BAB072E@gmail.com> Date: Fri, 13 Jun 2014 17:57:18 -0700 X-Google-Sender-Auth: fYtdVjvRoP9wDhYPkYCMrxXYLpc Message-ID: From: Anoop Ghanwani To: Chris Inacio Content-Type: multipart/alternative; boundary=001a11c38d8a9e947404fbc14693 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/4MXfgRhG3thYlRHcomllwMJnsoE X-Mailman-Approved-At: Fri, 13 Jun 2014 18:02:53 -0700 Cc: "draft-ietf-opsawg-large-flow-load-balancing.all@tools.ietf.org" , " IESG" , "" Subject: Re: [secdir] Secdir review of draft-ietf-opsawg-large-flow-load-balancing-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 00:57:23 -0000 --001a11c38d8a9e947404fbc14693 Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 1, 2014 at 9:25 PM, Chris Inacio wrote: > > > After reading Yoav's review, I was curious about this document. > > I would agree, roughly, with Yoav's comments on flow description. The > table at the beginning of the document (section 2) I feel would be much > better served with its Y axis labeled as bandwidth, and not flow scale. > We have modified the figure to show this as "Bandwidth. > > From a technical point of view, the only issue I have with the document is > that I feel that it misses how long lived flows are identified. I > understand the technical challenge that this presents: how should a middle > box understand/guess the intention of the end points for the duration of a > flow? There are likely to be some heuristics that could be > developed/included that would be likely to have some indication as to the > lifetime. For example, SSH keep alives with an otherwise minimal (smallest > of small) flow, or VPN identification. (Of course with VPN, the flow can > quickly switch from small to large and back to small.) Devices with > enhanced flow inspection can obviously label the traffic via inspection. > > I have 2 possible security considerations: > > Assuming the multi paths might lead to equal but diverse Internet > connections (anycast), does moving flows between paths provide an attacker > who has already penetrated an enterprise, the possibility to further evade > detection of border monitoring devices via flow flopping? Possibly evading > stateful inspection at the border? > This would be unlikely since the the packets still follow the same path that other regular packets follow. It is just pinned to a specific path rather than being allow to use whatever the hash algorithm dictates. > > And less likely: From a security point of view, sophisticated attackers, > persistent attackers, like to map their target environment (hosts and > network) before attempting their actual attack (DoS, exfiltration, > destruction, etc.). Does the movement of flows across otherwise redundant > links expose more network structure, especially with respect to traceroute > for an attacker. > The traceroute itself probably wouldn't be a large flow so that by itself shouldn't be affected by this scheme. We have augmented the security section based on comments from the GEN-ART review. Anoop --001a11c38d8a9e947404fbc14693 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, May 1, 2014 at 9:25 PM, Chris Inacio <= inacio@cert.org>= ; wrote:


After reading Yoav’s review, I was curious about this doc= ument.

I would agree, roughly, with Yoav’s comments on flow description. &nb= sp;The table at the beginning of the document (section 2) I feel would be m= uch better served with its Y axis labeled as bandwidth, and not flow scale.=

We have modified the figure to show this as "Bandw= idth. 

>From a technical point of view, the only issue I have with the document is = that I feel that it misses how long lived flows are identified.  I und= erstand the technical challenge that this presents: how should a middle box= understand/guess the intention of the end points for the duration of a flo= w?  There are likely to be some heuristics that could be developed/inc= luded that would be likely to have some indication as to the lifetime. &nbs= p;For example, SSH keep alives with an otherwise minimal (smallest of small= ) flow, or VPN identification.  (Of course with VPN, the flow can quic= kly switch from small to large and back to small.)  Devices with enhan= ced flow inspection can obviously label the traffic via inspection.

I have 2 possible security considerations:

Assuming the multi paths might lead to equal but diverse Internet connectio= ns (anycast), does moving flows between paths provide an attacker who has a= lready penetrated an enterprise, the possibility to further evade detection= of border monitoring devices via flow flopping?  Possibly evading sta= teful inspection at the border?

This would be unlikely since the the packe= ts still follow the same path that other regular packets follow.  It i= s just pinned to a specific path rather than being allow to use whatever th= e hash algorithm dictates.
 

And less likely: From a security point of view, sophisticated attackers, pe= rsistent attackers, like to map their target environment (hosts and network= ) before attempting their actual attack (DoS, exfiltration, destruction, et= c.).  Does the movement of flows across otherwise redundant links expo= se more network structure, especially with respect to traceroute for an att= acker.

The traceroute itself probably wouldn'= t be a large flow so that by itself shouldn't be affected by this schem= e.

We have augmented the security section based on= comments from the GEN-ART review.

Anoop

 
=
--001a11c38d8a9e947404fbc14693-- From nobody Thu Jun 19 04:42:13 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 680A91A01E6 for ; Thu, 19 Jun 2014 04:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.772 X-Spam-Level: X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYbRMKbcyXCf for ; Thu, 19 Jun 2014 04:42:07 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 8B1DF1A018E for ; Thu, 19 Jun 2014 04:42:07 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s5JBg5CO011846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 19 Jun 2014 14:42:05 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s5JBg5U0014466; Thu, 19 Jun 2014 14:42:05 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21410.52365.495616.648226@fireball.kivinen.iki.fi> Date: Thu, 19 Jun 2014 14:42:05 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/HYb8gVybmyQ4usJG0bLggTQ-FGY Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 11:42:10 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Catherine Meadows is next in the rotation. For telechat 2014-06-26 Reviewer LC end Draft Shaun Cooley T 2014-06-12 draft-ietf-appsawg-sieve-duplicate-07 Alan DeKok T 2014-06-11 draft-ietf-hip-rfc4843-bis-05 Donald Eastlake T 2014-06-11 draft-ietf-hip-rfc5201-bis-14 Shawn Emery T 2014-06-11 draft-ietf-hip-rfc5202-bis-05 Simon Josefsson T 2014-06-25 draft-ietf-tram-stun-dtls-03 For telechat 2014-07-10 David Harrington T 2014-07-01 draft-ietf-ppsp-peer-protocol-10 Ben Laurie T 2014-07-01 draft-ietf-pce-questions-06 Last calls and special requests: Dan Harkins 2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-14 Sam Hartman 2014-06-23 draft-ietf-dnsop-child-syncronization-01 Paul Hoffman 2014-06-20 draft-ietf-tls-encrypt-then-mac-02 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-06 Jeffrey Hutzelman 2014-06-20 draft-ietf-mmusic-rtsp-nat-21 Chris Inacio 2014-06-23 draft-ietf-mpls-smp-requirements-06 Leif Johansson 2014-06-24 draft-ietf-netext-wifi-epc-eap-attributes-08 Charlie Kaufman 2014-07-02 draft-ietf-6man-multicast-addr-arch-update-05 Scott Kelly 2014-06-30 draft-ietf-eman-battery-mib-12 Stephen Kent 2014-06-30 draft-ietf-eman-energy-aware-mib-15 Tero Kivinen 2014-06-30 draft-ietf-eman-energy-monitoring-mib-10 Warren Kumari 2014-07-02 draft-ietf-netext-pmip-cp-up-separation-04 Julien Laganier E 2013-11-21 draft-ietf-websec-key-pinning-15 Julien Laganier 2014-04-29 draft-ietf-dhc-dhcpv4-over-dhcpv6-09 Julien Laganier 2014-06-30 draft-ietf-ppsp-survey-08 Matt Lepinski 2014-06-30 draft-ietf-tcpm-tcp-rfc4614bis-05 Chris Lonvick 2014-07-10 draft-secretaries-good-practices-06 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Ondrej Sury 2014-05-28 draft-ietf-ipfix-text-adt-05 David Waltermire 2014-06-10 draft-salgueiro-dispatch-websocket-sipclf-01 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-11 -- kivinen@iki.fi From nobody Thu Jun 19 05:11:04 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512541A038A; Thu, 19 Jun 2014 05:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tn0pmu7t1hQv; Thu, 19 Jun 2014 05:10:56 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 F3CB71A0389; Thu, 19 Jun 2014 05:10:55 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id s5JCAptv012350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 19 Jun 2014 14:10:53 +0200 Date: Thu, 19 Jun 2014 14:10:51 +0200 From: Simon Josefsson To: iesg@ietf.org, secdir@ietf.org, draft-ietf-tram-stun-dtls.all@tools.ietf.org Message-ID: <20140619141051.74e420f9@latte.josefsson.org> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.98.1 at duva.sjd.se X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/_SOXnqGTW8cG6Ngeug1M3bGO2wY Subject: [secdir] Review of draft-ietf-tram-stun-dtls-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 12:11:00 -0000 Hello, I have reviewed this document, and believe it is ready with nits. MAJOR: * The document is silent on whether DTLS cookies is required or not for STUN. DTLS cookies is one of few security differences between TLS and DTLS. The DTLS document says servers SHOULD use cookies, but as not requiring this can lead to amplification attacks, I suggest adding a MUST here. For example, add the following to the end of section 3: Servers implementing this document MUST send DTLS cookies to protect against some Denial of Service attacks. Of course, I'm not to decide this, and I'm certainly no STUN expert, so the authors and/or WG should think about whether mandating DTLS cookies makes sense for STUN. Note that section 4.6 require DTLS cookies for TURN. Is this difference intentional? Or did I overlook where this draft requires it for STUN too? * There is a bit of terminology mixup, and I think the origin of the mixup is section 1 referring to "TLS-over-UDP" as "DTLS". That is unfortunate for two reasons: 1) DTLS is not bound to UDP; DTLS can be used over TCP or other transports, and 2) DTLS is similar but not identical to TLS. DTLS is not the same as TLS run over UDP. Quoting section 1: TLS-over-UDP (referred to as DTLS [RFC6347]) offers the same security advantages as TLS-over-TCP, but without the undesirable latency concerns. I suggest to rewrite the paragraph into: STUN transported over DTLS [RFC6347] over UDP offers the same security advantages as TLS-over-TCP, but without the undesirable latency concerns. Further, in section 3 clarify that the STUN transport "DTLS" is DTLS over UDP which isn't otherwise explicit: OLD: STUN [RFC5389] defines three transports: UDP, TCP, and TLS. This document adds DTLS as a valid transport for STUN. NEW: STUN [RFC5389] defines three transports: UDP, TCP, and TLS. This document adds DTLS (over UDP) as a valid transport for STUN. * Cipher suites. Quoting the document: Instead of TLS_RSA_WITH_AES_128_CBC_SHA, which is the default cipher suite for STUN over TLS, STUN over DTLS, at a minimum, MUST support TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. STUN over DTLS MUST prefer TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and any other Perfect Forward Secrecy (PFS) cipher suites over non-PFS cipher suites. I think this is good text, but still, some concerns: 1) The word "support" is not precise. Does it mean 1) that implementers MUST implement it (but not necessarily enable them), or that 2) all deployed clients MUST offer at least these two ciphersuites, and that all servers MUST accept at least these two ciphersuites if the client doesn't offer anything else? I assume the latter was the intent, but it can be read as the former. 2) I don't think "PFS cipher suites" is well-defined in this context, as PFS is only briefly discussed in the TLS spec. There is a bunch of DHE key exchange algorithms defined for TLS, are all of them relevant? Probably not the anonymous ones? 3) The requirement to prefer some cipher suites is generally for both client and server, but in DTLS they behave differently. Clients list a set of acceptable ciphersuites, and the server picks one. Is it permitted for clients to list non-PFS ciphersuites at all? 4) The text can lead to poor decisions for broken ciphers. There are PFS ciphersuites out there based on broken ciphers, and there are non-PFS ciphersuites that are not known to be broken. For example, TLS_DHE_DSS_WITH_DES_CBC_SHA is PFS but DES is clearly broken. I don't think you want a server to prefer TLS_DHE_DSS_WITH_DES_CBC_SHA over, say, TLS_DH_RSA_WITH_AES_256_CBC_SHA256, right? 5) Since you are explicit about ciphersuites, and appear to worry about ciphersuite selection, consider forbidding DES and RC4 directly since they are known weak cipher. This would resolve the last concern too, I think. A straw-man: Implementations of STUN over DTLS, and deployed clients and servers, MUST support TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, MAY support other ciphersuites, and SHOULD NOT support any insecure ciphersuites. Perfect Forward Secrecy (PFS) cipher suites MUST be preferred over non-PFS cipher suites. Cipher suites with known weaknesses, such as those based on (single) DES and RC4, MUST NOT be used. MINOR: * TCP ports != UDP ports. Typo fix: OLD: By default, STUN over DTLS MUST use port 5349, the same port as STUN .. By default, TURN over DTLS uses port 5349, the same port as TURN over NEW: By default, STUN over DTLS MUST use port 5349, the same port number as STUN .. By default, TURN over DTLS uses port 5349, the same port number as TURN over * SRV terminology mixup. OLD: SRV records, the service name MUST be set to "turns" and the application name to "udp". ... SRV records, the service name MUST be set to "stuns" and the application name to "udp". NEW: SRV records, the service name MUST be set to "turns" and the protocol name to "udp". ... SRV records, the service name MUST be set to "stuns" and the protocol name to "udp". /Simon From nobody Thu Jun 19 05:36:39 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE2A21A039A for ; Thu, 19 Jun 2014 05:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkqPOQtWnyTJ for ; Thu, 19 Jun 2014 05:36:27 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C32EB1A0393 for ; Thu, 19 Jun 2014 05:36:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 39684BEE6 for ; Thu, 19 Jun 2014 13:36:27 +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 mbs9WnKDobiJ for ; Thu, 19 Jun 2014 13:36:27 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0ABBABEE4 for ; Thu, 19 Jun 2014 13:36:27 +0100 (IST) Message-ID: <53A2D94B.6080503@cs.tcd.ie> Date: Thu, 19 Jun 2014 13:36:27 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "secdir@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/vO1GY8YksahGa9NWHKY0evmd8ZU Subject: [secdir] Tuesday lunch in Toronto conflict X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 12:36:34 -0000 Hiya, ISOC are organising one of their lunch time sessions in Toronto on the topic of "Internet Security and Privacy: Ten years later" That conflicts with out usual get together which is a pity. We could try find another slot or just live with the conflict. (These ISOC things tend to be fairly high level informational panels rather than nitty-gritty lets-do-stuff meetings so I'm told.) Kathleen and I would like to see what folks prefer. If enough of us want to move we'll try (and possibly fail) to find another slot. I've created a doodle poll. Please answer: yes - if want to attend both and we should try move the secdir lunch if-need-be - if you're going to attend the ISOC thing and not secdir if there is a conflict no - if you think we should live with the conflict and you will attend secdir regardless The poll is at [1]. Please fill it in before the end of next Monday. If you've comments on the poll, enter them there please - if we need more mail on this we can do that next week. If you're doing something else during that slot, then why did you read this far? :-) Thanks, S. [1] http://doodle.com/ktv2q3yr6s4e2am5 From nobody Thu Jun 19 06:48:46 2014 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6621A03A8; Thu, 19 Jun 2014 06:46:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1403185581; bh=2BjK7kqrH5UwqE4lP9jj78cyTLlSnqDGsT914JMtwnA=; h=From:To:Date:Message-ID:MIME-Version:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Sender; b=rbih6kKK19aCziWbRztbRLTQFSr7jHhpf8B68B7wVSnxG4LVRet1VgfU5Tz3lQeZB ddwldF5JpCRb4G30MrCX2QrI5THQkF8aMQZqVjapwcIEA07ThRqPiBpTJKGxXu/cA9 KEcJhLABQZh4Dti/cKcioo6mETHwM9MJNnSKbiwQ= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 058961A03A3 for ; Thu, 19 Jun 2014 06:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToO2wWfVdVAJ for ; Thu, 19 Jun 2014 06:46:12 -0700 (PDT) Received: from ausc60ps301.us.dell.com (ausc60ps301.us.dell.com [143.166.148.206]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76BBC1A0365 for ; Thu, 19 Jun 2014 06:46:12 -0700 (PDT) X-LoopCount0: from 10.175.216.251 X-IronPort-AV: E=Sophos;i="5.01,507,1400043600"; d="scan'208,217";a="536461588" From: To: Date: Thu, 19 Jun 2014 08:46:09 -0500 Thread-Topic: IEEE 802 New Work Under Consideration @ July 2014 Plenary Thread-Index: Ac+LxNOChs6hi4C6R/O9RqQwCyr/qg== Message-ID: <28616F4740DDF542AA1DB7C9F597963907B1993A86@AUSX7MCPS301.AMER.DELL.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/new-work/85KJJQSlnAb5I6hJ0vSv_9fWCio X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Content-Type: multipart/mixed; boundary="===============5137073904944145410==" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/dj03f6uNrorAzElwiKS2Rf8q520 X-Mailman-Approved-At: Thu, 19 Jun 2014 06:48:43 -0700 Cc: paul.nikolich@att.net Subject: [secdir] [new-work] IEEE 802 New Work Under Consideration @ July 2014 Plenary 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, 19 Jun 2014 13:46:22 -0000 --===============5137073904944145410== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_28616F4740DDF542AA1DB7C9F597963907B1993A86AUSX7MCPS301A_" --_000_28616F4740DDF542AA1DB7C9F597963907B1993A86AUSX7MCPS301A_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, The following Project Authorization Requests (PARs) will be considered at t= he July 2014 IEEE 802 Plenary: * 802.1ARce - Secure Device Identity, Amendment 1: Amendment 1: SHA-384 = and P-384 Elliptic Curve, PAR and CSD * 802.1AEcg - Media Access Control (MAC) Security - Amendment: Ethernet = Data Encryption devices, PAR and CSD * 802.3bv- amendment, 1000 Mb/s Operation Over Plastic Optical Fiber , P= AR and CSD * 802.3bw - amendment, 1 Twisted Pair 100 Mb/s Ethernet , PAR and CSD * 802.11ah, Sub 1 GHz, PAR extension request, PAR and CSD * 802.11ai, Fast initial link setup, PAR extension request , PAR = and CSD * 802.15.4, amendment enabling Spectrum Resource Measurement Capability,= PAR and CSD * 802.22.3, Specifying Spectrum Occupancy Sensing (SOS) Measurement Devi= ces and Means that Enable Coalescing the Results from Multiple Such Devices= , PAR and CSD The PARs can be found at http://www.ieee802.org/PARs.shtml#PAR_1407 along w= ith the supporting IEEE 802 Criteria for Standards Development, or CSD, (wh= ich includes the 5 criteria, i.e. the explanations of how they fit the IEEE= 802 criteria for initiating new work). Any comments on a proposed PAR should be sent to the Working Group chair id= entified on the PAR to be received by 5:00 PM (PDT), Tuesday, Jul 15, 2014 = (1:00am UTC Jul 16, 2014). Regards, John D'Ambrosia Recording Secretary, IEEE 802 LMSC --_000_28616F4740DDF542AA1DB7C9F597963907B1993A86AUSX7MCPS301A_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

The following Project Authorization Requests (PARs) will be cons= idered at the July 2014 IEEE 802 Plenary:

    802.1ARce - Secure Device Identity, Amendment = 1: Amendment 1: SHA-384 and P-384 Elliptic Curve, PAR and CSD
  • 802.3bv- amendment, 1000 Mb= /s Operation Over Plastic Optical Fiber , PAR and CSD
  • 802.3bw - amendment, 1 Twisted Pair 100 Mb/s Ethern= et ,  PAR and CSD
  • 802.11ah, Sub 1 GHz, PAR extension request, PAR and CSD
  • 802.11ai, Fast initial link setup,= PAR extension request , PAR and CSD
  • 802.15.4, ame= ndment enabling Spectrum Resource Measurement Capability, PAR and CSD
  • 802.22.3, Specifying Spectrum Occupancy Sensing (SOS= ) Measurement Devices and Means that Enable Coalescing the Results from Mul= tiple Such Devices, PAR and CSD <= /o:p>

The PARs= can be found at htt= p://www.ieee802.org/PARs.shtml#PAR_1407 along with the supporting IEEE = 802 Criteria for Standards Development, or CSD, (which includes the 5 crite= ria, i.e. the explanations of how they fit the IEEE 802 criteria for initia= ting new work).

Any comments on a proposed PAR should be sent to the Working Group c= hair identified on the PAR to be received by 5:00 PM (PDT), Tuesday, Jul 15= , 2014 (1:00am UTC Jul 16, 2014).

Regards,

John = D’Ambrosia

Recording Secretary, IE= EE 802 LMSC

 

= = --_000_28616F4740DDF542AA1DB7C9F597963907B1993A86AUSX7MCPS301A_-- --===============5137073904944145410== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work --===============5137073904944145410==-- From nobody Thu Jun 19 14:17:55 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF961A041F for ; Thu, 19 Jun 2014 14:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwcbJS2IPnpg for ; Thu, 19 Jun 2014 14:17:50 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4F7D1A0316 for ; Thu, 19 Jun 2014 14:17:50 -0700 (PDT) Received: from [172.20.2.23] (63-146-242-187.dia.static.qwest.net [63.146.242.187]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s5JLHlsX087770 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 19 Jun 2014 14:17:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 63-146-242-187.dia.static.qwest.net [63.146.242.187] claimed to be [172.20.2.23] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <36309B69-3BE4-437C-B5D8-25EDC690838A@vpnc.org> Date: Thu, 19 Jun 2014 17:17:46 -0400 To: secdir Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Y-Kta4r1PvkmiYX9-AJ3CqZH76U Subject: [secdir] SecDir review of draft-ietf-tls-encrypt-then-mac X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 21:17:51 -0000 Greetings. This document seems like a probably-good extension for TLS. = The security considerations are short and to the point, and I could not = think of any other significant security considerations to add. --Paul Hoffman= From nobody Fri Jun 20 07:08:42 2014 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 63AD21B27D5; Fri, 20 Jun 2014 07:07:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1403273242; bh=kBAaq2X5B85IpOW9GecWdPbsRa01aZUfx+EIQlyOb3Q=; h=To:Date:MIME-Version:From:Message-ID:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=LGmC71iHFlR1Gv3Szs7WhhanieRaPCR6QcXMgk4TmKLQR+X+LGvSJvGBGAI3pa8uX FCRfcGa71Ggkc9N80nEJJcbMMaArJnHbsLWcz9hGH49pVzOooDOJUY2PmpJCZQ4d4c I5hKhy6QdjS3f1ixcJhcj7bFlgk1RZ2hoNkWu4T0= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED361B27B7 for ; Fri, 20 Jun 2014 07:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.853 X-Spam-Level: X-Spam-Status: No, score=-4.853 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPAcjGxydYRV for ; Fri, 20 Jun 2014 07:07:14 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AEB81B27EA for ; Fri, 20 Jun 2014 07:06:23 -0700 (PDT) Received: from eb.bleuazur.com ([88.173.33.195] helo=sith.local) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1WxzSQ-0004Fd-Bb; Fri, 20 Jun 2014 10:06:22 -0400 To: "new-work@ietf.org" Date: Fri, 20 Jun 2014 16:06:21 +0200 MIME-Version: 1.0 From: "Coralie Mercier" Organization: W3C Message-ID: User-Agent: Opera Mail/1.0 (MacIntel) Archived-At: http://mailarchive.ietf.org/arch/msg/new-work/aYmDis503t78piZp1d34UKUyfdk X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/lWVGsn8dXzX04I9dJs1-z5qGxSo X-Mailman-Approved-At: Fri, 20 Jun 2014 07:08:39 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Web Applications Working Group (until 2014-07-18) 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, 20 Jun 2014 14:07:22 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Rich Web Client Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the Web Applications Working Group: http://www.w3.org/2014/06/webapps-charter.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2014-07-18 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [2], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Yves Lafon and Xiaoqian Wu , Staff Contacts. Thank you, Coralie Mercier, W3C Communications [0] http://www.w3.org/2006/rwc/ [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Coralie Mercier - W3C Communications Team - http://www.w3.org mailto:coralie@w3.org +336 4322 0001 http://www.w3.org/People/CMercier/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Fri Jun 20 07:29:58 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729901A03B7; Fri, 20 Jun 2014 07:15:52 -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, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pR3fplo9GNBq; Fri, 20 Jun 2014 07:15:48 -0700 (PDT) Received: from nomis80.org (nomis80.org [23.92.21.33]) by ietfa.amsl.com (Postfix) with ESMTP id 59DCF1A03C1; Fri, 20 Jun 2014 07:15:48 -0700 (PDT) Received: from porto.nomis80.org (unknown [199.87.121.1]) by nomis80.org (Postfix) with ESMTPSA id 1B3AC10EAE; Fri, 20 Jun 2014 14:18:29 +0000 (UTC) Message-ID: <53A44212.9020600@per.reau.lt> Date: Fri, 20 Jun 2014 08:15:46 -0600 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Simon Josefsson , iesg@ietf.org, secdir@ietf.org, draft-ietf-tram-stun-dtls.all@tools.ietf.org References: <20140619141051.74e420f9@latte.josefsson.org> In-Reply-To: <20140619141051.74e420f9@latte.josefsson.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/t_LnEhQQ56cy498Mq0npxoW8Jfc X-Mailman-Approved-At: Fri, 20 Jun 2014 07:29:57 -0700 Subject: Re: [secdir] Review of draft-ietf-tram-stun-dtls-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 14:15:52 -0000 Thanks a lot for your review! The authors will reply and publish a new revision shortly. Simon Le 2014-06-19 06:10, Simon Josefsson a écrit : > Hello, > > I have reviewed this document, and believe it is ready with nits. > > MAJOR: > > * The document is silent on whether DTLS cookies is required or not > for STUN. DTLS cookies is one of few security differences between > TLS and DTLS. The DTLS document says servers SHOULD use cookies, > but as not requiring this can lead to amplification attacks, I > suggest adding a MUST here. For example, add the following to the > end of section 3: > > Servers implementing this document MUST send DTLS cookies to protect > against some Denial of Service attacks. > > Of course, I'm not to decide this, and I'm certainly no STUN expert, > so the authors and/or WG should think about whether mandating DTLS > cookies makes sense for STUN. > > Note that section 4.6 require DTLS cookies for TURN. Is this > difference intentional? Or did I overlook where this draft requires > it for STUN too? > > * There is a bit of terminology mixup, and I think the origin of the > mixup is section 1 referring to "TLS-over-UDP" as "DTLS". That is > unfortunate for two reasons: 1) DTLS is not bound to UDP; DTLS can > be used over TCP or other transports, and 2) DTLS is similar but not > identical to TLS. DTLS is not the same as TLS run over UDP. > Quoting section 1: > > TLS-over-UDP (referred to as DTLS [RFC6347]) offers the same security > advantages as TLS-over-TCP, but without the undesirable latency > concerns. > > I suggest to rewrite the paragraph into: > > STUN transported over DTLS [RFC6347] over UDP offers the same > security advantages as TLS-over-TCP, but without the undesirable > latency concerns. > > Further, in section 3 clarify that the STUN transport "DTLS" is DTLS > over UDP which isn't otherwise explicit: > > OLD: > STUN [RFC5389] defines three transports: UDP, TCP, and TLS. This > document adds DTLS as a valid transport for STUN. > NEW: > STUN [RFC5389] defines three transports: UDP, TCP, and TLS. This > document adds DTLS (over UDP) as a valid transport for STUN. > > * Cipher suites. Quoting the document: > > Instead of TLS_RSA_WITH_AES_128_CBC_SHA, which is the default cipher > suite for STUN over TLS, STUN over DTLS, at a minimum, MUST support > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and MUST support > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. STUN over DTLS MUST prefer > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and any other Perfect Forward > Secrecy (PFS) cipher suites over non-PFS cipher suites. > > I think this is good text, but still, some concerns: > > 1) The word "support" is not precise. Does it mean 1) that > implementers MUST implement it (but not necessarily enable > them), or that 2) all deployed clients MUST offer at least these > two ciphersuites, and that all servers MUST accept at least > these two ciphersuites if the client doesn't offer anything > else? I assume the latter was the intent, but it can be read as > the former. > > 2) I don't think "PFS cipher suites" is well-defined in this > context, as PFS is only briefly discussed in the TLS spec. > There is a bunch of DHE key exchange algorithms defined for TLS, > are all of them relevant? Probably not the anonymous ones? > > 3) The requirement to prefer some cipher suites is generally for both > client and server, but in DTLS they behave differently. Clients > list a set of acceptable ciphersuites, and the server picks one. > Is it permitted for clients to list non-PFS ciphersuites at all? > > 4) The text can lead to poor decisions for broken ciphers. There > are PFS ciphersuites out there based on broken ciphers, and > there are non-PFS ciphersuites that are not known to be broken. > For example, TLS_DHE_DSS_WITH_DES_CBC_SHA is PFS but DES is > clearly broken. I don't think you want a server to prefer > TLS_DHE_DSS_WITH_DES_CBC_SHA over, say, > TLS_DH_RSA_WITH_AES_256_CBC_SHA256, right? > > 5) Since you are explicit about ciphersuites, and appear to worry > about ciphersuite selection, consider forbidding DES and RC4 > directly since they are known weak cipher. This would resolve > the last concern too, I think. > > A straw-man: > > Implementations of STUN over DTLS, and deployed clients and > servers, MUST support TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, MAY support other > ciphersuites, and SHOULD NOT support any insecure ciphersuites. > Perfect Forward Secrecy (PFS) cipher suites MUST be preferred over > non-PFS cipher suites. Cipher suites with known weaknesses, such > as those based on (single) DES and RC4, MUST NOT be used. > > MINOR: > > * TCP ports != UDP ports. Typo fix: > > OLD: > By default, STUN over DTLS MUST use port 5349, the same port as STUN > .. > By default, TURN over DTLS uses port 5349, the same port as TURN over > NEW: > By default, STUN over DTLS MUST use port 5349, the same port number > as STUN .. > By default, TURN over DTLS uses port 5349, the same port number as > TURN over > > * SRV terminology mixup. > > OLD: > SRV records, the service name MUST be set to "turns" and the > application name to "udp". > ... > SRV records, the service name MUST be set to "stuns" and the > application name to "udp". > NEW: > SRV records, the service name MUST be set to "turns" and the > protocol name to "udp". > ... > SRV records, the service name MUST be set to "stuns" and the > protocol name to "udp". > > /Simon > From nobody Fri Jun 20 07:35:15 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 128A91B2806 for ; Fri, 20 Jun 2014 07:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBjkx8O7mc_T for ; Fri, 20 Jun 2014 07:34:45 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 707D81B27E8 for ; Fri, 20 Jun 2014 07:34:45 -0700 (PDT) Received: by mail-ig0-f177.google.com with SMTP id c1so576002igq.16 for ; Fri, 20 Jun 2014 07:34:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getjive.com; s=mail; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=RW1YjJXUNdjnLz194N3YwgrlpCQYbo4ocgSroohtfhk=; b=lKIGpF+FcPsxnrDqeFQ0DdLeAg9KMq6NhvB9cyhnc89gH0Gv7dvJ7nhPUXVXwUcjSa EwEE0VqO/WU/NEwIXLlt3yPWLKMjEZ4eUdqmYt3kqpNk29pHSHKXFNXF42qvUAlxji49 3eg3dhfpkmqd79cU83ZqCPBgcHuxKHhPAjBtc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=RW1YjJXUNdjnLz194N3YwgrlpCQYbo4ocgSroohtfhk=; b=UvhIbKgsL1YR9o+m8sn7EzLuhUWLEhfSZojyDa8NRP+S/uswLLuubeqHCHxq0q12SG KTEPqwAC5xUW4yqmgW8iu9MdoFLOV6EoreII9AH6kYpYamRDJngbPEfTDcudSkhPwxkX Ie+aKs6vfTWCbyOR9mXW6GUPVPvQGEyiR9l2fs3RnVgZg/S0pgO2OkRjs7SOfvdeAa6E r+oZS8BRZjkqvvySzdXnGxjuLK15P2i9gENkJtmyVO80epRt4FP7ET9GC5n7sEY1X1fE zno0xHXjovs6yn+wINKS8Q6FJiTY8lZ1E4RmYMXaWVzrYuaY+H1YphyNFQ+BopgtJY6+ h2VA== X-Gm-Message-State: ALoCoQnTyCOkXvmC2eGa0vG6WLP5iiRL0keqLGFb3sHFUQaEDteweNequp7b7cOO0X0BDT3ewkd3 X-Received: by 10.50.129.104 with SMTP id nv8mr4992056igb.45.1403274884666; Fri, 20 Jun 2014 07:34:44 -0700 (PDT) Received: from jivecommunications.com ([199.87.120.126]) by mx.google.com with ESMTPSA id qo12sm4829930igb.21.2014.06.20.07.34.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Jun 2014 07:34:44 -0700 (PDT) Message-ID: <53A4467D.2020905@getjive.com> Date: Fri, 20 Jun 2014 08:34:37 -0600 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Simon Josefsson , iesg@ietf.org, secdir@ietf.org, draft-ietf-tram-stun-dtls.all@tools.ietf.org References: <20140619141051.74e420f9@latte.josefsson.org> In-Reply-To: <20140619141051.74e420f9@latte.josefsson.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="85bP0XhHL079Q95Vc0rrTKtOENhqt8Adh" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/MFSiT7OVtk-L4bQURGm8ze0wpuk X-Mailman-Approved-At: Fri, 20 Jun 2014 07:35:13 -0700 Subject: Re: [secdir] Review of draft-ietf-tram-stun-dtls-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 14:34:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --85bP0XhHL079Q95Vc0rrTKtOENhqt8Adh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Simon, Thanks for the review. Please see my responses inline. On 6/19/14, 6:10 AM, Simon Josefsson wrote: > Hello, >=20 > I have reviewed this document, and believe it is ready with nits. >=20 > MAJOR: >=20 > * The document is silent on whether DTLS cookies is required or not > for STUN. DTLS cookies is one of few security differences between > TLS and DTLS. The DTLS document says servers SHOULD use cookies, > but as not requiring this can lead to amplification attacks, I > suggest adding a MUST here. For example, add the following to the > end of section 3: >=20 > Servers implementing this document MUST send DTLS cookies to protec= t > against some Denial of Service attacks. >=20 > Of course, I'm not to decide this, and I'm certainly no STUN expert, > so the authors and/or WG should think about whether mandating DTLS > cookies makes sense for STUN. >=20 > Note that section 4.6 require DTLS cookies for TURN. Is this > difference intentional? Or did I overlook where this draft requires > it for STUN too? Yes, you are right, but I do not think that adding this for all the STUN Usages is right, it should be added on a usage by usage basis. The Nat Discovery Usage (section 4.1) and NAT Behavior Discovery Usage (section 4.5) MUST definitively use the cookie in the same way the TURN Usage is using it. As for the other Usages (Connectivity Check - 4.2, Media Keep-Alive - 4.3 and SIP Keep-Alive - 4.4), I do not think that the cookie is useful, based on slide 3 of the following presentation by Martin Thomson: http://www.ietf.org/proceedings/interim/2012/06/12/rtcweb/slides/slides-i= nterim-2012-rtcweb-2-7.pptx This said, I'd like some guidance there. So I will add the same text that is in section 4.6 to sections 4.1 and 4.5. I will also add to section 4 some text saying that new STUN Usages should discuss if it is appropriate to use the cookie or not. >=20 > * There is a bit of terminology mixup, and I think the origin of the > mixup is section 1 referring to "TLS-over-UDP" as "DTLS". That is > unfortunate for two reasons: 1) DTLS is not bound to UDP; DTLS can > be used over TCP or other transports, Well, the same can be said for TLS-over-TCP, e.g. RFC 3436 predates RFC 5389, but RFC 5389 still uses the TLS-over-TCP terminology. I think what RFC 5389 meant is "in this spec, TLS means TLS-over-TCP", and in the same way in -stun-dtls we mean "in this spec DTLS means DTLS-over-UDP". > and 2) DTLS is similar but not > identical to TLS. DTLS is not the same as TLS run over UDP. I agree. > Quoting section 1: >=20 > TLS-over-UDP (referred to as DTLS [RFC6347]) offers the same securit= y > advantages as TLS-over-TCP, but without the undesirable latency > concerns. >=20 > I suggest to rewrite the paragraph into: >=20 > STUN transported over DTLS [RFC6347] over UDP offers the same > security advantages as TLS-over-TCP, but without the undesirable > latency concerns. I would prefer the following, as it establishes DTLS as an alias for DTLS-over-UDP for the remaining of the spec: "DTLS-over-UDP (referred to as DTLS [RFC6347]) offers the same security advantages as TLS-over-TCP, but without the undesirable latency concerns." >=20 > Further, in section 3 clarify that the STUN transport "DTLS" is DTLS > over UDP which isn't otherwise explicit: >=20 > OLD: > STUN [RFC5389] defines three transports: UDP, TCP, and TLS. This > document adds DTLS as a valid transport for STUN. > NEW: > STUN [RFC5389] defines three transports: UDP, TCP, and TLS. This > document adds DTLS (over UDP) as a valid transport for STUN. With the text I propose above, we do not need this modification. >=20 > * Cipher suites. Quoting the document: >=20 > Instead of TLS_RSA_WITH_AES_128_CBC_SHA, which is the default cipher= > suite for STUN over TLS, STUN over DTLS, at a minimum, MUST support > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and MUST support > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. STUN over DTLS MUST prefer > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and any other Perfect Forward > Secrecy (PFS) cipher suites over non-PFS cipher suites. >=20 > I think this is good text, but still, some concerns: >=20 > 1) The word "support" is not precise. Does it mean 1) that > implementers MUST implement it (but not necessarily enable > them), or that 2) all deployed clients MUST offer at least these > two ciphersuites, and that all servers MUST accept at least > these two ciphersuites if the client doesn't offer anything > else? I assume the latter was the intent, but it can be read as > the former. >=20 > 2) I don't think "PFS cipher suites" is well-defined in this > context, as PFS is only briefly discussed in the TLS spec. > There is a bunch of DHE key exchange algorithms defined for TLS, > are all of them relevant? Probably not the anonymous ones? >=20 > 3) The requirement to prefer some cipher suites is generally for bot= h > client and server, but in DTLS they behave differently. Clients > list a set of acceptable ciphersuites, and the server picks one. > Is it permitted for clients to list non-PFS ciphersuites at all? >=20 > 4) The text can lead to poor decisions for broken ciphers. , There > are PFS ciphersuites out there based on broken ciphers, and > there are non-PFS ciphersuites that are not known to be broken. > For example, TLS_DHE_DSS_WITH_DES_CBC_SHA is PFS but DES is > clearly broken. I don't think you want a server to prefer > TLS_DHE_DSS_WITH_DES_CBC_SHA over, say, > TLS_DH_RSA_WITH_AES_256_CBC_SHA256, right? >=20 > 5) Since you are explicit about ciphersuites, and appear to worry > about ciphersuite selection, consider forbidding DES and RC4 > directly since they are known weak cipher. This would resolve > the last concern too, I think. >=20 > A straw-man: >=20 > Implementations of STUN over DTLS, and deployed clients and > servers, MUST support TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, MAY support other > ciphersuites, and SHOULD NOT support any insecure ciphersuites. > Perfect Forward Secrecy (PFS) cipher suites MUST be preferred over > non-PFS cipher suites. Cipher suites with known weaknesses, such > as those based on (single) DES and RC4, MUST NOT be used. OK. I just prepended your first sentence with "Instead of TLS_RSA_WITH_AES_128_CBC_SHA, which is the default cipher suite for STUN over TLS, " >=20 > MINOR: >=20 > * TCP ports !=3D UDP ports. Typo fix: >=20 > OLD: > By default, STUN over DTLS MUST use port 5349, the same port as STUN= > .. > By default, TURN over DTLS uses port 5349, the same port as TURN ove= r > NEW: > By default, STUN over DTLS MUST use port 5349, the same port number > as STUN .. > By default, TURN over DTLS uses port 5349, the same port number as > TURN over OK >=20 > * SRV terminology mixup. >=20 > OLD: > SRV records, the service name MUST be set to "turns" and the > application name to "udp". > ... > SRV records, the service name MUST be set to "stuns" and the > application name to "udp". > NEW: > SRV records, the service name MUST be set to "turns" and the > protocol name to "udp". > ... > SRV records, the service name MUST be set to "stuns" and the > protocol name to "udp". OK --=20 Marc Petit-Huguenin Developer | Jive Communications, Inc. Jive.com | marcph@getjive.com --85bP0XhHL079Q95Vc0rrTKtOENhqt8Adh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTpEaCAAoJEMUNRP98lsiXzZIH/056WifWa1iDlUQ2vWvcd12l /cdQzqrVTzZToY2rZHIDotxZQvRKjKz89Fw04O+hkaKmdD+gBGm/N1kRhVwiWqx6 ywlu7q3L3iQepfFOY0+i/0P5fyLkx78NcWQbwxqgWmPzQIzRvWT2EFWY8as8RByI fVf0IyQ37Raws28uIQ1cEKEN2EFm+SVXNUjgHJTDArmmwopFByYzkCQhFhH5Q13c oVMJvf2QAPJDSpsBItG/FsgUiV2zWZruXfG0BrpWAjAbdIFH8rFgvI5begYasKbW Nk3zE1YZTdmGPrhiF3FCr3P1sDd0JMrsQinfmDq4e/b2gkKr3d4LdpAqWUg0ukY= =hVec -----END PGP SIGNATURE----- --85bP0XhHL079Q95Vc0rrTKtOENhqt8Adh-- From nobody Sun Jun 22 15:49:26 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E031A03C5; Sun, 22 Jun 2014 15:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyyvM6dVnJyb; Sun, 22 Jun 2014 15:49:20 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 531721A03AD; Sun, 22 Jun 2014 15:49:20 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id v10so4924019pde.40 for ; Sun, 22 Jun 2014 15:49:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=yTJK0H2/xtYMMQmN83pZrIayCAgfXe0NCo1sn2I3X/M=; b=zXpjKqFPkr0sz7yeMsFlwOkd1tGEGxtjuQuGp3JEHUmsqsDRLuvem9t9BJyXAm8klK zW4nvKy3h93ZR0tfvVKag4iHLRc0vNpa/Ij52WiHspBWbV38mBiWHs6p29P2PjT7Wx83 gBglxrLw5o+JABqIQX3DxH0AskMCm8yg4/CigZ+38naqZRP5zkkdN557Yg5ykMnfHO9C kcTUrpJF1YcWAVwG0jMLrKzpRTUXiCVxIqTdJrTOflXVSOSvVuCSutRSbGZDq2+9Joq0 Q989DZxZT4nr/9GXowuEAuiGTU+abAEobEdnzR5HwW3P3nEAdAyyW/wbregX363gmfGS pzWg== X-Received: by 10.69.3.67 with SMTP id bu3mr23767876pbd.34.1403477359937; Sun, 22 Jun 2014 15:49:19 -0700 (PDT) Received: from [192.168.1.76] (172-3-137-150.lightspeed.sntcca.sbcglobal.net. [172.3.137.150]) by mx.google.com with ESMTPSA id oz7sm23659172pbc.41.2014.06.22.15.49.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 22 Jun 2014 15:49:19 -0700 (PDT) Message-ID: <53A75D6E.3020502@gmail.com> Date: Sun, 22 Jun 2014 15:49:18 -0700 From: Chris Lonvick User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: iesg@ietf.org, secdir@ietf.org, draft-secretaries-good-practices.all@tools.ietf.org Content-Type: multipart/alternative; boundary="------------000701050507030907010205" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/ofoPi6j6UtT-7lVPrcTVQdmmD68 Subject: [secdir] SECDIR draft-secretaries-good-practices.06.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2014 22:49:23 -0000 This is a multi-part message in MIME format. --------------000701050507030907010205 Content-Type: text/plain; charset=ISO-8859-1; 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 appears to be well written and thorough. I have one security related suggestion and some nits. It appears that this document suggests that some Secretaries should be given access to tools that are normally reserved for Chairs, such as maillist administration. It would be prudent to note in the Security Considerations section that the Chairs know how to revoke those privileges in case of problems. The authors may wish to consider the following nits. The third line of the first paragraph of the Introduction is a bit confusing. current: of RFC 2418 [1]). Over time, the WG Secretary role's has greatly suggested: of RFC 2418 [1]). Over time, the role of the WG Secretary has greatly The last sentence of the second paragraph of the Introduction seems to run on for a bit. current: In that regard, part or even all of the guidelines it provides might not be relevant for the smaller WGs, the Chairs of which do not need to delegate operational tasks as they handle them by themselves. suggested: In that regard, part or even all of the guidelines provided in this document might not be relevant for the successful operation of smaller WGs. In those, the Chairs may not need to delegate operations tasks. The last two sentences of second bullet in Section 3.1.1 could use some more explanation. current: The call for discussion slots should remind these policies as well as how should the requests be formulated, together with a deadline for sending them. The call would also typically include information on when will the particular WG session be held during the IETF meeting noting that the IETF agenda is draft until being final. proposed: The note sent by the Secretary should remind the WG members of the policies, the formats of requests, and deadlines. Note: I would just strike the last sentence as that seems to be better discussed in the next bullet. I'll suggest some rewording of "Proposing a WG session agenda" current: Based on the collected discussion's slot requests, and depending on the known preferences of the WG Chairs for the typical structure of their WG sessions, or on the objectives Chairs have for a particular WG session, and/or on his/her personal view, the Secretary could propose to the Chairs a structured agenda for the upcoming WG session. Following that, the WG Secretary could work with the Chairs to finalise the agenda in view of publishing a first draft agenda. proposed: While the decisions for the slot are to be made by the WG Chairs, the Secretary can further aid them by proposing a session agenda based upon his/her knowledge of the preference of the Chairs and the topical work of the WG. Following that, the WG Secretary could work with the Chairs to finalize the agenda. I'll suggest some rewording of the third paragraph in Section 4. current: Although typically a WG might only have one Secretary there is no reason why two Secretaries might not be appointed. This might be to help transition a new WG secretary into the role, before the previous Secretary steps down, or simply to load balance the tasks across two Secretaries. Reciprocally, a person may perfectly be Secretary of multiple WGs. This primarily depends on his/her ability to deal with the induced workload, noting nevertheless that synergies may be realised in such a situation. In any case, this document does not give a recommendation on what should be the appropriate value for the "Secretary / WG" ratio. proposed: Typically a WG may have a Secretary to cover the expected workload. However, a WG may consider having multiple Secretaries if the workload is very excessive, or to provide an overlap of Secretaries to transition the role as one steps down. There may also be other reasons for multiple Secretaries that have not been recognized yet. Similar to individuals holding Chair roles in multiple WGs, there is no known reason why individuals cannot hold Secretary roles in multiple WGs, or that they may be a Chair of some WGs and Secretary of other WGs. This will depend on his/her ability to deal with the workload, noting that synergies may be realized in such situations. A couple of minor things in the first paragraph of Section 5 current: Section 3 has listed the typical functions and responsibilities of WG Secretaries. The role of a WG Secretary can range from a few of these to the full spectrum of them, and even beyond. In that regard, there is a number of additional WG related events to which the support of the WG Secretary would be useful. Those for example include planning and setting for WG interim meetings, design team meetings, etc. Nevertheless, some tasks described herein apply to these contexts. proposed: Section 3 has listed the typical functions and responsibilities of WG Secretaries. The role of a WG Secretary can range from a few of these to the full spectrum of them, and even beyond. In that regard, there may be additional WG related events to which the support of the WG Secretary would be useful; for example, planning WG interim meetings. Best regards, Chris --------------000701050507030907010205 Content-Type: text/html; charset=ISO-8859-1 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 appears to be well written and thorough.  I 
have one security related suggestion and some nits.

It appears that this document suggests that some Secretaries should 
be given access to tools that are normally reserved for Chairs, such
as maillist administration.  It would be prudent to note in the
Security Considerations section that the Chairs know how to revoke 
those privileges in case of problems.

The authors may wish to consider the following nits.  

The third line of the first paragraph of the Introduction is a bit confusing.
current:
   of RFC 2418 [1]). Over time, the WG Secretary role's has greatly
suggested:
   of RFC 2418 [1]).  Over time, the role of the WG Secretary has greatly

The last sentence of the second paragraph of the Introduction seems to run on for a bit.
current:
   In that regard, part or even all of the guidelines it
   provides might not be relevant for the smaller WGs, the Chairs of
   which do not need to delegate operational tasks as they handle them
   by themselves.
suggested:
   In that regard, part or even all of the guidelines provided in this
   document might not be relevant for the successful operation of
   smaller WGs.  In those, the Chairs may not need to delegate 
   operations tasks.

The last two sentences of second bullet in Section 3.1.1 could use some more explanation.
current:
   The call for discussion slots
   should remind these policies as well as how should the requests be
   formulated, together with a deadline for sending them.  The call would
   also typically include information on when will the particular WG
   session be held during the IETF meeting noting that the IETF agenda
   is draft until being final.
proposed:
   The note sent by the Secretary should remind the WG members of the
   policies, the formats of requests, and deadlines.  
Note: I would just strike the last sentence as that seems to be better discussed in the 
next bullet.
   
I'll suggest some rewording of "Proposing a WG session agenda"
current:
   Based on the collected discussion's slot requests, and depending on
   the known preferences of the WG Chairs for the typical structure of
   their WG sessions, or on the objectives Chairs have for a particular
   WG session, and/or on his/her personal view, the Secretary could
   propose to the Chairs a structured agenda for the upcoming WG
   session. Following that, the WG Secretary could work with the Chairs
   to finalise the agenda in view of publishing a first draft agenda.
proposed:
   While the decisions for the slot are to be made by the WG Chairs,
   the Secretary can further aid them by proposing a session agenda
   based upon his/her knowledge of the preference of the Chairs and
   the topical work of the WG.  Following that, the WG Secretary could 
   work with the Chairs to finalize the agenda.
   
I'll suggest some rewording of the third paragraph in Section 4.
current:
   Although typically a WG might only have one Secretary there is no
   reason why two Secretaries might not be appointed. This might be to
   help transition a new WG secretary into the role, before the previous
   Secretary steps down, or simply to load balance the tasks across two
   Secretaries. Reciprocally, a person may perfectly be Secretary of
   multiple WGs. This primarily depends on his/her ability to deal with
   the induced workload, noting nevertheless that synergies may be
   realised in such a situation. In any case, this document does not
   give a recommendation on what should be the appropriate value for the
   "Secretary / WG" ratio.
proposed:
   Typically a WG may have a Secretary to cover the expected workload.
   However, a WG may consider having multiple Secretaries if the 
   workload is very excessive, or to provide an overlap of Secretaries 
   to transition the role as one steps down.  There may also be other
   reasons for multiple Secretaries that have not been recognized yet.

   Similar to individuals holding Chair roles in multiple WGs, there is
   no known reason why individuals cannot hold Secretary roles in
   multiple WGs, or that they may be a Chair of some WGs and Secretary of
   other WGs.  This will depend on his/her ability to deal with the
   workload, noting  that synergies may be realized in such situations.
   
A couple of minor things in the first paragraph of Section 5
current:
   Section 3 has listed the typical functions and responsibilities of WG
   Secretaries. The role of a WG Secretary can range from a few of these
   to the full spectrum of them, and even beyond. In that regard, there
   is a number of additional WG related events to which the support of
   the WG Secretary would be useful. Those for example include planning
   and setting for WG interim meetings, design team meetings, etc.
   Nevertheless, some tasks described herein apply to these contexts.
proposed:
   Section 3 has listed the typical functions and responsibilities of WG
   Secretaries. The role of a WG Secretary can range from a few of these
   to the full spectrum of them, and even beyond. In that regard, there
   may be additional WG related events to which the support of
   the WG Secretary would be useful; for example, planning WG interim 
   meetings.


Best regards,
Chris


  


--------------000701050507030907010205--


From nobody Sun Jun 22 19:28:05 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB921B2876; Sun, 22 Jun 2014 19:27:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAC3IWkJnGS9; Sun, 22 Jun 2014 19:27:56 -0700 (PDT)
Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD69A1B2861; Sun, 22 Jun 2014 19:27:55 -0700 (PDT)
Received: by mail-wi0-f182.google.com with SMTP id bs8so3277385wib.3 for ; Sun, 22 Jun 2014 19:27:54 -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:content-type; bh=3uxG3KKUwh4GrJjom2LwwpRU21ndD0mNR3X37R2S7cQ=; b=IIzhh4s4feDKdN0JJU7XQPVxTk5GZlkk5HNjUiDb0TwLBnXPCNU3Vh3A80xpTa3PBB uUSD26+VfVFrj6oM6WLDxUFs4QL46noRHncfRk9XzqnguaCy4p3GJZmlxKmIPRhb1dHI awRF4dY6LO2cJ8SWqcBM85WfE8ZK7AkvaBCq0Grl+3TZWh4sPib/hZ6zaoH6Sq+vj/bo B/sLIS08TbJEVo/mwWUdsRDCq5TvN/unEQ20V4tgSS3RRs3Zl5RRCqqjYbNC6NsHlAmg 6Hc2C2AOVoan9hDaIxMx1RHvhVbRWt4sV3xlozV+0Axdr2C5tOxkQivVJ9wVfOe9Ouzz rJAg==
MIME-Version: 1.0
X-Received: by 10.180.37.42 with SMTP id v10mr22177557wij.43.1403490474304; Sun, 22 Jun 2014 19:27:54 -0700 (PDT)
Received: by 10.216.191.1 with HTTP; Sun, 22 Jun 2014 19:27:54 -0700 (PDT)
Date: Sun, 22 Jun 2014 22:27:54 -0400
Message-ID: 
From: Matthew Lepinski 
To: draft-ietf-tcpm-tcp-rfc4614bis.all@tools.ietf.org,  "secdir@ietf.org" , "iesg@ietf.org" 
Content-Type: multipart/alternative; boundary=e89a8f6473c72aa9f304fc779762
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/8a7SQqiIatU4V6yx_l4Dzs3R2WY
Subject: [secdir] Secdir Review of draft-ietf-tcpm-tcp-rfc4614bis-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Jun 2014 02:28:00 -0000

--e89a8f6473c72aa9f304fc779762
Content-Type: text/plain; charset=UTF-8

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

This draft is an update to the Roadmap for TCP specifications (RFC 4614).
The roadmap provides a pointer (along with a brief abstract) to key TCP
specifications. The update to the roadmap makes small changes to the
organization of the roadmap and (more importantly) adds pointers to a
number of more recent TCP-related specifications.

This document appears to be ready for publication. I found no problems with
this document.

As a collection of pointers to other specifications, this document does not
introduce any new security concerns. Security issues related to TCP are
addressed in individual specifications referenced in this roadmap. (Indeed,
one of the changes made in this update to the roadmap is to include more
pointers to documents related to TCP security, such as the specification
for TCP-AO.)

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


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



This draft is an update to the Roadmap for TCP specifications (RF=
C 4614). The roadmap provides a pointer (along with a brief abstract) to ke=
y TCP specifications. The update to the roadmap makes small changes to the =
organization of the roadmap and (more importantly) adds pointers to a numbe=
r of more recent TCP-related specifications.



This document appears to be ready for publicat=
ion. I found no problems with this document.



As a collection of pointers to other specifica=
tions, this document does not introduce any new security concerns. Security=
 issues related to TCP are addressed in individual specifications reference=
d in this roadmap. (Indeed, one of the changes made in this update to the r=
oadmap is to include more pointers to documents related to TCP security, su=
ch as the specification for TCP-AO.)




--e89a8f6473c72aa9f304fc779762--


From nobody Sun Jun 22 23:03:27 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC331A01A5; Sun, 22 Jun 2014 23:03:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.451
X-Spam-Level: 
X-Spam-Status: No, score=-3.451 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ci5MIOfRKFnP; Sun, 22 Jun 2014 23:03:23 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 924AD1B2991; Sun, 22 Jun 2014 23:03:23 -0700 (PDT)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5N63L1s027535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Jun 2014 06:03:22 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s5N63JuV028297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jun 2014 06:03:20 GMT
Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5N63IRG009983; Mon, 23 Jun 2014 06:03:19 GMT
Received: from [10.159.122.68] (/10.159.122.68) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 22 Jun 2014 23:03:18 -0700
Message-ID: <53A7C33A.9040202@oracle.com>
Date: Mon, 23 Jun 2014 00:03:38 -0600
From: Shawn M Emery 
User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20140508 Thunderbird/17.0.11
MIME-Version: 1.0
To: secdir@ietf.org
References: <53389B18.9060305@oracle.com>
In-Reply-To: <53389B18.9060305@oracle.com>
Content-Type: multipart/alternative; boundary="------------090009040502040302020309"
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/fF49zc9n1BDZ1T9GBjhj4j0U5_8
Cc: draft-ietf-hip-rfc5202-bis.all@tools.ietf.org, iesg@ietf.org
Subject: [secdir] Review of draft-ietf-hip-rfc5202-bis-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Jun 2014 06:03:25 -0000

This is a multi-part message in MIME format.
--------------090009040502040302020309
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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

This standards track draft is intended to obsolete RFC 5202.  5202-bis
describes Host Identity Protocol (HIP) extensions which uses the Encapsulated
Security Payload (ESP) mechanism for the exchange of user data.

The security considerations section does exist and defers to ESP's (RFC 4303)
security considerations.  The section goes on to describe the security features
of the draft, but does not provide insight to what attacks are possible and how
the protocol extensions does or does not mitigate against said attacks.

General comments:

It would be easier to discern differences between the original RFC and bis
update if there was a section that described these changes.  This would be
beneficial to reviewers, such as myself, and implementers alike.

Editorial comments:

None.

Shawn.
--


--------------090009040502040302020309
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    

      

        
        

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

This standards track draft is intended to obsolete RFC 5202.  5202-bis
describes Host Identity Protocol (HIP) extensions which uses the Encapsulated
Security Payload (ESP) mechanism for the exchange of user data.

The security considerations section does exist and defers to ESP's (RFC 4303)
security considerations.  The section goes on to describe the security features
of the draft, but does not provide insight to what attacks are possible and how
the protocol extensions does or does not mitigate against said attacks.

General comments:

It would be easier to discern differences between the original RFC and bis
update if there was a section that described these changes.  This would be
beneficial to reviewers, such as myself, and implementers alike.

Editorial comments:

None.

Shawn.
--


        

      

    

  


--------------090009040502040302020309--


From nobody Mon Jun 23 06:59:24 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85EA01B2B06; Mon, 23 Jun 2014 06:59:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level: 
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7ox9bnuNoRS; Mon, 23 Jun 2014 06:59:18 -0700 (PDT)
Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6F851B2962; Mon, 23 Jun 2014 06:59:15 -0700 (PDT)
Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s5NDxEhi027089; Mon, 23 Jun 2014 09:59:14 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1403531954; bh=qx11UOxN0kpyIplih31gK9R2/8UcHH9Nj7fJuEBiaAY=; h=From:To:CC:Subject:Date:Message-ID:Content-Type:Content-ID: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:In-Reply-To: References; b=LXFjmNo24P0VHvdlopyjdfUWsK593zOPr9CYFqwXyiuyzZvfojlnHDj7jSkqkOLed Bgc21LwlZkRpy0hqiJDwN1ZsP1OlJyH/n1HBzyl4xQXdSYTE6ZTLkgwGVvjmepCwN5 3ekgnwmGs3hwA03KSDgz6og6iF2sv86H5Bt0+P6k=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id s5NDxJWP032766; Mon, 23 Jun 2014 09:59:19 -0400
Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.02.0347.000; Mon, 23 Jun 2014 09:59:10 -0400
From: Chris Inacio 
To: "" 
Thread-Topic: review of draft-ietf-mpls-smp-requirements-06
Thread-Index: AQHPjutOvsydJA6Q1kiOlx9WmLKIAw==
Date: Mon, 23 Jun 2014 13:59:09 +0000
Message-ID: <4B67B93E-4E34-4A62-9B07-B0E3F1DCEDDA@cert.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.64.51.97]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/oW41CaYW1rv5HXPmYseIey3wYsg
Cc: "draft-ietf-mpls-smp-requirements-06.all@tools.ietf.org" , " IESG" 
Subject: [secdir] review of draft-ietf-mpls-smp-requirements-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Jun 2014 13:59:20 -0000

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

Firstly, this document is a requirements document, and therefore doesn=92t =
necessarily have a large need for security considerations, the resulting pr=
otocols can bear the burden.  Although I wouldn=92t complain if the authors=
 had put more into the security considerations in the requirements =96 like=
 acknowledging the exhaustion of resources related to preemption, especiall=
y by a malicious actor.  Or a malicious actor attempting to cause a alterna=
te path to force traffic by a sensor/device.

The security considerations section references the security considerations =
to 2 other RFCs, which in turn references multiple other RFCs which referen=
ce multiple standards.  My depth limit of reviewing the security considerat=
ions sections stopped at 1-level of reference.  It is assumed that the rela=
ted RFCs have also gone through security review previous and that review is=
 sufficient in this case.


Editorial NITS:

Section 4.1, last paragraph:
=20
the commitment of the shared
   resources are be coordinated between the different working paths in
   the SMP network.

should be:

shared resources are to be coordinated


Section 5.5:

Referring the =93former" and =93later=94, each with a complex combination o=
f events and times is a bit difficult to read, even though the sentences ar=
e completely correctly structured.  It might be worth being a little more v=
erbose to simplify the reading. I say this as a native english speaker.  I =
wouldn=92t want to read that if English was my second language.


regards,
--
Chris Inacio
inacio@cert.org




From nobody Tue Jun 24 03:20:24 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC04D1B29CC for ; Tue, 24 Jun 2014 03:20:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.652
X-Spam-Level: 
X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWJ8HJUrtgri for ; Tue, 24 Jun 2014 03:20:18 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8E81B29E2 for ; Tue, 24 Jun 2014 03:20:17 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8B0BDBE4D for ; Tue, 24 Jun 2014 11:20:16 +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 XZp3NLnSL9Bl for ; Tue, 24 Jun 2014 11:20:15 +0100 (IST)
Received: from [10.196.201.139] (179-193.icannmeeting.org [199.91.193.179]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D651ABE8B for ; Tue, 24 Jun 2014 11:20:12 +0100 (IST)
Message-ID: <53A950DC.2090604@cs.tcd.ie>
Date: Tue, 24 Jun 2014 11:20:12 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "secdir@ietf.org" 
References: <53A2D94B.6080503@cs.tcd.ie>
In-Reply-To: <53A2D94B.6080503@cs.tcd.ie>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/FYwRe53rq1EYdx5NspngRgSo3bY
Subject: Re: [secdir] Tuesday lunch in Toronto conflict
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Jun 2014 10:20:21 -0000

Result: 11 participants, 8 said don't move, 3 said
they'll go to the ISOC gig, so we'll stick with the
usual secdir Tuesday lunch slot.

Thanks,
S.

On 19/06/14 13:36, Stephen Farrell wrote:
> 
> Hiya,
> 
> ISOC are organising one of their lunch time sessions in Toronto
> on the topic of "Internet Security and Privacy: Ten years later"
> 
> That conflicts with out usual get together which is a pity.
> We could try find another slot or just live with the conflict.
> (These ISOC things tend to be fairly high level informational
> panels rather than nitty-gritty lets-do-stuff meetings so I'm
> told.)
> 
> Kathleen and I would like to see what folks prefer. If enough
> of us want to move we'll try (and possibly fail) to find
> another slot.
> 
> I've created a doodle poll.
> 
> Please answer:
> 
> yes - if want to attend both and we should try move
>       the secdir lunch
> 
> if-need-be - if you're going to attend the ISOC thing
>       and not secdir if there is a conflict
> 
> no - if you think we should live with the conflict and
>       you will attend secdir regardless
> 
> The poll is at [1]. Please fill it in before the end
> of next Monday. If you've comments on the poll, enter
> them there please - if we need more mail on this we
> can do that next week.
> 
> If you're doing something else during that slot, then
> why did you read this far? :-)
> 
> Thanks,
> S.
> 
> [1] http://doodle.com/ktv2q3yr6s4e2am5
> 
> _______________________________________________
> 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 Jun 24 08:49:26 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4781B2DF9 for ; Tue, 24 Jun 2014 08:49:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.151
X-Spam-Level: 
X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RiJx6LuKPF1n for ; Tue, 24 Jun 2014 08:49:17 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88F201B2D70 for ; Tue, 24 Jun 2014 08:48:08 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:59572 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WzSxE-000KpZ-H3; Tue, 24 Jun 2014 11:48:17 -0400
Message-ID: <53A99DB2.5050707@bbn.com>
Date: Tue, 24 Jun 2014 11:48:02 -0400
From: Stephen Kent 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: secdir , bclaise@cisco.com, jparello@cisco.com,  moulchan@cisco.com, n.brownlee@auckland.ac.nz, tnadeau@lucidvision.com,  joel jaeggli 
Content-Type: multipart/alternative; boundary="------------060605060003090203090209"
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/0Tm5J20cE1UbrCt6BrMrTUErRB8
Subject: [secdir] SECDIR review of draft-ietf-eman-energy-aware-mib-15
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Jun 2014 15:49:22 -0000

This is a multi-part message in MIME format.
--------------060605060003090203090209
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I reviewed this document as part of the security directorate's ongoing 
effort to review all IETF documents being processed by the IESG.These 
comments were written primarily for the benefit of the security area 
directors.Document editors and WG chairs should treat these comments 
just like any other last call comments. Since I am not a MIB expert, my 
comments are strictly related to the security-relevant aspects of this 
document.

This document, as its name implies, defines a MIB for energy management 
devices. Given increasing concern over security in the so-called 
"cyber-physical" realm, a MIB for such devices clearly merits scrutiny. 
Also, to the extent that such devices (e.g., meters) might be associated 
with residences, there are personal privacy issues that ought to be 
addressed, in the PERPASS era.

The document is clearly written; my compliments to the authors in that 
regard. The one odd thing I noted was that Sections 11.1 and 11.2 appear 
between Sections 6 and 7! I think this was a cut and paste error that is 
easily remedied.

The Security Considerations section (7) is about one-half page in 
length. I have several concerns with the text here.

First, the text says "It is thus important to control even GET and/or 
NOTIFY access to these objects and possibly to even encrypt the values 
of these objects when sending them over the network via SNMP." This 
seems to be an understatement. I'd like to see the text here RECOMMEND 
use of encryption to provide confidentiality. This would be supportive 
of personal privacy, in residential contexts, and physical security in 
residential and enterprise settings. I can imagine a movie in which 
burglars use a lack of encryption to gain critical information about 
building infrastructure from a an energy MIB J.

The text later says "There are a number of management objects defined in 
these MIB modules with a MAX-ACCESS clause of read-write and/or 
read-create.Such objects MAY be considered sensitive or vulnerable in 
some network environments.The support for SET operations in a non-secure 
environment without proper protection can have a negative effect on 
network operations. Again, this strikes me as a significant 
understatement, i.e., the scope of the "negative effect" could be much 
broader that just a network. (Power outlets are cited as examples of 
objects, so anything plugged into an outlet could be effected, right?) 
There should be more emphasis on the need for access control.

The text later says "SNMP versions prior to SNMPv3 did not include 
adequate security. Even if the network itself is secure (for example, by 
using IPsec), there is still no secure control over who on the secure 
network is allowed to access and GET/SET (read/change/create/delete) the 
objects in these MIB modules." This is a misleading. IPsec natively 
provides access control. It would be accurate to say that the access 
controls offered by IPsec would only limit who could access the MIB. 
What the authors seem to suggest here is finer-grained access control, 
so that one can manage GET/SET privileges for the set of individuals who 
are authorized to connect to the MIB via the SMTP port, right?

The text discussing use of SNMPv3 security is a bit confusing.

It RECOMMENDS that implementers "consider" SMNPv3 security features, but 
then says deployment of SNMP versions prior to v3 is NOT RECOMMENDED. 
The first paragraph discussing this topic deals with thinking about 
support (vs. use) of SNMPv3, while the second paragraph makes a much 
stronger statement about deployment. It would be more consistent to 
mandate support (MUST or SHOULD) for SNMPv3 in entities that incorporate 
this MIB. Separately the document can RECOMMEND enabling SNMPv3 security 
features in deployments, for the reasons cited.

--------------060605060003090203090209
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    
    
I
        reviewed this document as part of the security directorate's
        ongoing effort to
        review all IETF documents being processed by the IESG.  These comments were written
        primarily for the
        benefit of the security area directors. 
        Document editors and WG chairs should treat these
        comments just like any
        other last call comments. Since I am not a MIB expert, my
        comments are strictly
        related to the security-relevant aspects of this document.

    
 

    
This
        document, as its name
        implies, defines a MIB for energy management devices. Given
        increasing concern
        over security in the so-called “cyber-physical” realm, a MIB for
        such devices
        clearly merits scrutiny. Also, to the extent that such devices
        (e.g., meters)
        might be associated with residences, there are personal privacy
        issues that
        ought to be addressed, in the PERPASS era.

    
 

    
The document
        is clearly
        written; my compliments to the authors in that regard. The one
        odd thing I
        noted was that Sections 11.1 and 11.2 appear between Sections 6
        and 7! I think
        this was a cut and paste error that is easily remedied.

    
 

    
The Security
        Considerations section (7) is about one-half page in length. I
        have several
        concerns with the text here.

    
 

    
First, the
        text says “It
        is thus important to control even GET and/or NOTIFY access to
        these objects and
        possibly to even encrypt the values of these objects when
        sending them over the
        network via SNMP.” This seems to be an understatement. I’d like
        to see the text
        here RECOMMEND use of encryption to provide confidentiality.
        This would be
        supportive of personal privacy, in residential contexts, and
        physical security
        in residential and enterprise settings. I can imagine a movie in
        which burglars
        use a lack of encryption to gain critical information about
        building
        infrastructure from a an energy MIB J.

    
 

    
The text
        later says “There
        are a number of management objects defined in these MIB modules
        with a
        MAX-ACCESS clause of read-write and/or read-create.  Such objects MAY be
        considered sensitive or
        vulnerable in some network environments. 
        The support for SET operations in a non-secure
        environment without
        proper protection can have a negative effect on network
        operations. Again, this
        strikes me as a significant understatement, i.e., the scope of
        the “negative
        effect” could be much broader that just a network. (Power
        outlets are cited as
        examples of objects, so anything plugged into an outlet could be
        effected,
        right?)  There should be
        more emphasis on
        the need for access control.

    
 

    
The text
        later says “SNMP
        versions prior to SNMPv3 did not include adequate security. Even
        if the network
        itself is secure (for example, by using IPsec), there is still
        no secure
        control over who on the secure network is allowed to access and
        GET/SET (read/change/create/delete)
the
        objects in these MIB modules.” This is a misleading. IPsec
        natively
        provides access control. It would be accurate to say that the
        access controls
        offered by IPsec would only limit who could access the MIB. What
        the authors
        seem to suggest here is finer-grained access control, so that
        one can manage
        GET/SET privileges for the set of individuals who are authorized
        to connect to
        the MIB via the SMTP port, right?
    

    
 

    
The text
        discussing use of
        SNMPv3 security is a bit confusing.

    It RECOMMENDS that implementers
      “consider”
      SMNPv3 security features, but then says deployment of SNMP
      versions prior to v3
      is NOT RECOMMENDED. The first paragraph discussing this topic
      deals with
      thinking about support (vs. use) of SNMPv3, while the second
      paragraph makes a
      much stronger statement about deployment. It would be more
      consistent to mandate
      support (MUST or SHOULD) for SNMPv3 in entities that incorporate
      this MIB.
      Separately the document can RECOMMEND enabling SNMPv3 security
      features in
      deployments, for the reasons cited. 
    
    
    
    
    
    
    
    
    
    
  


--------------060605060003090203090209--


From nobody Tue Jun 24 13:47:37 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699C21B2827 for ; Tue, 24 Jun 2014 13:47:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fbkn9AEtktrl for ; Tue, 24 Jun 2014 13:47:32 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1CBA1B27ED for ; Tue, 24 Jun 2014 13:47:25 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C4C97F5A; Tue, 24 Jun 2014 22:47:23 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 8Yq6WIkuBnDW; Tue, 24 Jun 2014 22:47:14 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 24 Jun 2014 22:47:22 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0974A2003A; Tue, 24 Jun 2014 22:47:22 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id tBeLXqewSQ6K; Tue, 24 Jun 2014 22:47:20 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2C9D720039; Tue, 24 Jun 2014 22:47:19 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 63B4C2D9659F; Tue, 24 Jun 2014 22:47:19 +0200 (CEST)
Date: Tue, 24 Jun 2014 22:47:19 +0200
From: Juergen Schoenwaelder 
To: Stephen Kent 
Message-ID: <20140624204718.GB19710@elstar.local>
Mail-Followup-To: Stephen Kent , secdir , bclaise@cisco.com, jparello@cisco.com, moulchan@cisco.com, n.brownlee@auckland.ac.nz, tnadeau@lucidvision.com, joel jaeggli 
References: <53A99DB2.5050707@bbn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <53A99DB2.5050707@bbn.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/NXsV74tNywKlVXlgQOOHIb5eObY
Cc: tnadeau@lucidvision.com, secdir , joel jaeggli , jparello@cisco.com, n.brownlee@auckland.ac.nz, bclaise@cisco.com, moulchan@cisco.com
Subject: Re: [secdir] SECDIR review of draft-ietf-eman-energy-aware-mib-15
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Jun 2014 20:47:35 -0000

Hi,

there is a security boilerplate that we are following.

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

If you think this is not appropriate anymore, we need to have a
discussion to update the boilerplate instead of debating specific MIB
modules.  Note that this topic comes up periodically - usually without
much changes to the boilerplate at the end. Lets see the result this
time. ;-)

/js

On Tue, Jun 24, 2014 at 11:48:02AM -0400, Stephen Kent wrote:
> I reviewed this document as part of the security directorate's ongoing 
> effort to review all IETF documents being processed by the IESG.These 
> comments were written primarily for the benefit of the security area 
> directors.Document editors and WG chairs should treat these comments 
> just like any other last call comments. Since I am not a MIB expert, my 
> comments are strictly related to the security-relevant aspects of this 
> document.
> 
> This document, as its name implies, defines a MIB for energy management 
> devices. Given increasing concern over security in the so-called 
> "cyber-physical" realm, a MIB for such devices clearly merits scrutiny. 
> Also, to the extent that such devices (e.g., meters) might be associated 
> with residences, there are personal privacy issues that ought to be 
> addressed, in the PERPASS era.
> 
> The document is clearly written; my compliments to the authors in that 
> regard. The one odd thing I noted was that Sections 11.1 and 11.2 appear 
> between Sections 6 and 7! I think this was a cut and paste error that is 
> easily remedied.
> 
> The Security Considerations section (7) is about one-half page in 
> length. I have several concerns with the text here.
> 
> First, the text says "It is thus important to control even GET and/or 
> NOTIFY access to these objects and possibly to even encrypt the values 
> of these objects when sending them over the network via SNMP." This 
> seems to be an understatement. I'd like to see the text here RECOMMEND 
> use of encryption to provide confidentiality. This would be supportive 
> of personal privacy, in residential contexts, and physical security in 
> residential and enterprise settings. I can imagine a movie in which 
> burglars use a lack of encryption to gain critical information about 
> building infrastructure from a an energy MIB J.
> 
> The text later says "There are a number of management objects defined in 
> these MIB modules with a MAX-ACCESS clause of read-write and/or 
> read-create.Such objects MAY be considered sensitive or vulnerable in 
> some network environments.The support for SET operations in a non-secure 
> environment without proper protection can have a negative effect on 
> network operations. Again, this strikes me as a significant 
> understatement, i.e., the scope of the "negative effect" could be much 
> broader that just a network. (Power outlets are cited as examples of 
> objects, so anything plugged into an outlet could be effected, right?) 
> There should be more emphasis on the need for access control.
> 
> The text later says "SNMP versions prior to SNMPv3 did not include 
> adequate security. Even if the network itself is secure (for example, by 
> using IPsec), there is still no secure control over who on the secure 
> network is allowed to access and GET/SET (read/change/create/delete) the 
> objects in these MIB modules." This is a misleading. IPsec natively 
> provides access control. It would be accurate to say that the access 
> controls offered by IPsec would only limit who could access the MIB. 
> What the authors seem to suggest here is finer-grained access control, 
> so that one can manage GET/SET privileges for the set of individuals who 
> are authorized to connect to the MIB via the SMTP port, right?
> 
> The text discussing use of SNMPv3 security is a bit confusing.
> 
> It RECOMMENDS that implementers "consider" SMNPv3 security features, but 
> then says deployment of SNMP versions prior to v3 is NOT RECOMMENDED. 
> The first paragraph discussing this topic deals with thinking about 
> support (vs. use) of SNMPv3, while the second paragraph makes a much 
> stronger statement about deployment. It would be more consistent to 
> mandate support (MUST or SHOULD) for SNMPv3 in entities that incorporate 
> this MIB. Separately the document can RECOMMEND enabling SNMPv3 security 
> features in deployments, for the reasons cited.

> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview


-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         


From nobody Tue Jun 24 15:03:42 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00DC61A01AD; Tue, 24 Jun 2014 15:03:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.149
X-Spam-Level: 
X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I388rpph1JG2; Tue, 24 Jun 2014 15:03:36 -0700 (PDT)
Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E11E1A00EB; Tue, 24 Jun 2014 15:03:36 -0700 (PDT)
Received: by mail-oa0-f48.google.com with SMTP id m1so1092007oag.21 for ; Tue, 24 Jun 2014 15:03:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:from:date:message-id:subject:to:content-type; bh=FwlrBwYqXFkpxrCjvqQ1SngTWhAf/sr5jvXG5Ts/KV0=; b=NfOF+WBCEF4fcunKkxVl5e4aNe99ft7vyzBDn7Qga+v9GbnUKw2UGiVciku496n8b8 VLGhk9aysr/VowQ2deWXDh3LP4TLSSnARvv1R9G8R0tnjES+NwjExDstAGkd5glCYi9i z5ZpIutXunjGN8RqZHvmwuNqq7/UTR0AmmZkVg81/TUmqdBJK0tSG+IaNixWchyabWTT Z6IGEK+U++zSFnoXf5eF2zJuqVmKUDbDWu869RZ8kM/HtTFSVDoOAqaQEcpeZQTeoZeX VKu+651oxh0PHmTUIHToOFsusvXWlSw5rh1vTmYgoTCQSv9TEZlQp9WeKrH6KXeQA4G7 ZOEQ==
X-Received: by 10.182.112.161 with SMTP id ir1mr3874609obb.41.1403647415449; Tue, 24 Jun 2014 15:03:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.76.25.41 with HTTP; Tue, 24 Jun 2014 15:03:15 -0700 (PDT)
From: Donald Eastlake 
Date: Tue, 24 Jun 2014 18:03:15 -0400
Message-ID: 
To: "iesg@ietf.org" , "secdir@ietf.org" ,  draft-ietf-hip-rfc5201-bis.all@tools.ietf.org
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/21qsCEciZuCxk54Td_CQXI94SiI
Subject: [secdir] SECIR review of draft-ietf-hip-rfc5201-bis-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Jun 2014 22:03:37 -0000

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

This document specifies Version 2 of HIP, the Host Identity Protocol,
obsoleting RFC 5201.

The Security Considerations includes thorough discussion of
denial-of-service and man-in-the-middle attacks which are also touched
on in other appropriate parts of the document.

I was impressed with the thoroughness of the consideration of security
issues throughout this document. I think it is ready from a security
point of view for publication.

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


From nobody Thu Jun 26 06:34:26 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4D71B30EC for ; Thu, 26 Jun 2014 06:34:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.372
X-Spam-Level: 
X-Spam-Status: No, score=-0.372 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvzkTOuoT0rK for ; Thu, 26 Jun 2014 06:34:20 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 67F761B30F3 for ; Thu, 26 Jun 2014 06:17:43 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s5QDHdsF023306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 26 Jun 2014 16:17:39 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s5QDHdfB020819; Thu, 26 Jun 2014 16:17:39 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <21420.7539.478114.917261@fireball.kivinen.iki.fi>
Date: Thu, 26 Jun 2014 16:17:39 +0300
From: Tero Kivinen 
To: secdir@ietf.org
X-Edit-Time: 0 min
X-Total-Time: 0 min
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/KasKAXE1iIWuxSnjViB18q3W1Zg
Subject: [secdir] Assignments
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: secdir-secretary@mit.edu
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jun 2014 13:34:25 -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 2014-06-26

Reviewer                 LC end     Draft
Shaun Cooley           T 2014-06-12 draft-ietf-appsawg-sieve-duplicate-09
Alan DeKok             T 2014-06-11 draft-ietf-hip-rfc4843-bis-07
Simon Josefsson        TR2014-06-25 draft-ietf-tram-stun-dtls-04
David Waltermire       T 2014-06-10 draft-salgueiro-dispatch-websocket-sipclf-01


For telechat 2014-07-10

David Harrington       T 2014-07-01 draft-ietf-ppsp-peer-protocol-10
Scott Kelly            T 2014-06-30 draft-ietf-eman-battery-mib-12
Tero Kivinen           T 2014-06-30 draft-ietf-eman-energy-monitoring-mib-10
Ben Laurie             T 2014-07-01 draft-ietf-pce-questions-06
Catherine Meadows      T 2014-07-07 draft-ietf-paws-protocol-12
Adam Montville         T 2014-07-03 draft-ietf-sidr-bgpsec-reqs-11
Russ Mundy             T 2014-07-03 draft-ietf-sidr-cps-04
Sandy Murphy           T 2014-07-04 draft-ietf-stir-threats-03
Yoav Nir               T 2014-07-04 draft-ietf-straw-sip-traceroute-02
Magnus Nystrom         T 2014-07-04 draft-ietf-xmpp-websocket-07
Ondrej Sury            T 2014-05-28 draft-ietf-ipfix-text-adt-06

Last calls and special requests:

Dan Harkins              2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-14
Sam Hartman              2014-06-23 draft-ietf-dnsop-child-syncronization-01
Jeffrey Hutzelman      E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-06
Jeffrey Hutzelman        2014-06-20 draft-ietf-mmusic-rtsp-nat-21
Leif Johansson           2014-06-24 draft-ietf-netext-wifi-epc-eap-attributes-08
Charlie Kaufman          2014-07-02 draft-ietf-6man-multicast-addr-arch-update-05
Warren Kumari            2014-07-02 draft-ietf-netext-pmip-cp-up-separation-04
Julien Laganier        E 2013-11-21 draft-ietf-websec-key-pinning-17
Julien Laganier          2014-04-29 draft-ietf-dhc-dhcpv4-over-dhcpv6-09
Julien Laganier          2014-06-30 draft-ietf-ppsp-survey-08
Alexey Melnikov          2014-07-04 draft-ietf-p2psip-service-discovery-13
Hilarie Orman            2014-07-07 draft-ietf-xrblock-rtcp-xr-psi-decodability-04
Zach Shelby              2014-06-06 draft-housley-implementer-obligations-02
Brian Weis             E 2014-01-16 draft-ietf-radext-dynamic-discovery-11
-- 
kivinen@iki.fi


From nobody Thu Jun 26 09:58:29 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15EC11B2C13 for ; Thu, 26 Jun 2014 09:58:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.852
X-Spam-Level: 
X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7lAoXkPpCZn for ; Thu, 26 Jun 2014 09:58:26 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B66491B2EF6 for ; Thu, 26 Jun 2014 09:44:09 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:55436 helo=COMSEC.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1X0CmK-0006vf-K7; Thu, 26 Jun 2014 12:44:05 -0400
Message-ID: <53AC4DD0.8090100@bbn.com>
Date: Thu, 26 Jun 2014 12:44:00 -0400
From: Stephen Kent 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: secdir , bclaise@cisco.com, jparello@cisco.com,  moulchan@cisco.com, n.brownlee@auckland.ac.nz, tnadeau@lucidvision.com,  joel jaeggli 
References: <53A99DB2.5050707@bbn.com> <20140624204718.GB19710@elstar.local>
In-Reply-To: <20140624204718.GB19710@elstar.local>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/2tCZxQX1Nz3NPEvju6kTLSEcC94
Subject: Re: [secdir] SECDIR review of draft-ietf-eman-energy-aware-mib-15
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jun 2014 16:58:28 -0000

Juergen,

I read the boilerplate you cited.

The comment re IPsec is misleading, for the reasons I noted in my review.
This is the first MIB I-D I've reviewed. I would have pointed out the 
problems
with that text earlier had I reviewed a MIB earlier :-).

With the publication of RFC 7258 as a BCP its seems appropriate to revisit
the boilerplate when discussing confidentiality and use of encryption. 
Hence
my suggestion that use of encryption be RECOMMENDED.

Since the subject of this MIB is energy management, I think that my 
comments about
the potential adverse impacts of security lapses for these MIBs are 
relevant. This
is outside the generic context for which the boilerplate was developed.

Finally, the boilerplate does not seem to use the same language as the 
text at the end
of the SC, e.g., I don't see the word "consider" in the boilerplate. The 
mix of advice dealing
with implementation vs. deployment still strikes me as confusing, as 
written. I think the
boilerplate text is better in this respect, and should be used as a 
starting point for
the last part of the SC in this I-D (tailored as needed).

Steve


From nobody Fri Jun 27 06:37:36 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2164A1B2BC1; Fri, 27 Jun 2014 06:37:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.772
X-Spam-Level: 
X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60f4ivIMGf7w; Fri, 27 Jun 2014 06:37:26 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 969291B2BBC; Fri, 27 Jun 2014 06:37:25 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s5RDbN7T029985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 27 Jun 2014 16:37:23 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s5RDbMOo005135; Fri, 27 Jun 2014 16:37:22 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <21421.29586.427961.926637@fireball.kivinen.iki.fi>
Date: Fri, 27 Jun 2014 16:37:22 +0300
From: Tero Kivinen 
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-eman-energy-monitoring-mib.all@tools.ietf.org
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 19 min
X-Total-Time: 23 min
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/gWVRQeFr1uu6h3QNlN13fblVdrg
Subject: [secdir] Secdir review of draft-ietf-eman-energy-monitoring-mib-10.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jun 2014 13:37:32 -0000

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

This document describes the MIB for energy monitoring. It has mostly
read only information about the current energy use etc, but it also
have one important writable attribute eoPowerAdminState which can be
used to change the power state of the device (shut it down?). The MIB
also have second part which can be used to create notifications and
intervals for enery usage.

Both of these are pointed out in the security consideations section
and the security considerations section mostly follows the MIB
security guidelines text, but differs in one paragraph. The text in
draft says:

       It is RECOMMENDED that implementers consider the security
       features as provided by the SNMPv3 framework (see [RFC3410],
       section 8), including full support for the SNMPv3 cryptographic
       mechanisms (for authentication and privacy).

Where the guidelines text says:

      Implementations SHOULD provide the security features described
      by the SNMPv3 framework (see [RFC3410]), and implementations
      claiming compliance to the SNMPv3 standard MUST include full
      support for authentication and privacy via the User-based
      Security Model (USM) [RFC3414] with the AES cipher algorithm
      [RFC3826]. Implementations MAY also provide support for the
      Transport Security Model (TSM) [RFC5591] in combination with a
      secure transport such as SSH [RFC5592] or TLS/DTLS [RFC6353].

Asking implementors to consider security features is something that
cannot be verified, i.e. there is no way I can see whether the
implementor x actually even considered the security features or not,
thus making RECOMMENDATION to consider security feature is just
stupid. The guidelines text instead makes SHOULD for providing
security.

Why is this text changed from the mib-security framework
(http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security).

Also I think the security considerations section should mention that
almost all of the MIB items do have privacy issues, as for example
reading the power usage of the home TV/PC/game console/washing machine
will give indication whether person is at home, and what he might be
doing. Thus the first paragraph saying "Some objects may be considered
sensitive", I would say most of the objects are sensitive in most
environments.

Actually it seems to bit dangerous to have mostly read-only
information in MIB where the only read-write item is the very security
sensitive object which can be used to turn the devices off. Especially
when the MIB name is Power and Energy MONITORING MIB. Casual operator
might just check the MIB name and then notice there is lots of
read-only information like "eoPowerNamePlate" or "eoPowerAccuracy",
etc and just assume this is only for monitoring the power usage, and
not notice that it also allows turning device on and off via one
read-write value hidden among the read-only values.

I would be more happy if that one read-write value would be moved to
separate MIB, but I do not know if there is better place for it. If it
is not moved, then it would be better to change the title of the draft
o say "Power and Energy Monitoring and Control MIB" or something
similar which indicates more clearly that this MIB can be used to
control devices. 

Nits:

In section 11:

       - Unauthorized changes to the eoPowerOperState (via
         theeoPowerAdminState ) MAY disrupt the power settings of the
	 ^^^^^^^^^^^^^^^^^^^^

s/theeoPowerAdminState/the eoPowerAdminState/.

The formatting of the draft was bit wierd in places (extra ^L in the
middle of page etc), but I assume those will be fixed by the RFC
editor. 
-- 
kivinen@iki.fi


From nobody Fri Jun 27 11:25:37 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD951B28AA; Fri, 27 Jun 2014 11:25:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level: 
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYoNBRGyzg3u; Fri, 27 Jun 2014 11:25:31 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 352B31B27B9; Fri, 27 Jun 2014 11:25:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=821; q=dns/txt; s=iport; t=1403893531; x=1405103131; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=HCK3WUrPsWVcER5Jj4BlpZD+GQlvJ9APjLSyZpWvQo8=; b=TvbErzZmM43SYa9E5V7ew7jCGLL5WqWIpq9cCNimLuDaF6QUc6E8oUyf niSynUrlcv2F21YFYTi0gR68+49rlW7yA1thMQcbQqzCfEP+1aUMOXqb2 +44ySfgCrDhb8UkXyXgawcr9DtCaX8ro5xHKtr5gmbr/aGL3d6UVVglGz g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqgFAJO2rVOtJV2U/2dsb2JhbABagw2BLKo+AQEBAQEBBQFtAZkCAYENFnWEBQEEeRIBKlYmAQQBDQ2IOsNHF4VkiD8RAR8xgzSBFgEEjgGgV4NCgXc5
X-IronPort-AV: E=Sophos;i="5.01,562,1400025600"; d="scan'208";a="56530045"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-6.cisco.com with ESMTP; 27 Jun 2014 18:25:30 +0000
Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s5RIPUXQ029549 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Jun 2014 18:25:30 GMT
Received: from xmb-aln-x10.cisco.com ([169.254.5.38]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Fri, 27 Jun 2014 13:25:30 -0500
From: "Shaun Cooley (shcooley)" 
To: "secdir@ietf.org" , "iesg@ietf.org" 
Thread-Topic: secdir review of draft-ietf-appsawg-sieve-duplicate
Thread-Index: Ac+SNLXgaJ1IgESXR/mrYhXBOpOkGA==
Date: Fri, 27 Jun 2014 18:25:29 +0000
Message-ID: <187A7B1DA239514F9146FC78B19AADE322D5E076@xmb-aln-x10.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.19.187.25]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/VS3AGjhQBPTcecYnfhzf-gwnc7k
Cc: "draft-ietf-appsawg-sieve-duplicate.all@tools.ietf.org" 
Subject: [secdir] secdir review of draft-ietf-appsawg-sieve-duplicate
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jun 2014 18:25:32 -0000

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

This document defines a new test command for the Sieve email filtering lang=
uage that allows for the detection of duplicate emails, as identified by me=
ssage ID, or more complex string matching in the headers or other parts of =
the message.

The document is easy to understand and covers the primary potential issue o=
f resource exhaustion that might arise from a flood of messages with unique=
 IDs.  I consider this document to be READY for publication.

-Shaun


From nobody Fri Jun 27 20:22:47 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070E01A0283 for ; Fri, 27 Jun 2014 20:22:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.651
X-Spam-Level: 
X-Spam-Status: No, score=-2.651 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73tzizrS6RG6 for ; Fri, 27 Jun 2014 20:22:41 -0700 (PDT)
Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEC41A027D for ; Fri, 27 Jun 2014 20:22:41 -0700 (PDT)
Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta08.westchester.pa.mail.comcast.net with comcast id KfL71o0091c6gX858fNhuC; Sat, 28 Jun 2014 03:22:41 +0000
Received: from [50.94.114.15] ([50.94.114.15]) by omta23.westchester.pa.mail.comcast.net with comcast id KfNN1o00N0Kzn4J3jfNR2D; Sat, 28 Jun 2014 03:22:38 +0000
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: David Harrington 
In-Reply-To: <21421.29586.427961.926637@fireball.kivinen.iki.fi>
Date: Fri, 27 Jun 2014 23:22:22 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <21421.29586.427961.926637@fireball.kivinen.iki.fi>
To: Tero Kivinen 
X-Mailer: Apple Mail (2.1878.2)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1403925761; bh=wZ6hef+WQVctpFrq/P+06SDxw0oxBUYVxJWtRNRc5Go=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=SVfvjgu++LDhzuw+kWRQRmjyltVgYtgrAkNutKUFVGEZd2cmurQcmBOAqi0R+qva5 +X+FzuWpuz+mIqo4AmEq9ZUPZra1XZMT4JTaUkKVvKh/cVxhZMF6F2kicnev2kBMsf 5tktkTHPIsCktKhEZ0/CeHGl7NYdcrTyQTsC/FuDwMzbblXflSwz1qDIicUloqHPAY BhwHrmaPPQEGCIvjRd1P8c+wdyG5gcl/3zfHzijDbpythx0wcPVTfEuMYJW0GUmhG8 z6oACN/8eWd2tdCYQdTx2Tjy7gHwcl/GDZLw2CrCmWFzUxIoxRhKnBqTkVn+P9tjKA 8DyFaL/z0WjCw==
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/gj_XEII2uu1UK9Ob31bUKLNprLw
Cc: draft-ietf-eman-energy-monitoring-mib.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-eman-energy-monitoring-mib-10.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Jun 2014 03:22:45 -0000

Hi,

comments inline.

dbh

On Jun 27, 2014, at 9:37 AM, Tero Kivinen  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 document describes the MIB for energy monitoring. It has mostly
> read only information about the current energy use etc, but it also
> have one important writable attribute eoPowerAdminState which can be
> used to change the power state of the device (shut it down?). The MIB
> also have second part which can be used to create notifications and
> intervals for enery usage.
>=20
> Both of these are pointed out in the security consideations section
> and the security considerations section mostly follows the MIB
> security guidelines text, but differs in one paragraph. The text in
> draft says:
>=20
>       It is RECOMMENDED that implementers consider the security
>       features as provided by the SNMPv3 framework (see [RFC3410],
>       section 8), including full support for the SNMPv3 cryptographic
>       mechanisms (for authentication and privacy).

These are the old guidelines.=20

>=20
> Where the guidelines text says:
>=20
>      Implementations SHOULD provide the security features described
>      by the SNMPv3 framework (see [RFC3410]), and implementations
>      claiming compliance to the SNMPv3 standard MUST include full
>      support for authentication and privacy via the User-based
>      Security Model (USM) [RFC3414] with the AES cipher algorithm
>      [RFC3826]. Implementations MAY also provide support for the
>      Transport Security Model (TSM) [RFC5591] in combination with a
>      secure transport such as SSH [RFC5592] or TLS/DTLS [RFC6353].
>=20
> Asking implementors to consider security features is something that
> cannot be verified, i.e. there is no way I can see whether the
> implementor x actually even considered the security features or not,
> thus making RECOMMENDATION to consider security feature is just
> stupid.

Yeah, but it=92s the best that could be negotiated at that point in =
time.

> The guidelines text instead makes SHOULD for providing
> security.
>=20
> Why is this text changed from the mib-security framework
> (http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security).

The document was probably based on an older mib document.
It MIGHT have been based on the templates on the tools page before I got =
them updated.

The document should be updated to the new boilerplate.

>=20
> Also I think the security considerations section should mention that
> almost all of the MIB items do have privacy issues, as for example
> reading the power usage of the home TV/PC/game console/washing machine
> will give indication whether person is at home, and what he might be
> doing. Thus the first paragraph saying "Some objects may be considered
> sensitive", I would say most of the objects are sensitive in most
> environments.

without changing the boilerplate, of course =85

>=20
> Actually it seems to bit dangerous to have mostly read-only
> information in MIB where the only read-write item is the very security
> sensitive object which can be used to turn the devices off. Especially
> when the MIB name is Power and Energy MONITORING MIB. Casual operator
> might just check the MIB name and then notice there is lots of
> read-only information like "eoPowerNamePlate" or "eoPowerAccuracy",
> etc and just assume this is only for monitoring the power usage, and
> not notice that it also allows turning device on and off via one
> read-write value hidden among the read-only values.
>=20
> I would be more happy if that one read-write value would be moved to
> separate MIB, but I do not know if there is better place for it. If it
> is not moved, then it would be better to change the title of the draft
> o say "Power and Energy Monitoring and Control MIB" or something
> similar which indicates more clearly that this MIB can be used to
> control devices.=20
>=20
> Nits:
>=20
> In section 11:
>=20
>       - Unauthorized changes to the eoPowerOperState (via
>         theeoPowerAdminState ) MAY disrupt the power settings of the
> 	 ^^^^^^^^^^^^^^^^^^^^
>=20
> s/theeoPowerAdminState/the eoPowerAdminState/.
>=20
> The formatting of the draft was bit wierd in places (extra ^L in the
> middle of page etc), but I assume those will be fixed by the RFC
> editor.=20
> --=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 Fri Jun 27 22:11:02 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07801A02A4; Fri, 27 Jun 2014 22:10:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdouxSbmdoRW; Fri, 27 Jun 2014 22:10:54 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F7DB1A029A; Fri, 27 Jun 2014 22:10:54 -0700 (PDT)
Received: from BL2PR03MB498.namprd03.prod.outlook.com (10.141.93.146) by BL2PR03MB497.namprd03.prod.outlook.com (10.141.93.142) with Microsoft SMTP Server (TLS) id 15.0.969.15; Sat, 28 Jun 2014 05:10:51 +0000
Received: from BL2PR03MB498.namprd03.prod.outlook.com ([10.141.93.146]) by BL2PR03MB498.namprd03.prod.outlook.com ([10.141.93.146]) with mapi id 15.00.0969.007; Sat, 28 Jun 2014 05:10:51 +0000
From: Charlie Kaufman 
To: "secdir@ietf.org" 
Thread-Topic: Secdir review of draft-ietf-6man-multicast-addr-arch-update-05
Thread-Index: Ac+SiKW4XRhXv3zlTOeprxoPra3d/w==
Date: Sat, 28 Jun 2014 05:10:50 +0000
Message-ID: <5e3dd927cd2c401bb107b3c3c7f617da@BL2PR03MB498.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [50.46.158.7]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-forefront-prvs: 0256C18696
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199002)(50986999)(33646001)(20776003)(101416001)(99286002)(95666004)(106356001)(76482001)(105586002)(66066001)(54356999)(80022001)(31966008)(76576001)(85852003)(83072002)(99396002)(74502001)(64706001)(74316001)(86362001)(92566001)(4396001)(21056001)(77982001)(81542001)(85306003)(86612001)(2656002)(74662001)(87936001)(83322001)(107046002)(2351001)(81342001)(229853001)(46102001)(79102001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB497; H:BL2PR03MB498.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/k-dyQmL31RYI0kleGSJ98tJKxjM
Cc: "draft-ietf-6man-multicast-addr-arch-update.all@tools.ietf.org" , "iesg@ietf.org" 
Subject: [secdir] Secdir review of draft-ietf-6man-multicast-addr-arch-update-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Jun 2014 05:10:57 -0000

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

This document tightens the wording around the usage of flag bits specified =
in RFCs 3306 and 3956. I don't believe it would require changes to any exis=
ting implementations, and it would be a real stretch to claim it has any se=
curity implications at all. The document's security considerations section =
references the security considerations sections of other documents. This se=
ems appropriate.

This document addresses an issue that I personally am very passionate about=
, and I believe this document takes what is already a bad situation in thos=
e earlier RFCs and makes it worse. (It is possible there is some subtlety i=
n the issues surrounding IP Multicast Addresses that makes my arguments inv=
alid, but please hear me out and think about it.)

There are too many documents that have fields labelled "flags" or "undefine=
d" or "reserved for future use" and they expect implementers to do the righ=
t thing with them. Documents should always specify what a sender should sen=
d and what recipients should do with received values. A good default policy=
 for implementers to follow is to always send packets with such fields set =
to zero and always ignore values seen in these fields. But if that is the d=
esired policy, the spec should say so, and there are times when a different=
 policy makes more sense. For example, it might also be useful to have a re=
served for future use field where a sender always sends zero and a recipien=
t treats any message containing a non-zero value as invalid. That would all=
ow a new implementation to send a message that another new implementation w=
ould process correctly and an old implementation would reject as invalid ra=
ther than processing incorrectly.

The reason for specifying behavior carefully is that future revisions to th=
e protocol may want to encode information in these fields, but to do so saf=
ely it must be possible to predict what existing implementations will do wh=
en interacting with the new ones. That is only possible if we know what exi=
sting systems are going to send and what existing systems will do when they=
 receive newly defined values.

RFCs 3306 and 3956 break these rules by saying things like "The behavior is=
 unspecified if P or T is not set to 1". Behavior should never be unspecifi=
ed. Either the values of P and T should be ignored, or the address should b=
e treated as invalid if P or T is not set to 1, or some other behavior shou=
ld be specified. The sender should have a specified behavior of always sett=
ing them to 1.

This I-D, while trying to correct some ambiguities, actually makes it worse=
. It says things like "X may be set to 0 or 1" (where X is a flag bit). It =
would be fine to say X MUST be ignored on receipt. But it should specify th=
at it MUST be sent as zero. Otherwise, implementations of the spec are free=
 to set it to zero or one and no future modification to the protocol can as=
cribe any meaning to the value set because when interoperating with an old =
implementation the received value is unpredictable and meaningless.

It divides a 4 bit "reserved" field into four 1 bit "flag" fields, but stil=
l does not specify what values those flags should be set to (presumably zer=
o) nor what an implementation should do if they are non-zero on receipt (pe=
rhaps ignore them, or perhaps reject the address... I can't guess the inten=
t.

It might be too late to do an optimal job of specifying the desired behavio=
rs with respect to these flags because that might "break" existing implemen=
tations. But we certainly shouldn't make it worse by permitting useless fle=
xibility unless it was already promised in the earlier documents.

	--Charlie Kaufman


From nobody Sun Jun 29 06:23:10 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F661A04B7; Sun, 29 Jun 2014 06:23:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsxIg7tAYKgL; Sun, 29 Jun 2014 06:23:01 -0700 (PDT)
Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 946021A04AE; Sun, 29 Jun 2014 06:23:00 -0700 (PDT)
Received: by mail-wi0-f172.google.com with SMTP id hi2so4817327wib.11 for ; Sun, 29 Jun 2014 06:22:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=qF+ckbPIxAIU1YyvYIroFpz+hvsn2ZR1kiHQJnhjdVA=; b=ZTbYurboYB3C0L19sjD4ENM0M/8sFq1bsfRaz+BQL6gbHWZWENGVx7exwqlSbup4GD JHE2aXIbPzTyoLd1w93GUvTXKiL4QwkoxF95pd+L7hWo6GlkUOK2jTNd20mdjA/+x3uN 9KnRLwd4KK52OtMwbARzwCqLU+GIq2c1BKzsgPlmHVj6u9yATtl+AwHJyZ477llR2uPq kBuHfcnUYtnAPFwg27VMrd5TZSOrETb1QkmqhsJ4DDaeQu3a0CkXB10NfOnJUcwbQr7V ewzf40S+XMZW1ynhXNk57i6jVX/STU0sz/R/Tr6mf+X+zYq50uxX1NDBbm5dYoc53FS+ fEag==
X-Received: by 10.180.107.99 with SMTP id hb3mr23103112wib.8.1404048179225; Sun, 29 Jun 2014 06:22:59 -0700 (PDT)
Received: from [172.24.251.205] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id m3sm34513615wjr.49.2014.06.29.06.22.58 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 29 Jun 2014 06:22:58 -0700 (PDT)
From: Yoav Nir 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Message-Id: 
Date: Sun, 29 Jun 2014 16:22:55 +0300
To: " IESG" , "" , draft-ietf-straw-sip-traceroute.all@tools.ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/x-MDzYhnUnrnS9mIWAlHVnQ9xqc
Subject: [secdir] SecDir Review of draft-ietf-straw-sip-traceroute-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 29 Jun 2014 13:23:03 -0000

Hi.

I have reviewed this document as part of the security directorate=92s =
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.

Short version: the document is ready with a few changes needed.

The document extends the media-loopback mechanism, described in RFC =
6849. That mechanism is used to monitor the performance of media =
delivery along a path by having the target reflect back the a media =
stream. So it=92s like ECHO, only for media. This document extends that =
mechanism by allowing the monitoring to be performed with the hops along =
the way (proxies and B2BUAs) rather than only end-to-end. This allows =
for better trouble-shooting and helps find the problematic hop. It uses =
a traceroute-like mechanism with a decreasing TTL, except here it=92s =
the Max-Forwards header field that gets decremented at each hop. When =
max-forwards reaches zero, the B2BUA replies with a 200 message, =
=93answering the call=94, and media loopback tests can be used.

This document depends on draft-ietf-straw-b2bua-loop-detection (now in =
RFC editor=92s queue). B2BUAs that do not support the latter =
specification, will not decrement the max-forwards fields, and thus will =
not take part in the protocol. In such a case, the path will appear to =
have fewer B2BUAs than it actually has.

The security considerations section is very short, and only mentions the =
possibility of resource exhaustion because of all those calls doing =
media-loopback, without using the term =93denial of service=94. IMO most =
of the security considerations of RFC 6849 apply here as well (with the =
exception of the UA indicating to the human that a loopback session is =
happening - B2BUAs don=92t have humans), so they should be repeated here =
at least by reference (as RFC 6849 itself references 3264 and 3550). =20

The section says "B2BUAs should have some means of controlling who can =
make such test calls, how many concurrent calls can be established and =
maintained, and for how long.=94  I think a document like this should =
offer something more about what these =93some means=94 are. It=92s =
possible to require authentication of the UA doing the testing to the =
B2BUA being tested. This aligns with the recommendation in RFC 6849, but =
I don=92t know whether or not authentication to B2BUAs is feasible in =
the real world.=20

Yoav


From nobody Mon Jun 30 07:56:33 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7F21A0367 for ; Mon, 30 Jun 2014 07:56:31 -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
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 CLCSTcOu8Sg7 for ; Mon, 30 Jun 2014 07:56:28 -0700 (PDT)
Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9610E1A035C for ; Mon, 30 Jun 2014 07:56:28 -0700 (PDT)
Received: by mail-pd0-f182.google.com with SMTP id y13so8386241pdi.13 for ; Mon, 30 Jun 2014 07:56:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:message-id:date:to :mime-version; bh=PGjwujretsGeV5CMKVAAbvE/WKgReitjjuZlZrETFrA=; b=YUO/+WR8HReYjImYktxNETXlkxAZNHBoLrmp1ubyOEcXSdnulrHo9kq/A1FgxNY3El 85G+ajW7mVkDPjK+G7KMcgisH4ZFNaIH9OnGIPR7t6qmybhKXF71D3oN3pAYeaZ5++mo GHSN7C9hseJxGUq5wvxZC0mEIiQj/2iWV5mmIDatFaK7Gao41P8mpNTnviYINt2MI/49 LqSGKtGSk6i9xvmYDpgHSA9JEmnB3WFI/VYt7hV7tT3E2UEcAGpJfJxQjZZ9mPnAcmoR KF7l7dLQ6vQYqJpr5qniySvjSDoFnrrQhvrBF6hw3PTzFRFGVTqimIxNCDrlpVDhg9dt Vcag==
X-Gm-Message-State: ALoCoQk6dFVSblBEXiEJBJta6jPnRmRD0/2zEPrGyenosM+sayfAB/1Rj9F4RH1Bf85hYgGJoUIx
X-Received: by 10.68.235.100 with SMTP id ul4mr52481044pbc.15.1404140188177; Mon, 30 Jun 2014 07:56:28 -0700 (PDT)
Received: from [192.168.1.55] (99-64-100-240.lightspeed.austtx.sbcglobal.net. [99.64.100.240]) by mx.google.com with ESMTPSA id vy5sm100992457pac.13.2014.06.30.07.56.25 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Jun 2014 07:56:26 -0700 (PDT)
From: "Adam W. Montville" 
Content-Type: multipart/signed; boundary="Apple-Mail=_E335DD80-1BA7-4BF6-A7C3-9A51961A8E25"; protocol="application/pgp-signature"; micalg=pgp-sha512
Message-Id: <468FCC23-2398-4165-BACA-E9F0AEF742E7@stoicsecurity.com>
Date: Mon, 30 Jun 2014 09:56:27 -0500
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-sidr-bgpsec-reqs.all@tools.ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/BVCkuBzZI5uUr1HY-CVKR97t-9U
Subject: [secdir] SecDir Review of draft-ietf-sidr-bgpsec-reqs-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Jun 2014 14:56:31 -0000

--Apple-Mail=_E335DD80-1BA7-4BF6-A7C3-9A51961A8E25
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

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 ready with (potential) nits.  When reading this =
requirements draft I tried to keep an eye on measurability: When =
implementing drafts are created, how will they be objectively measured =
to meet the requirements?

Potential Nits:

1. Requirements 3.1 and 3.2 indicate that a =93strong level of =
certainty=94 is needed, but does not define what that means in context.  =
This may be common knowledge within the community, however.=20

2. Requirement 3.13 indicates that BGPsec =93MUST provide backward =
compatibility=94, but we are left to assume that downgrade prevention is =
enabled.  We might assume that it is, but it=92s probably better not to. =
 Perhaps adding a statement to the effect of =93MUST provide backward =
compatibility=85. but also allow for strict BGPsec adherence=94 or =
something similar.  I also recognize that there may be obviating =
circumstances behind this requirement (i.e. it=92s not practical to =
*not* allow strict adherence), which I might also assume as a reader.

3. Requirement 3.18 uses the phrase =93necessary degree of assurance=94 =
regarding validity of certain data, and I don=92t know what that is =
really saying.  Is this really a statement of integrity and authenticity =
or something else?  What is the gradient of assurance and how do we know =
when we=92ve reached that =93necessary degree=94?

4. In the Security Considerations section (6) it seems that more =
explanation pertaining to the following sentence might be warranted: =
=93The data plane might not follow the control plane.=94  This might be =
readily apparent to anyone in-the-know, but it=92s not so apparent to =
those not-in-the-know.


Regards,

Adam



--Apple-Mail=_E335DD80-1BA7-4BF6-A7C3-9A51961A8E25
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

iQEcBAEBCgAGBQJTsXqbAAoJELhc5c4zaVWHRjcIALAifpEb7IsbFNWWy9hALHOl
5OjU3/JNzDorWhVUfoMJPX+KUblt9DxHVlgjLv4m2yVC9MFiTcLjgHigtzg7ycyf
mTng3buXxzm8y2R1PSymUCOGi9HCrJFivmrJvVBDBItDIp5dg8iiBr6a1zgBbtNB
l0mVq+CLDXrNQiSlFGz2REjPVqyWeMG4eZUlokruR+Rs7Fj9ewIR/hSZHI7o2P9e
QY0t9to55aL+iPqJm3vkIIbxVHpldYk+XoB+bae+VvGgYrkZQfwqRxvX/CKDqsw5
k8nZwfPVwSVVynfzrfOotmTz85xaa1K6Pa9ysQ67Y2KpzHa181eYgqvRvNSa0+0=
=W1ze
-----END PGP SIGNATURE-----

--Apple-Mail=_E335DD80-1BA7-4BF6-A7C3-9A51961A8E25--


From nobody Mon Jun 30 09:29:08 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA741A03B0 for ; Mon, 30 Jun 2014 09:29:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5RGgcCnPQB5 for ; Mon, 30 Jun 2014 09:28:58 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 580441A03A1 for ; Mon, 30 Jun 2014 09:28:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BE6C0BE39 for ; Mon, 30 Jun 2014 17:28:57 +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 WYgWiRZmE4Nl for ; Mon, 30 Jun 2014 17:28:57 +0100 (IST)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A1F73BE24 for ; Mon, 30 Jun 2014 17:28:57 +0100 (IST)
Message-ID: <53B19049.3000105@cs.tcd.ie>
Date: Mon, 30 Jun 2014 17:28:57 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "secdir@ietf.org" 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/T78gZKYZG6PFL6pm-2bzo8393MA
Subject: [secdir] secdir lunch location for IETF-90
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Jun 2014 16:29:02 -0000

Hiya,

Usual secdir lunch fun this time will be at:

Assigned Room: Confederation 3
Assigned Date: 07/22/2014

Cheers,
S.


From nobody Mon Jun 30 09:42:30 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89ABB1A03BC; Mon, 30 Jun 2014 09:42:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level: 
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDHhn_pOJVtY; Mon, 30 Jun 2014 09:42:26 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80A021A0397; Mon, 30 Jun 2014 09:42:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6128; q=dns/txt; s=iport; t=1404146546; x=1405356146; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=43yeDQ6uDvovRbtzUBrCnxyDw/hgzRKDbL1CXMS0OnY=; b=VR5TheC5/OQPgQR1oxqT+RR1a9frdtgCRiz5Ea6w9YB0MMnYZkmyaWTQ SuRZOuHyudxNDjglJHk8fdKE7g9+HVTM36JSsFAVIkuJamzaQteZN5XPV ZPYcI8OC1w/P/oPf4T6CkyZ/ir5vwU4d4QcQnJjd4BOanUtnx+PXi9Av2 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjYHALiSsVOtJV2c/2dsb2JhbABagw2BLKsZAQEBAQEBBQFuAZlGAYEOFnWEAwEBAQMBDg9IFAULAgEIRiERJQIEDgWILgMJCMEcDYZSF4Vkg2iDFIF0MweDLYEWAQSKDY5TgX6Na4YSg0KBbiIg
X-IronPort-AV: E=Sophos;i="5.01,576,1400025600"; d="scan'208";a="57118567"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-1.cisco.com with ESMTP; 30 Jun 2014 16:42:25 +0000
Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s5UGgPtI004322 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Jun 2014 16:42:25 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.80]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Mon, 30 Jun 2014 11:42:25 -0500
From: "Carlos Pignataro (cpignata)" 
To: Chris Lonvick 
Thread-Topic: SECDIR draft-secretaries-good-practices.06.txt
Thread-Index: AQHPjmw7xagMpwpCCE6l9c8WzBkTXZuKO4oA
Date: Mon, 30 Jun 2014 16:42:25 +0000
Message-ID: <264A8ABD-CA61-48A0-8A72-7045DA768AB4@cisco.com>
References: <53A75D6E.3020502@gmail.com>
In-Reply-To: <53A75D6E.3020502@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [64.102.157.229]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/yOfTmy1fyXPjczFEBIQ5HOgmT7U
Cc: "draft-secretaries-good-practices.all@tools.ietf.org" , The IESG , "secdir@ietf.org" 
Subject: Re: [secdir] SECDIR draft-secretaries-good-practices.06.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Jun 2014 16:42:28 -0000

Thank you very much, Chris!

Carlos.

On Jun 22, 2014, at 6:49 PM, Chris Lonvick  wrote:

> Hi,
> I have reviewed this document as part of the security directorate's=20
> ongoing effort to review all IETF documents being processed by the=20
> IESG.  These comments were written primarily for the benefit of the=20
> security area directors.  Document editors and WG chairs should treat=20
> these comments just like any other last call comments.
>=20
> Overall the document appears to be well written and thorough.  I=20
> have one security related suggestion and some nits.
>=20
> It appears that this document suggests that some Secretaries should=20
> be given access to tools that are normally reserved for Chairs, such
> as maillist administration.  It would be prudent to note in the
> Security Considerations section that the Chairs know how to revoke=20
> those privileges in case of problems.
>=20
> The authors may wish to consider the following nits. =20
>=20
> The third line of the first paragraph of the Introduction is a bit confus=
ing.
> current:
>    of RFC 2418 [1]). Over time, the WG Secretary role's has greatly
> suggested:
>    of RFC 2418 [1]).  Over time, the role of the WG Secretary has greatly
>=20
> The last sentence of the second paragraph of the Introduction seems to ru=
n on for a bit.
> current:
>    In that regard, part or even all of the guidelines it
>    provides might not be relevant for the smaller WGs, the Chairs of
>    which do not need to delegate operational tasks as they handle them
>    by themselves.
> suggested:
>    In that regard, part or even all of the guidelines provided in this
>    document might not be relevant for the successful operation of
>    smaller WGs.  In those, the Chairs may not need to delegate=20
>    operations tasks.
>=20
> The last two sentences of second bullet in Section 3.1.1 could use some m=
ore explanation.
> current:
>    The call for discussion slots
>    should remind these policies as well as how should the requests be
>    formulated, together with a deadline for sending them.  The call would
>    also typically include information on when will the particular WG
>    session be held during the IETF meeting noting that the IETF agenda
>    is draft until being final.
> proposed:
>    The note sent by the Secretary should remind the WG members of the
>    policies, the formats of requests, and deadlines. =20
> Note: I would just strike the last sentence as that seems to be better di=
scussed in the=20
> next bullet.
>   =20
> I'll suggest some rewording of "Proposing a WG session agenda"
> current:
>    Based on the collected discussion's slot requests, and depending on
>    the known preferences of the WG Chairs for the typical structure of
>    their WG sessions, or on the objectives Chairs have for a particular
>    WG session, and/or on his/her personal view, the Secretary could
>    propose to the Chairs a structured agenda for the upcoming WG
>    session. Following that, the WG Secretary could work with the Chairs
>    to finalise the agenda in view of publishing a first draft agenda.
> proposed:
>    While the decisions for the slot are to be made by the WG Chairs,
>    the Secretary can further aid them by proposing a session agenda
>    based upon his/her knowledge of the preference of the Chairs and
>    the topical work of the WG.  Following that, the WG Secretary could=20
>    work with the Chairs to finalize the agenda.
>   =20
> I'll suggest some rewording of the third paragraph in Section 4.
> current:
>    Although typically a WG might only have one Secretary there is no
>    reason why two Secretaries might not be appointed. This might be to
>    help transition a new WG secretary into the role, before the previous
>    Secretary steps down, or simply to load balance the tasks across two
>    Secretaries. Reciprocally, a person may perfectly be Secretary of
>    multiple WGs. This primarily depends on his/her ability to deal with
>    the induced workload, noting nevertheless that synergies may be
>    realised in such a situation. In any case, this document does not
>    give a recommendation on what should be the appropriate value for the
>    "Secretary / WG" ratio.
> proposed:
>    Typically a WG may have a Secretary to cover the expected workload.
>    However, a WG may consider having multiple Secretaries if the=20
>    workload is very excessive, or to provide an overlap of Secretaries=20
>    to transition the role as one steps down.  There may also be other
>    reasons for multiple Secretaries that have not been recognized yet.
>=20
>    Similar to individuals holding Chair roles in multiple WGs, there is
>    no known reason why individuals cannot hold Secretary roles in
>    multiple WGs, or that they may be a Chair of some WGs and Secretary of
>    other WGs.  This will depend on his/her ability to deal with the
>    workload, noting  that synergies may be realized in such situations.
>   =20
> A couple of minor things in the first paragraph of Section 5
> current:
>    Section 3 has listed the typical functions and responsibilities of WG
>    Secretaries. The role of a WG Secretary can range from a few of these
>    to the full spectrum of them, and even beyond. In that regard, there
>    is a number of additional WG related events to which the support of
>    the WG Secretary would be useful. Those for example include planning
>    and setting for WG interim meetings, design team meetings, etc.
>    Nevertheless, some tasks described herein apply to these contexts.
> proposed:
>    Section 3 has listed the typical functions and responsibilities of WG
>    Secretaries. The role of a WG Secretary can range from a few of these
>    to the full spectrum of them, and even beyond. In that regard, there
>    may be additional WG related events to which the support of
>    the WG Secretary would be useful; for example, planning WG interim=20
>    meetings.
>=20
> Best regards,
> Chris


From nobody Mon Jun 30 13:57:20 2014
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 698BD1A0A9C for ; Mon, 30 Jun 2014 13:57:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.751
X-Spam-Level: 
X-Spam-Status: No, score=-0.751 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=unavailable
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 D3-xhQOzFzU3 for ; Mon, 30 Jun 2014 13:57:15 -0700 (PDT)
Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:228]) by ietfa.amsl.com (Postfix) with ESMTP id 3205E1A0452 for ; Mon, 30 Jun 2014 13:57:15 -0700 (PDT)
Received: from omta12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by qmta15.emeryville.ca.mail.comcast.net with comcast id LknY1o0080x6nqcAFkxFcc; Mon, 30 Jun 2014 20:57:15 +0000
Received: from [192.168.1.181] ([184.39.6.21]) by omta12.emeryville.ca.mail.comcast.net with comcast id Lkwx1o00Q0TCz8g8Ykx0mF; Mon, 30 Jun 2014 20:57:12 +0000
From: David Harrington 
Content-Type: multipart/alternative; boundary="Apple-Mail=_59D99498-7C22-430A-AEFE-8ED10BF35B8E"
Date: Mon, 30 Jun 2014 16:56:56 -0400
To: "iesg@ietf.org IESG" , secdir@ietf.org, draft-ietf-ppsp-peer-protocol.all@tools.ietf.org
Message-Id: <78982690-9233-4763-9FA2-0904BD683BBF@comcast.net>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
X-Mailer: Apple Mail (2.1878.2)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1404161835; bh=Qz9hPodZywhgN8kgCSgX5Iaj8/igop8f2HNLBUP5QRo=; h=Received:Received:From:Content-Type:Date:Subject:To:Message-Id: Mime-Version; b=Ciz5noTCg3hnRAjDvObIJfiyDDkHiAzqPpbXH1Ccl+MPzFljuX7h0jSwxlmqRe51c N50c9GIzLMG6+4Ztjg09b9oHrW22gSU2Tn2k9SdeWPXY/ufH34BAd3CjS+ZJjynETp i23qQ4Bx/HpeftGCbWLNFQ/NXcP/IX1u6M5QYNwv/53QHmTUDOvDtS6lDY7DuOA0Fw BePcECRLSawGfXNcOi3neVNLMs0u9tp3SIgicX/kdVuBy9X/dPSqie+ocPBxIQN0jL QoHSXMlLIFCSDa5D8rLb0puHVcKHMBOQmOcjtNwNcPvJg4ZRMOjWuN7DBXtSShZjYJ PBJlQo5hw4cpA==
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/joYFFJlUnKBwyA3t9KOmo6A6gYs
Subject: [secdir] secdir review of draft-ietf-ppsp-peer-protocol
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Jun 2014 20:57:17 -0000

--Apple-Mail=_59D99498-7C22-430A-AEFE-8ED10BF35B8E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I have reviewed this document as part of the security directorate's=20
ongoing effort to review all IETF documents being processed by the=20
IESG.  These comments were written primarily for the benefit of the=20
security area directors.  Document editors and WG chairs should treat=20
these comments just like any other last call comments.
Summary: I think this document is far from ready for publication as a =
standard., or for last-call reviews. The WG has review work to do before =
this document is ready for expert review.
I gave up reviewing this document after 10 pages, because it was so not =
ready for review.

I will say that, being both an opsdir and secdir reviewer, I was greatly =
encouraged by the table of contents, which shows that a lot of =
consideration was given to security and ops and mgmt. But then I started =
reading the text in the main part of the document, and was severely =
disappointed by what I found.
I chose to sample sections of the document to see if maybe it was just =
the opening text that was problematic. I don=92t think so.

1)  Editorial: in the terminology section, it says
   content integrity protection scheme
       Scheme for protecting the integrity of the content while it is
       being distributed via the peer-to-peer network.  I.e. methods for
       receiving peers to detect whether a requested chunk has been
       maliciously modified by the sending peer.
I do not believe this protocol can detect intent, so to claim that it =
can detect whether a chunk has been maliciously modified is inaccurate. =
It can tell if a chunk has been modified.

2) Technical: in the definition  of swarm ID, there is a conditional =
that applies to VOD. It is ambiguous whether it also applies to live =
streaming. I recommend this wording be modified to make it clearer.
If Merkle trees are not used for integrity protection, what is the swarm =
ID for VOD?

3) Ed: s/as it source/as its source/

4) Ed: " This message conveys protocol options, in particular, peer A =
includes
   the ID of the swarm as the destination peers can listen for multiple
   swarms on the same transport address.=94
I couldn=92t parse this sentence; is it missing punctuation?
I recommend rewording for clarity.

5) Ed: "denotes what chunks of the content peer B, resp. C have.=94
I don=92t know what word =93resp.=94 is abbreviating.
Substituting words that start with resp, (e.g., response, respectively, =
etc.) I cannot make sense of this sentence.

6) tech: I feel uncomfortable with section 2 containing examples that =
describe the overall flow. Examples are non-normative text, usually =
contained in a non-normative appendix. These examples describe the order =
of messages, and it is=20

7) in example 2.2, the integrity hash is provided by the peer that is =
providing the (potentially maliciously modified) content. Isn=92t that =
like asking the fox to verify that the henhouse is safe?

8) in 3, paragraph 1, it says =93In general,=94 which seems less =
specific than normally expected of standards language.

9) in 3, paragraph 1, it says =93this behavior=94, but I=92m not sure =
which behavior it is referencing. It is unclear whether not sending =
error messages, or discarding messages, or stopping communication, or =
classifying peers is the behavior that allows a peer to deal with slow, =
crashed, or silent peers. I don=92t understand HOW any of the behaviors =
mentioned would allow a peer to deal with slow, crashed, or silent =
peers. I do not understand on what basis peers are judged =93good=94 or =
=93bad=94.

10) in 3, paragraph 2, it says, "Multiple messages are multiplexed into =
a single datagram for
   transmission.  Messages in a single datagram MUST be processed in the
   strict order in which they appear in the datagram.=94 While this =
might be true for UDP, is this also accurate for TCP or other =
non-datagram transports?=20
This is not written using RFC2119 keywords; should =93are=94 be =93MUST =
be=94 or =93SHOULD be=94 or =93MAY be=94?

11) in 3, paragraph 3, the second sentence seems to contradict the first =
sentence, and since neither is written using RFC2119 keywords, it seems =
to really leave the whole question open to implementer interpretation.

[jumping forward to sample other places in the document]

12) section 8 is ambiguous:
"8.  UDP Encapsulation

   PPSPP implementations MUST use UDP as transport protocol and MUST use
   LEDBAT for congestion control [RFC6817].  Using LEDBAT enables PPSPP
   to serve the content after playback (seeding) without disrupting the
   user who may have moved to different tasks that use its network
   connection.  Future PPSPP versions can also run over other transport
   protocols, or use different congestion control algorithms.
=93
I find =93MUST use UDP=94 inconsistent with =93=94can also run over =
other transport protocols=94, and =93MUST use LEDBAT=94 inconsistent =
with =93or use different congestion control protocols=94.

[jumping ahead =85]
In 8.3, there is a discussion of multiple swarms sharing a UDP port. I=92m=
 unsure whether this would work, but since UDP is stateless, it might. =
Do channels work for protocols like TCP?=20

[jumping ahead =85]=20

"A SIGNED_INTEGRITY message (type 0x07) consists of a chunk
   specification, a 64-bit NTP timestamp [RFC5905] and a digital
   signature encoded as a Signature field in a RRSIG record in DNSSEC
   without the BASE-64 encoding [RFC4034].=94
Can this work in an implementation with no NTP support?

[juming ahead =85]
8.14 describes a keep alive message format, but no processing =
instructions.
Are receiving implementations required to do anything with this message? =
are they supposed to respond somehow?
How does the sender of a keep alive determine that the connection is =
still live?
There is no message type for keep alive. If the first octet of the keep =
alive happens to be 0x0a, how does the receiver know whether this is a =
keep alive or a CHOKE message?

Table 7 defines the messages types in decimal. But the text uses hex =
values.=20


=97
At this point, I will observe that I think this document is far from =
ready for publication as a standard.=20

The WG, and the chairs and shepherd, really need to look at this =
document closely to ensure the English is clear and unambiguous, that =
RFC2119 keywords are used to specify the behaviors expected from =
implementers.

I think this document would be well served by describing the message =
types and formats and their processing in a transport-neutral manner, =
and then describing the transport-specific mapping details, so it is =
clear and unambiguous how the mapping of message sequences to datagrams =
is handled for UDP and DCCP, and how the mapping of message sequences =
should be handled for stream-based protocols like TCP. There are some =
message types, notably keep alive, that I am not sure apply in the same =
way to different transports.

Multiple messages are multiplexed in a datagram. How are the messages =
delimited? If there is any corruption in one message, how does the =
receiver find the end of the message and the start of the next message? =
If I understand correctly, invalid messages are discarded and no error =
code is sent. If one of the messages are found to be invalid, are all =
messages in that datagram discarded? or are all subsequent messages in =
that datagram discarded? or is it valid to process the remaining =
messages in the datagram after an invalid message is detected? If so, =
would that conflict with the rule that all messages must be processed in =
order?

How will messages be limited in stream-based transports? if 1000 =
messages are sent in a streaming protocol, and number 3 is invalid, what =
happens to the remaining stream of 997 messages?

Dave Harrington
ietfdbh@comcast.net






--Apple-Mail=_59D99498-7C22-430A-AEFE-8ED10BF35B8E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


I have reviewed this =
document as part of the security directorate's=20
ongoing effort to review all IETF documents being processed by the=20
IESG.  These comments were written primarily for the benefit of the=20
security area directors.  Document editors and WG chairs should treat=20
these comments just like any other last call comments.
Summary: I think this document is far from ready for publication as a =
standard., or for last-call reviews. The WG has review work to do before =
this document is ready for expert review.
I gave up =
reviewing this document after 10 pages, because it was so not ready for =
review.

I will say that, being =
both an opsdir and secdir reviewer, I was greatly encouraged by the =
table of contents, which shows that a lot of consideration was given to =
security and ops and mgmt. But then I started reading the text =
in the main part of the document, and was severely disappointed by what =
I found.
I chose to sample sections of the document to see if maybe =
it was just the opening text that was problematic. I don=92t think =
so.

1) =
 Editorial: in the terminology section, it =
says
   content integrity protection =
scheme
       Scheme for protecting the integrity of the content while it is
       being distributed via the peer-to-peer network.  I.e. methods for
       receiving peers to detect whether a requested chunk has been
       maliciously modified by the sending peer.
I do not believe this protocol can detect =
intent, so to claim that it can detect whether a chunk has been =
maliciously modified is inaccurate. It can tell if a chunk has been =
modified.

2) Technical: in the definition  of swarm ID, there is a =
conditional that applies to VOD. It is ambiguous whether it also applies =
to live streaming. I recommend this wording be modified to make it =
clearer.
If Merkle =
trees are not used for integrity protection, what is the swarm ID for =
VOD?

3) Ed: =
s/as it =
source/as its source/

4) Ed: "   This message conveys protocol options, in =
particular, peer A includes
   the ID =
of the swarm as the destination peers can listen for multiple
   swarms on the same transport address.=94
I couldn=92t parse this sentence; is it missing =
punctuation?
I recommend rewording for =
clarity.

5) Ed: "denotes what chunks of the content peer B, resp. C =
have.=94
I don=92t know what word =93resp.=94 is =
abbreviating.
Substituting words that start with resp, (e.g., response, =
respectively, etc.) I cannot make sense of this =
sentence.

6) tech: I feel uncomfortable with section 2 containing examples =
that describe the overall flow. Examples are non-normative text, usually =
contained in a non-normative appendix. These examples describe the order =
of messages, and it is 

7) in example =
2.2, the integrity hash is provided by the peer that is providing the =
(potentially maliciously modified) content. Isn=92t that like asking the =
fox to verify that the henhouse is safe?

8) in 3, paragraph 1, it says =93In =
general,=94 which seems less specific than normally expected of =
standards language.

9) in 3, paragraph 1, it says =93this behavior=94, but =
I=92m not sure which behavior it is referencing. It is unclear whether =
not sending error messages, or discarding messages, or stopping =
communication, or classifying peers is the behavior that allows a peer =
to deal with slow, crashed, or silent peers. I don=92t understand HOW =
any of the behaviors mentioned would allow a peer to deal with slow, =
crashed, or silent peers. I do not understand on what basis peers are =
judged =93good=94 or =93bad=94.

10) in 3, paragraph 2, it says, "Multiple messages are =
multiplexed into a single datagram for
   transmission.  Messages in a single datagram MUST =
be processed in the
   strict order in which they appear in the datagram.=94 While this =
might be true for UDP, is this also accurate for TCP or other =
non-datagram transports? 
This is not =
written using RFC2119 keywords; should =93are=94 be =93MUST be=94 or =
=93SHOULD be=94 or =93MAY be=94?

11) in 3, paragraph 3, the second sentence seems to =
contradict the first sentence, and since neither is written using =
RFC2119 keywords, it seems to really leave the whole question open to =
implementer interpretation.

[jumping forward to sample other places in the =
document]

12) =
section 8 is ambiguous:
"8.  UDP =
Encapsulation

   PPSPP implementations MUST use UDP as transport protocol and MUST use
   LEDBAT for congestion control [RFC6817].  Using LEDBAT enables PPSPP
   to serve the content after playback (seeding) without disrupting the
   user who may have moved to different tasks that use its network
   connection.  Future PPSPP versions can also run over other transport
   protocols, or use different congestion control =
algorithms.
=93
I find =93MUST use UDP=94 =
inconsistent with =93=94can also run over other transport protocols=94, =
and =93MUST use LEDBAT=94 inconsistent with =93or use different =
congestion control protocols=94.

[jumping ahead =
=85]
In 8.3, there is a discussion of multiple swarms sharing =
a UDP port. I=92m unsure whether this would work, but since UDP is =
stateless, it might. Do channels work for protocols like TCP? =


[jumping ahead =85] =


"A =
SIGNED_INTEGRITY message (type 0x07) consists of a chunk
   specification, a 64-bit NTP timestamp [RFC5905] and a digital
   signature encoded as a Signature field in a RRSIG record in DNSSEC
   without the BASE-64 encoding [RFC4034].=94
Can =
this work in an implementation with no NTP support?

[juming ahead =85]
8.14 describes a keep alive =
message format, but no processing instructions.
Are =
receiving implementations required to do anything with this message? are =
they supposed to respond somehow?
How does the sender of a keep =
alive determine that the connection is still live?
There =
is no message type for keep alive. If the first octet of the keep alive =
happens to be 0x0a, how does the receiver know whether this is a keep =
alive or a CHOKE message?

Table 7 defines the =
messages types in decimal. But the text uses hex values. 


=97
At this point, I will observe that I think this =
document is far from ready for publication as a =
standard. 

The WG, =
and the chairs and shepherd, really need to look at this document =
closely to ensure the English is clear and unambiguous, that RFC2119 =
keywords are used to specify the behaviors expected from =
implementers.

I think =
this document would be well served by describing the message types and =
formats and their processing in a transport-neutral manner, and then =
describing the transport-specific mapping details, so it is clear and =
unambiguous how the mapping of message sequences to datagrams is handled =
for UDP and DCCP, and how the mapping of message sequences should be =
handled for stream-based protocols like TCP. There are some message =
types, notably keep alive, that I am not sure apply in the same way to =
different transports.

Multiple messages are multiplexed in a datagram. How =
are the messages delimited? If there is any corruption in one message, =
how does the receiver find the end of the message and the start of the =
next message? If I understand correctly, invalid messages are discarded =
and no error code is sent. If one of the messages are found to be =
invalid, are all messages in that datagram discarded? or are all =
subsequent messages in that datagram discarded? or is it valid to =
process the remaining messages in the datagram after an invalid message =
is detected? If so, would that conflict with the rule that all messages =
must be processed in order?

How will messages be limited in stream-based =
transports? if 1000 messages are sent in a streaming protocol, and =
number 3 is invalid, what happens to the remaining stream of 997 =
messages?

Dave =
Harrington
ietfdbh@comcast.net





=

--Apple-Mail=_59D99498-7C22-430A-AEFE-8ED10BF35B8E--