From weiler@watson.org Tue Oct 4 14:33:38 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 304CB21F8E2B for ; Tue, 4 Oct 2011 14:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.57 X-Spam-Level: X-Spam-Status: No, score=-1.57 tagged_above=-999 required=5 tests=[AWL=-0.830, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+JDyM6gX0GI for ; Tue, 4 Oct 2011 14:33:37 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 25CC121F8E27 for ; Tue, 4 Oct 2011 14:33:36 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id p94LagPR060637 for ; Tue, 4 Oct 2011 17:36:42 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p94LafU6060629 for ; Tue, 4 Oct 2011 17:36:42 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 4 Oct 2011 17:36:41 -0400 (EDT) From: Samuel Weiler To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Tue, 04 Oct 2011 17:36:42 -0400 (EDT) Subject: [secdir] Secdir assignments on hiatus X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 21:33:38 -0000 Some of you have noticed that there have net been secdir assignments in over a month. Indeed, you have not been overlooking the emails -- there have not been any. The tools.ietf.org server that hosts the assignment tool crashed in early September, and the tool is not yet back up and running, nor have I reconstructed the data to switch back to manual assignments. I am not sure when the usual review schedule will resume; hopefully within another week or two. -- Sam Weiler From kivinen@iki.fi Thu Oct 6 05:34:54 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8289521F8C5F for ; Thu, 6 Oct 2011 05:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.839 X-Spam-Level: X-Spam-Status: No, score=-101.839 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E67NCk13xK9q for ; Thu, 6 Oct 2011 05:34:54 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1FC921F8C2F for ; Thu, 6 Oct 2011 05:34:52 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p96Cbx4W002410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Oct 2011 15:37:59 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p96CbuO7007983; Thu, 6 Oct 2011 15:37:56 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20109.41252.618359.548136@fireball.kivinen.iki.fi> Date: Thu, 6 Oct 2011 15:37:56 +0300 From: Tero Kivinen To: secdir-secretary@mit.edu In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 1 min Cc: secdir@ietf.org Subject: [secdir] Secdir assignments on hiatus X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 12:34:54 -0000 Samuel Weiler writes: > Some of you have noticed that there have net been secdir assignments > in over a month. Indeed, you have not been overlooking the emails -- > there have not been any. > > The tools.ietf.org server that hosts the assignment tool crashed in > early September, and the tool is not yet back up and running, nor have > I reconstructed the data to switch back to manual assignments. I am > not sure when the usual review schedule will resume; hopefully within > another week or two. It seems we have the databases copied out from the crashed machine, and they are already in place in the new server, but there are still some permission problems which needs to be fixed before the review tool works again. Hopefully those problems will be fixed in day or two, not in week or two... :-) -- kivinen@iki.fi From weiler+secdir@watson.org Mon Oct 10 10:42:27 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB0121F8C6E for ; Mon, 10 Oct 2011 10:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-MTPwz+0kEV for ; Mon, 10 Oct 2011 10:42:26 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 9A63921F8C54 for ; Mon, 10 Oct 2011 10:42:26 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id p9AHgPaq008237 for ; Mon, 10 Oct 2011 13:42:25 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p9AHgO7F008226 for ; Mon, 10 Oct 2011 13:42:25 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 10 Oct 2011 13:42:24 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Mon, 10 Oct 2011 13:42:25 -0400 (EDT) Subject: [secdir] Assignments (finally!) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 17:42:27 -0000 Almost everything on this list is newly assigned. About half of us have a new assignment, some on the next telechat. Please check the lists carefully. Dashes (-) in the last call date field typcially indicate that IETF LC has already ended. Apologies for not getting these out for so long. As a reminder, we normally ask for reviews by the end of IETF LC and, in any case no later than the FRIDAY before the telechat. With the delay in getting these out, I'm sure our ADs will be understanding, but doc editors do appreciate having comments within the last call window rather than just before telechat. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Leif Johansson is next in the rotation. For telechat 2011-10-20 Reviewer LC end Draft Uri Blumenthal T 2011-10-18 draft-ietf-mpls-tp-li-lb-07 Dave Cridland T - draft-ietf-nfsv4-federated-fs-dns-srv-namespace-09 Shawn Emery T - draft-ietf-sidr-ghostbusters-14 Steve Hanna TR2011-06-09 draft-ietf-dnsext-rfc2672bis-dname-24 Sam Hartman T 2011-10-12 draft-melnikov-mmhs-header-fields-04 Sam Weiler T 2011-10-12 draft-ietf-grow-no-more-unallocated-slash8s-03 Brian Weis T - draft-ietf-appsawg-rfc3462bis-01 Klaas Wierenga T - draft-ietf-ccamp-attribute-bnf-02 Nico Williams T 2011-10-11 draft-ietf-ccamp-wson-impairments-07 For telechat 2011-11-03 Reviewer LC end Draft Alan DeKok T - draft-ietf-pim-port-08 Tobias Gondrom T 2011-10-18 draft-ietf-tls-dtls-heartbeat-03 Love Hornquist-Astrand T 2011-10-31 draft-salter-rfc5430bis-01 Jeffrey Hutzelman T 2011-10-24 draft-sprecher-mpls-tp-oam-considerations-01 Matt Lepinski T 2011-08-16 draft-ietf-ospf-auth-trailer-ospfv3-07 Last calls and special requests: Reviewer LC end Draft Derek Atkins 2011-10-20 draft-ietf-eai-rfc5336bis-14 Rob Austein 2011-10-20 draft-ietf-eai-rfc5337bis-dsn-04 Richard Barnes 2011-10-24 draft-ietf-ippm-metrictest-03 Donald Eastlake - draft-ietf-savi-framework-05 Phillip Hallam-Baker - draft-irtf-hiprg-dht-04 Steve Hanna 2011-10-20 draft-ietf-vcarddav-kind-app-00 Dan Harkins 2011-10-20 draft-jdfalk-maawg-cfblbcp-02 Paul Hoffman 2011-10-21 draft-oreirdan-mody-bot-remediation-16 Catherine Meadows R2011-04-13 draft-ietf-speechsc-mrcpv2-25 Tina TSOU 2011-04-23 draft-shin-augmented-pake-08 Carl Wallace 2011-11-07 draft-davis-t-langtag-ext-06 Tom Yu 2011-10-19 draft-ietf-codec-guidelines-05 Larry Zhu 2011-10-13 draft-ietf-cuss-sip-uui-reqs-06 Glen Zorn 2011-10-20 draft-ietf-eai-rfc5335bis-12 From shanna@juniper.net Mon Oct 10 11:26:53 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F45421F8C3D for ; Mon, 10 Oct 2011 11:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5omt7YzWdNo for ; Mon, 10 Oct 2011 11:26:52 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 99C9921F8C32 for ; Mon, 10 Oct 2011 11:26:48 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP; Mon, 10 Oct 2011 11:26:48 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.83.0; Mon, 10 Oct 2011 11:24:37 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 10 Oct 2011 14:24:36 -0400 From: Stephen Hanna To: "secdir@ietf.org" , "draft-ietf-dnsext-rfc2672bis-dname@tools.ietf.org" Date: Mon, 10 Oct 2011 14:24:35 -0400 Thread-Topic: secdir re-review of draft-ietf-dnsext-rfc2672bis-dname-24.txt Thread-Index: Acwgh9s80YeQfWrkRySR5CC9/YhwJhm8X62g Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] secdir re-review of draft-ietf-dnsext-rfc2672bis-dname-24.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 18:26:53 -0000 I was asked to review the changes made to this document in the last few months. I have done so. None of the changes have any apparent security impact. Some text was clarified and examples were added. Therefore, my previous analysis still applies. I do not see any security issues that are not well covered in this document. While I don't think this document will close any major security issues, it includes some helpful guidance. So I recommend that this document advance to RFC status. Thanks, Steve > -----Original Message----- > From: Stephen Hanna > Sent: Wednesday, June 01, 2011 2:15 PM > To: 'secdir@ietf.org'; 'draft-ietf-dnsext-rfc2672bis- > dname@tools.ietf.org' > Cc: 'ietf@ietf.org' > Subject: secdir review of draft-ietf-dnsext-rfc2672bis-dname-22.txt >=20 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 > This document intends to replace RFC 2672, the definition of DNAME > redirection in the DNS. DNAME is a DNS resource record type that > (in layman's terms) indicates that all domain names ending in a > specified suffix should be redirected to domain names where the > suffix is replaced by a specified value. For example, all names > that end with example.com should be remapped to example.net. >=20 > The document is quite thorough, apparently because the DNAME RR > has been used for many years and a great deal of real-world > experience has been gained. That's definitely a good thing! >=20 > From a security perspective, this document includes a more > thorough analysis of security considerations than the original > RFC 2672. It also includes a more thorough discussion of DNSSEC > interactions than the earlier document. >=20 > I do not see any security issues that are not well covered in > this document. While I don't think this document will close any > major security issues, it includes some helpful guidance. So > I recommend that this document advance to RFC status. >=20 > Thanks, >=20 > Steve From new-work-bounces@ietf.org Tue Sep 27 14:21:24 2011 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB4E21F9036; Tue, 27 Sep 2011 14:21:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1317158482; bh=cQMFZ5a6s2ApRLUkd/QxuJllhjPfxmNulr4VGxdp0Vs=; h=From:To:Mime-Version: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=xqdPKz00Hb79pBWKd+wWCeUUPcqjQGWJTeWqpb9eSny1pb+VgZMGqFpqg7KXUZsfL kobJc1871YdO45uNJb5cS8TAUsBKhfZgU7wYiewBkt1mwbBCt1yGNLipb3EMcG03U/ z3oMps/oIwiGOvrZWA6VbI1iPmpFMi3zK8dWXtek= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 947FA21F9036; Tue, 27 Sep 2011 14:21:16 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20110927212116.947FA21F9036@ietfa.amsl.com> Date: Tue, 27 Sep 2011 14:21:16 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Tue, 11 Oct 2011 09:45:08 -0700 Subject: [secdir] [new-work] WG Review: Reputation Services (repute) 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: Tue, 27 Sep 2011 21:21:24 -0000 A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, October 4, 2011. Reputation Services (repute) ----------------------------------------- Status: Proposed Working Group Last Updated: 2011-09-13 Chair(s): TBD Applications Area Director(s): Pete Resnick (presnick@qualcomm.com) Peter Saint-Andre (stpeter@stpeter.im) Applications Area Advisor: Pete Resnick (presnick@qualcomm.co) Mailing Lists: General Discussion: repute@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/repute Archive: http://www.ietf.org/mail-archive/web/repute/ Description of Working Group: In the open Internet, making a meaningful choice about the handling of content requires an assessment of its safety or "trustworthiness". This is based on a trust metric for the owner (identity) of an identifier associated with the content, to distinguish (likely) good actors from bad actors. The generic term for such information is "reputation". This working group will develop mechanisms for reputation reporting by independent services. One mechanism will be for a basic assessment of trustworthiness. Another will provide a range of attribute/value data that is used as input to such an assessment. Each service determines the attributes it reports. Various mechanisms have been developed for associating a verified identifier with email content, such as with SPF (RFC4408) and DKIM (RFC4871). An existing reputation query mechanism is Vouch-by-Reference (RFC5518). It provides a simple Boolean response concerning a domain name used for email. The current working group effort will expand upon this, to support additional applications -- such as Web pages and hosts -- and a wider range of reporting information. Given the recent adoption of domain name verification for email, by SPF and DKIM, the most obvious initial use case for reputation is for email. Inbound email filters that perform message authentication can obtain a verified domain name and then consult a reputation service provider to make a determination (perhaps also based on other factors) of whether or not the content is desirable and take appropriate action with respect to delivery, routing or rejection. Another possible use case is identity-based evaluation of web content using technologies such as the DKIM-derived DOSETA (work in progress). This working group will produce specifications for: * the detailed requirements for reporting * an end-to-end system architecture in which reporting occurs * the mechanisms and formats for reporting Two mechanisms are under consideration: * simple -- a reputation is expressed in a simple manner, via records in the DNS (see draft-kucherawy-reputation-query-dns) * extended -- a response can contain more complex information useful to an assessor, reported over HTTP using an encoding such as XML or JSON (see draft-kucherawy-reputation-query-http) The syntactic and semantic aspects of mechanisms and formats will be designed to be application-independent and portable (i.e., reputation provider-independent). By distinguishing reporting information (format) from reporting mechanism (channel), the specifications will permit adaptation to support reporting through additional channels. Limited application-specific tailoring will be provided for email, to demonstrate the approach, which can be applied for supportting additional applications. The design and specification will also permit adaptation to support reporting through additional transport channels. Items that are specifically out of scope for this work: * Specific actions to be taken in response to a reputation reply. It is up to assessors (i.e., the consumers of reputation data) to determine this. Non-normative illustrations, however, can be included to demonstrate possible uses of reputation data in a particular context. * Selection of what data might be valid as the subject of a reputation query. It is up to reputation service providers and assessors to select which qualities of a body of data might be useful input to reputation evaluation. * Concerns about methods of verifying domain names that are used for email reputation. A verified domain name is a starting point for this work; the means by which it was obtained and the "meaning" of the name or its verification are matters for discussion elsewhere. * Algorithms to be applied to aggregated feedback in order to compute reputations. These are part of a back-end system, usually proprietary, and not appropriate for specification as part of a query/reply framework and protocol. The initial draft set: draft-kucherawy-reputation-model draft-kucherawy-reputation-media-type draft-kucherawy-reputation-query-http draft-kucherawy-reputation-query-dns draft-kucherawy-reputation-query-udp draft-kucherawy-reputation-vocab-identity Goals and Milestones: Mar 2012: Informational document, defining the problem space and solution architecture, to the IESG for publication. Mar 2012: Specification for the multi-attribute reporting data structure, to the IESG for publication. May 2012: Informational document, defining the vocabulary for providing reputation in the email sphere, to the IESG for publication. Jul 2012: Specification defining the simple query mechanism, to the IESG for publication. Jul 2012: Specification for the extended query mechanism, to the IESG for publication. Oct 2012: Informational document, discussing issues of data transparency, redress, meta-reputation and other important operational considerations, to the IESG for publication. _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Fri Oct 7 18:25:45 2011 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C1A21F8B9C; Fri, 7 Oct 2011 18:25:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1318037145; bh=4UjXkzgYom9uqGZv/WOnhxHLxXNN9y//0SoCqVTqyyw=; h=From:Date:To:Message-Id:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=ZG7Rwoc+tKBl03zWtN0Zo7JTZoYMfOX5pP0AxbZsa29oZsl0PsewLp1YJpeESH2lK td2WKXKFo+/MNlZ+Q5Qu3/Zhz936P4lbvbIMHvDFwYzgE0iiqI9330P14OigCaLJ/8 2j6vLf2qABLdWMGIsBsnTZSrRZyF3RX6lBvuVha8= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E985921F8B9C for ; Fri, 7 Oct 2011 18:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.167 X-Spam-Level: X-Spam-Status: No, score=-10.167 tagged_above=-999 required=5 tests=[AWL=0.432, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjbRy2GH1LIo for ; Fri, 7 Oct 2011 18:25:43 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 73EEF21F8B8F for ; Fri, 7 Oct 2011 18:25:43 -0700 (PDT) Received: from localhost ([127.0.0.1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1RCLii-0004ct-Qo; Fri, 07 Oct 2011 21:28:56 -0400 From: Ian Jacobs Date: Fri, 7 Oct 2011 20:28:56 -0500 To: new-work@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Tue, 11 Oct 2011 09:45:08 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: SVG Working Group (until 2011-11-04) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2011 01:25:45 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Graphics Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the SVG Working Group: http://www.w3.org/Graphics/SVG/WG/charter/2010/ 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 2011-11-04 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [2], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Doug Schepers, Team Contact . Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/Graphics/ [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs/ Tel: +1 718 260 9447 _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Fri Oct 7 18:37:50 2011 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE4421F8B26; Fri, 7 Oct 2011 18:37:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1318037870; bh=O+ihR0QIcPuMpoYNYeuwZC7jZfntpJZRX+rsgFmHW+I=; h=From:Date:To:Message-Id:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=ac2KWUz39oX/2Xu0/h+AJefcghpL92C6L6gHRSGgmykwfAo+RKQOCO1wmYyl9rTln 6LYGh2w6CVHhlg9RLwA4Ra0ZMWc0bO7KX3BJyHWc8yU6rN9q1WPabgWHI/TPcxRbC7 hEtnUnquRUIw/atAAdONqmWOZGZjlEJs0MsLyyYk= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0539321F8B26 for ; Fri, 7 Oct 2011 18:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.239 X-Spam-Level: X-Spam-Status: No, score=-10.239 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaSwxeSULP+b for ; Fri, 7 Oct 2011 18:37:49 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3C021F861E for ; Fri, 7 Oct 2011 18:37:49 -0700 (PDT) Received: from localhost ([127.0.0.1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1RCLuS-000518-D6; Fri, 07 Oct 2011 21:41:04 -0400 From: Ian Jacobs Date: Fri, 7 Oct 2011 20:41:03 -0500 To: new-work@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Tue, 11 Oct 2011 09:45:08 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: CSS Working Group (until 2011-11-04) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2011 01:37:50 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Style Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the CSS Working Group: http://www.w3.org/2002/09/wbs/33280/css-charter-2011/ 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 2011-11-04 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 Bert Bos, Team Contact . Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/Style/ [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs/ Tel: +1 718 260 9447 _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Tue Oct 11 09:23:45 2011 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE4821F8E01; Tue, 11 Oct 2011 09:23:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1318350225; bh=5Vh6hLSGM9C1UqJQbnOQ7GjI/CTLU9fUJocmcfnaEzo=; h=From:To:Mime-Version: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=TXldp7SItL+MhX0xqr/UJTcs2BRCBuaqXNBiU7JDSBgc3K5jJNsAJKjoOFHpjbHDD JtEn5E+0q+/TqQletSSwY+IM7LTY0ALM03fRRJKN3M2phC4zclQqv4cmrE3AYSWEn3 faMpaV1g5JYsulN8oOj9QIF09huVmXf8bHGzDgVg= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 195EA21F8E03; Tue, 11 Oct 2011 09:23:43 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20111011162343.195EA21F8E03@ietfa.amsl.com> Date: Tue, 11 Oct 2011 09:23:43 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Tue, 11 Oct 2011 09:45:08 -0700 Subject: [secdir] [new-work] WG Review: Binary Floor Control Protocol Bis (bfcpbis) 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: Tue, 11 Oct 2011 16:23:45 -0000 A new IETF working group has been proposed in the Real-time Applications and Infrastructure Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, October 18, 2011. Binary Floor Control Protocol Bis (bfcpbis) ---------------------------- Status: Proposed Working Group Last Updated: 2011-09-20 Chairs: TBD Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Gonzalo Camarillo Mailing Lists: General Discussion: TBD To Subscribe: TBD Archive: TBD The BFCPBIS working group is chartered to specify a revision of BFCP (RFC 4582) to support using both TCP and UDP as transports. The current version of BFCP only supports TCP, which when both endpoints are behind NATs or firewalls, has a lower success rate than using the ICE techniques with a UDP based transport for BFCP. The need for video endpoints to work in these types of environments is driving a strong need to support a UDP based transport as well as TCP. This WG will create a revision of RFC 4582 which adds optional support for UDP to BFCP. The security when using UDP will be based on DTLS. The updated protocol will use an existing approach (e.g., stop and wait with a single outstanding transaction) to provide a reliable, congestion safe, and TCP friendly transport. In addition to providing a way for dealing with the reliable delivery of client-initiated transactions, the updated protocol will also be able to deliver server-initiated transactions reliably when needed. The WG will research the size of messages used and decide if fragmenting a request or response over multiple UDP packets is required. The new protocol will be backwards compatible with RFC 4582 when used in TCP mode. The BFCPBIS WG will coordinate closely with the MMUSIC WG to create a revision of RFC 4583 specifying how BFCP is signaled in SDP so that it supports UDP as well as TCP transports. This WG would ask the MMUSIC WG to add a milestone to create a revisions of RFC 4583 to address signaling the use of UDP in SDP. The WG will coordinate with International Multimedia Telecommunications Consortium (IMTC) and other industry fora. Milestones: April 2012 Draft revision of RFC 4582 to IESG _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Tue Oct 11 09:27:11 2011 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA9A21F8E83; Tue, 11 Oct 2011 09:27:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1318350431; bh=rFKv9CDvZofXNdRtlhw93oA2hgHfpanIILosYoxU9+8=; h=From:To:Mime-Version: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=CNvhAqDN5IrGr1fuEXKOAspgckMdUYWIpE9Dgmsf6emcYVnM0Gv8JEhKqayzPYeZ0 7s9KDOPyBnKDDpeq0/QPpo7CRRo7ebNRsy5gO740jRnJO8WBstH83zK4XLHMp3AZ5k 1RYsrYGFKm6gzejL3lowd5it9clNQElQw8bkSb8k= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 5C3A621F8E7D; Tue, 11 Oct 2011 09:27:09 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20111011162709.5C3A621F8E7D@ietfa.amsl.com> Date: Tue, 11 Oct 2011 09:27:09 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Tue, 11 Oct 2011 09:45:08 -0700 Subject: [secdir] [new-work] WG Review: Managed Incident Lightweight Exchange (mile) 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: Tue, 11 Oct 2011 16:27:11 -0000 A new IETF working group has been proposed in the Security Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, October 18, 2011. Managed Incident Lightweight Exchange (mile) -------------------------------------------- Status: Proposed Working Group Charter Last Updated: 2011-09-21 Chairs: TBD Security Area Directors: Stephen Farrell Sean Turner Security Area Advisor: Sean Turner Mailing Lists: General Discussion: mile@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/mile Archive: http://www.ietf.org/mail-archive/web/mile Description: The Managed Incident Lightweight Exchange (MILE) working group will develop standards and extensions for the purpose of improving incident information sharing and handling capabilities based on the work developed in the IETF Extended INCident Handling (INCH) working group. The Incident Object Description Exchange Format (IODEF) in RFC5070 and Real-time Inter-network Defense (RID) in RFC6045 were developed in the INCH working group by international Computer Security Incident Response Teams (CSIRTs) and industry to meet the needs of a global community interested in sharing, handling, and exchanging incident information. The extensions and guidance created by the MILE working group assists with the daily operations of CSIRTs at an organization, service provider, law enforcement, and at the country level. The application of IODEF and RID to interdomain incident information cooperative exchange and sharing has recently expanded and the need for extensions has become more important. Efforts continue to deploy IODEF and RID, as well as to extend them to support specific use cases covering reporting and mitigation of current threats such as anti-phishing extensions. An incident could be a benign configuration issue, IT incident, an infraction to a service level agreement (SLA), a system compromise, socially engineered phishing attack, or a denial-of-service (DoS) attack, etc. When an incident is detected, the response may include simply filing a report, notification to the source of the incident, a request to a third party for resolution/mitigation, or a request to locate the source. IODEF defines a data representation that provides a standard format for sharing information commonly exchanged about computer security incidents. RID enables the secure exchange of incident related information in an IODEF format providing options for security, privacy, and policy setting. MILE leverages collaboration and sharing experiences with the work developed in the INCH working group which includes the data model detailed in the IODEF, existing extensions to the IODEF for Anti-phishing (RFC5901), and RID (RFC6045, RFC6046) for the secure exchange of information. MILE will also leverage the experience gained in using IODEF and RID in operational contexts. Related work, drafted outside of INCH will also be reviewed and includes RFC5941, Sharing Transaction Fraud Data. The MILE working group provides coordination for these various extension efforts to improve the capabilities for exchanging incident information. MILE has several objectives with the first being a description a subset of IODEF focused on ease of deployment and applicability to current information security data sharing use cases. MILE also describes a generalization of RID for secure exchange of other security-relevant XML formats. MILE produces additional guidance needed for the successful exchange of incident information for new use cases according to policy, security, and privacy requirements. Finally, MILE produces a document template with guidance for defining IODEF extensions to be followed when producing extensions to IODEF as appropriate, for: * labeling incident reports with data protection, data retention, and other policies, regulations, and laws restricting the handling of those reports * referencing structured security information from within incident reports * reporting forensic data generated during an incident investigation (computer or accounting) The WG will produce the following: * An informational document on IODEF Guidance. * A Standards Track document specifying the Real-time Inter-network Defense (RID). * A Standards Track document specifying the transport for RID. * An informational template for extensions to IODEF. * A Standards Track document for IODEF Extensions in IANA XML Registry. * A Standards Track document for IODEF Extension to support structured cybersecurity information. * A Standards Track document for Labeling for data protection, retention, policies, and regulations. * A Standards Track document for GRC Report Exchange. * A Standards Track document for IODEF Extension to support forensics. The drafts under consideration as WG items include: * Real-time Inter-network Defense (RID) bis: draft-moriarty-mile-rfc6045-bis-01 * Transport of Real-time Inter-network Defense (RID) Messages bis: draft-trammell-mile-rfc6046-bis-00 * Template for extensions to IODEF: draft-trammell-mile-template-01.txt * IODEF Extensions in IANA XML Registry: draft-trammell-mile-iodef-xmlreg-00.txt * GRC Report Exchange (Generalized RID for XML reports/documents): draft-moriarty-mile-grc-exchange-00.txt * IODEF-extension to support structured cybersecurity information: draft-takahashi-mile-sci-00.txt Milestones WGLC = Working Group Last Call 2011-11 - WGLC Real-time Inter-network Defense (RID) 2011-11 - WGLC Transport for Real-time Inter-network Defense (RID) 2011-12 - Submit Real-time Inter-network Defense (RID) to IESG for consideration as Standards Track document 2011-12 - Submit Transport Real-time Inter-network Defense (RID) to IESG for consideration as Standards Track document 2011-12 - WGLC Template for extensions to IODEF 2011-12 - WGLC IODEF Extensions in IANA XML Registry 2011-12 - WGLC IODEF Extension to support structured cybersecurity information 2012-02 - Submit Template for extensions to IODEF to IESG for consideration as Informational document 2012-02 - Submit IODEF Extensions in IANA XML Registry to IESG for consideration as Standards Track document 2012-02 - Submit IODEF Extension to support structured cybersecurity information to IESG for consideration as Standards Track document 2012-03 - WGLC IODEF Extension Labeling for data protection, retention, policies, and regulations 2012-03 - WGLC IODEF Guidance 2012-04 - Submit IODEF Extension Labeling for data protection, retention, policies, and regulations to IESG for consideration as Standards Track document 2012-04 - Submit WGLC IODEF Guidance to IESG for consideration as Informational document 2012-05 - WGLC GRC Report Exchange 2012-06 - Submit GRC Report Exchange to IESG for consideration as Standards Track document 2012-06 - WGLC Forensics extension 2012-07 - Submit IODEF Forensics extension to IESG for consideration as Standards Track document _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nico@cryptonector.com Wed Oct 12 00:05:30 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15F321F853B; Wed, 12 Oct 2011 00:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Si4uqw+l1Zux; Wed, 12 Oct 2011 00:05:30 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABBB21F8531; Wed, 12 Oct 2011 00:05:30 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id A925ABC047; Wed, 12 Oct 2011 00:05:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :date:message-id:subject:from:to:content-type; q=dns; s= cryptonector.com; b=RF8wb2ERhtP5qtmscy9AXbsm6m4O3mDztznxpPJc/AiD KZ476WtWHnKYtT6M5+NGex+5GgWi1AEE07OdZcHx/YmMFSqTgQwYTQ5TQBf3Nssk yeicuuWpEG+lud6VkTTkR/jvRclrYxRloqAKb9jkjhWtGVPX+bZraXevMub+WnA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=NOj7xCmfwlR95N6g4U8J6NU+c/8=; b=nc+R0YxPBZL Mbmrbciqys8TMFHVueouv0bezhg3cc+W+/vCD3iy/LzMTOFY6NFCWsKP+OYc32Lk v8ojCrYajxYi8d08sNxW/002HmE+xUZvlPY11mN/PlR5KdiMgBzX2XF1TPJmTCzC VMuS1JNuO974Wwffo6cmaVYwfxyTTDV0= Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPSA id 74FCCBC040; Wed, 12 Oct 2011 00:05:28 -0700 (PDT) Received: by gyh20 with SMTP id 20so493579gyh.31 for ; Wed, 12 Oct 2011 00:05:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.31.131 with SMTP id a3mr51489826pbi.24.1318403127353; Wed, 12 Oct 2011 00:05:27 -0700 (PDT) Received: by 10.68.59.169 with HTTP; Wed, 12 Oct 2011 00:05:27 -0700 (PDT) Date: Wed, 12 Oct 2011 02:05:27 -0500 Message-ID: From: Nico Williams To: secdir@ietf.org, iesg@ietf.org, draft-ietf-ccamp-wson-impairments@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [secdir] Review of draft-ietf-ccamp-wson-impairments-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 07:05:31 -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 targets the informative (FYI) track and describes a framework for applying GMPLS protocols to handle information about link quality (my words) based on "Impairment Aware Routing and Wavelength Assignment (IA-RWA)". Given the document's intended status and the fact that no protocols as such are specified, it would seem that the sparse security considerations section should suffice, except that it's not clear whether active attacks are of concern (the security considerations section concenrs itself mostly with privacy concerns). A few words on the potential for active attacks would be useful, particularly for the non-initiate. The I-D is not properly formatted (e.g., the abstract is not on the first page, and plenty of other formatting errors follow). Assuming that these errors are corrected and that the security considerations section is updated as indicated above, I think this I-D should be ready. Nico -- From nico@cryptonector.com Wed Oct 12 11:02:12 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED9621F8BEF; Wed, 12 Oct 2011 11:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQ3m3w5UoYLu; Wed, 12 Oct 2011 11:02:11 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id C227A21F8BDE; Wed, 12 Oct 2011 11:02:11 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id E81EA2F4081; Wed, 12 Oct 2011 11:01:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=Vc54pohdugfS76EZ31MEyU2C3elU+Ddl7RDMcG94a1j4 2C8sUAKt8HPwHCHVK9liAGxtBYNp9bOmxjYKAHFTYgRV8hxY5rGErAiP4kBK9E2h dHMx3IDXTdrmX8yw6pn7OCaRFVmbLe4iYfiMHpVxPYz7uDByKjDnhopPui6qFv4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=mCwScrbH1VtkH0kvs2Atk0Mgu6w=; b=oWYzeUdQM5k WB/LsFw5+nHFdO4PxFBwagxKdV2Rp2EQNSHA2Oj6JAyTwrexCSMF2+vVj8wFNizl TPHXweagVtSkR+O3GoJGaAAkthHHlKahyDmcBRuvcTSrgbZuU/h4xns3ZUMKY+uF l0XX4avXRAUNk5vaf/AqsrtXQPTn9XUg= Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id BC5B52F4076; Wed, 12 Oct 2011 11:01:00 -0700 (PDT) Received: by qadb12 with SMTP id b12so1052531qad.31 for ; Wed, 12 Oct 2011 11:00:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.57.102 with SMTP id h6mr2820729pbq.7.1318442459747; Wed, 12 Oct 2011 11:00:59 -0700 (PDT) Received: by 10.68.59.169 with HTTP; Wed, 12 Oct 2011 11:00:59 -0700 (PDT) In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E171817FEAA@DFWEML501-MBX.china.huawei.com> References: <7AEB3D6833318045B4AE71C2C87E8E171817FEAA@DFWEML501-MBX.china.huawei.com> Date: Wed, 12 Oct 2011 13:00:59 -0500 Message-ID: From: Nico Williams To: Leeyoung Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "iesg@ietf.org" , "draft-ietf-ccamp-wson-impairments@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Review of draft-ietf-ccamp-wson-impairments-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 18:02:12 -0000 On Wed, Oct 12, 2011 at 12:30 PM, Leeyoung wrote: > Modified security section reads: > > =C2=A0 This document discusses a number of control plane architectures th= at > =C2=A0 incorporate knowledge of impairments in optical networks. If such > =C2=A0 architecture is put into use within a network it will by its natur= e > =C2=A0 contain details of the physical characteristics of an optical > =C2=A0 network. Such information would need to be protected from intentio= nal > =C2=A0 or unintentional disclosure similar to other network information u= sed > =C2=A0 within intra-domain protocols. > > =C2=A0 This document does not require changes to the security models with= in > =C2=A0 GMPLS and associated protocols. =C2=A0That is, the OSPF-TE, RSVP-T= E, and > =C2=A0 PCEP security models could be operated unchanged. However, satisfy= ing > =C2=A0 the requirements for impairment information dissemination using th= e existing > =C2=A0 protocols may significantly affect the loading of those protocols. > =C2=A0 This may make the operation of the network more vulnerable to deni= al- > =C2=A0 of-service attacks or active attacks. =C2=A0Therefore, additional = care maybe > =C2=A0 required to ensure that the protocols are secure in the impairment= -aware > =C2=A0 WSON environment. > > =C2=A0 Furthermore, the additional information distributed in order to > =C2=A0 address impairment information represents a disclosure of network > =C2=A0 capabilities that an operator may wish to keep private. Considerat= ion > =C2=A0 should be given to securing this information. =C2=A0For a general = discussion > =C2=A0 on MPLS- and GMPLS-related security issues, see the MPLS/GMPLS sec= urity > =C2=A0 framework [RFC5920]. > > Please suggest some texts if these are not satisfactory to your need. Tha= nks. I'm not concerned about denial of service attacks in particular as it is often the case that there are denial of service attack surfaces about which there's little we can do. What I'm concerned about is whether the framework can handle active attacks such as injections, impersonation, and MITMs. The reference to OSPF and friends is probably sufficient in this regard for me to figure out an answer, though saying something to the effect that a) you rely on such protocols for security (your proposed change says so), and b) that those protocols meet whatever you think the requirements ought to be for IA-RWA. Oh, and I suppose you should c) list what you think those requirements are. Of course, if these protocols don't today meet those requirements, then that'd be a problem, but I suspect that won't prove to be the case. This is one of those occasions where it's good to ask "what's your threat model" too. My guess is that there isn't that much of a threat from eavesdropping on IA-RWA, so passive attackers are not part of the threat model. What active attacks might be in the threat model? Nico -- From leeyoung@huawei.com Wed Oct 12 10:31:04 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB86021F8B22; Wed, 12 Oct 2011 10:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.382 X-Spam-Level: X-Spam-Status: No, score=-6.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILCR+dKDmgaC; Wed, 12 Oct 2011 10:31:04 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 4F23521F8AEC; Wed, 12 Oct 2011 10:31:04 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSY005AVRBRVU@usaga04-in.huawei.com>; Wed, 12 Oct 2011 12:31:03 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSY000T5RBQT1@usaga04-in.huawei.com>; Wed, 12 Oct 2011 12:31:03 -0500 (CDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 12 Oct 2011 10:30:57 -0700 Received: from DFWEML501-MBX.china.huawei.com ([10.124.31.87]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0270.001; Wed, 12 Oct 2011 10:30:54 -0700 Date: Wed, 12 Oct 2011 17:30:54 +0000 From: Leeyoung In-reply-to: X-Originating-IP: [10.47.139.172] To: Nico Williams , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-ccamp-wson-impairments@tools.ietf.org" Message-id: <7AEB3D6833318045B4AE71C2C87E8E171817FEAA@DFWEML501-MBX.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: Review of draft-ietf-ccamp-wson-impairments-07 Thread-index: AQHMiK1k/aUAVZm3CECvsX0ct9xRXZV4912A X-MS-Has-Attach: X-MS-TNEF-Correlator: References: X-Mailman-Approved-At: Fri, 14 Oct 2011 08:39:29 -0700 Subject: Re: [secdir] Review of draft-ietf-ccamp-wson-impairments-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 17:31:05 -0000 Hi Nico, Thanks for your review and giving us your comments on security section. Please review the following changes. The current security section reads: This document discusses a number of control plane architectures that incorporate knowledge of impairments in optical networks. If such architecture is put into use within a network it will by its nature contain details of the physical characteristics of an optical network. Such information would need to be protected from intentional or unintentional disclosure similar to other network information used within intra-domain protocols. It is expected that protocol solutions work will address any issues on the use of impairment information. Modified security section reads: This document discusses a number of control plane architectures that incorporate knowledge of impairments in optical networks. If such architecture is put into use within a network it will by its nature contain details of the physical characteristics of an optical network. Such information would need to be protected from intentional or unintentional disclosure similar to other network information used within intra-domain protocols. This document does not require changes to the security models within GMPLS and associated protocols. That is, the OSPF-TE, RSVP-TE, and PCEP security models could be operated unchanged. However, satisfying the requirements for impairment information dissemination using the existing protocols may significantly affect the loading of those protocols. This may make the operation of the network more vulnerable to denial- of-service attacks or active attacks. Therefore, additional care maybe required to ensure that the protocols are secure in the impairment-aware WSON environment. Furthermore, the additional information distributed in order to address impairment information represents a disclosure of network capabilities that an operator may wish to keep private. Consideration should be given to securing this information. For a general discussion on MPLS- and GMPLS-related security issues, see the MPLS/GMPLS security framework [RFC5920]. Please suggest some texts if these are not satisfactory to your need. Thanks. Best Regards, Young -----Original Message----- From: Nico Williams [mailto:nico@cryptonector.com] Sent: Wednesday, October 12, 2011 2:05 AM To: secdir@ietf.org; iesg@ietf.org; draft-ietf-ccamp-wson-impairments@tools.ietf.org Subject: Review of draft-ietf-ccamp-wson-impairments-07 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 targets the informative (FYI) track and describes a framework for applying GMPLS protocols to handle information about link quality (my words) based on "Impairment Aware Routing and Wavelength Assignment (IA-RWA)". Given the document's intended status and the fact that no protocols as such are specified, it would seem that the sparse security considerations section should suffice, except that it's not clear whether active attacks are of concern (the security considerations section concenrs itself mostly with privacy concerns). A few words on the potential for active attacks would be useful, particularly for the non-initiate. The I-D is not properly formatted (e.g., the abstract is not on the first page, and plenty of other formatting errors follow). Assuming that these errors are corrected and that the security considerations section is updated as indicated above, I think this I-D should be ready. Nico -- From klaas@cisco.com Fri Oct 14 08:07:01 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3ED21F87C9 for ; Fri, 14 Oct 2011 08:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZHuFWOOEXvW for ; Fri, 14 Oct 2011 08:07:00 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6505F21F87D3 for ; Fri, 14 Oct 2011 08:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=2069; q=dns/txt; s=iport; t=1318604820; x=1319814420; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=0A4dD/z0eeBNpNBc7zPqpEYW4thx4M4OYTaASyal7xw=; b=HL3FZBDDkr+F7KZLn1jTSAdp8mXsSAq9Y7HhhLejzS5GYNqYaMuiMzIZ /oy4I6GocNWADMJ5Ru1Kdj8A1/wvfJ+8Zs8DQZa4CrEZ//H9rShrFMq0Q Hdjhkkhg+6DGAJmUzDa6q0j1VbmjwHBpzUFA3dGiYfSUsBeiEL7onybGq w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEANFPmE6tJXG8/2dsb2JhbABDqGOBBYIHASctBIFNNKBTAZ5Ghk1LYQSTd5FX X-IronPort-AV: E=Sophos;i="4.69,346,1315180800"; d="scan'208";a="28490984" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 14 Oct 2011 15:06:59 +0000 Received: from rtp-kwiereng-8711.cisco.com (rtp-kwiereng-8711.cisco.com [10.116.7.34]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9EF6vD7017461; Fri, 14 Oct 2011 15:06:58 GMT From: Klaas Wierenga Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Oct 2011 17:06:56 +0200 Message-Id: To: secdir@ietf.org, draft-ietf-ccamp-attribute-bnf@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) X-Mailman-Approved-At: Fri, 14 Oct 2011 08:39:29 -0700 Subject: [secdir] secdir review of draft-ietf-ccamp-attribute-bnf-02.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 15:07:01 -0000 Hi, I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the = security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. This (short) document specifies how LSP (Label Switched Path) attributes = are to be carried in RSVP Path and Resv messages using the Routing = Backus-Naur Form, and clarifies related Resv message formats. The = document updates RFC 4875 and RFC 5420. Section 9 of RFC5420 contains a = narrative description of the message formats for the definition of the = object carrying information on the LSP. This document provides the BNF = for Path and Resv messages carrying the LSP Attributes related object.=20= Given my lack of expertise in MPLS I have not much to offer in terms of = general comments on the draft for the draft authors to take into = consideration, but here goes: - Section 1 Gives a short explanation as to why you need to update 5420, but not why = the same goes for 4875, this may be obvious for most, but it was not for = me. I think it would help to add a sentence on the necessary changes for = 4875. - Section 1, p3 states:=20 "The current message format description has led to an issue in how the LSP Attributes related objects are to be processed in Resv messages of P2MP LSPs." Is this just the fact that the lack of a formal definition of the = message format leads to inconstant implementations? If so, why not state = just that? If not, what is the problem? - The security considerations section states: "This document clarifies usage of objects defined in [RFC5420]. No new information is conveyed and therefore neither are there any additional security considerations. " Which I think that is a fair statement. So concerning the security = considerations part I see no objection for this document to advance. Regards, Klaas From weiler+secdir@watson.org Fri Oct 14 08:44:50 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3889721F8CC0 for ; Fri, 14 Oct 2011 08:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yOFQw3uKnnC for ; Fri, 14 Oct 2011 08:44:49 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 8B39821F8CA0 for ; Fri, 14 Oct 2011 08:44:49 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id p9EFilnq091458 for ; Fri, 14 Oct 2011 11:44:47 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p9EFikPf091454 for ; Fri, 14 Oct 2011 11:44:46 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 14 Oct 2011 11:44:46 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Fri, 14 Oct 2011 11:44:48 -0400 (EDT) Subject: [secdir] Assignments (PAY ATTENTION!) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 15:44:50 -0000 As you may have seen on Monday, secdir assignments have returned, and they've returned in force. Most of the docs below were newly assigned this week (Monday or today), and a couple of the docs that were listed in the "last call" section on Monday's assignment message are now scheduled for telechat next week. Please check the lists carefully. Dashes (-) in the last call date field typcially indicate that IETF LC has already ended. As a reminder, we normally ask for reviews by the end of IETF LC and, in any case no later than the FRIDAY before the telechat. With the delay in getting these out, I'm sure our ADs will be understanding, but doc editors do appreciate having comments within the last call window rather than just before telechat. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Tero Kivinen is next in the rotation. For telechat 2011-10-20 Reviewer LC end Draft Derek Atkins T 2011-10-20 draft-ietf-eai-rfc5336bis-14 Rob Austein T 2011-10-20 draft-ietf-eai-rfc5337bis-dsn-04 Uri Blumenthal T 2011-10-18 draft-ietf-mpls-tp-li-lb-07 Dave Cridland T - draft-ietf-nfsv4-federated-fs-dns-srv-namespace-09 Shawn Emery T - draft-ietf-sidr-ghostbusters-14 Dan Harkins T 2011-10-20 draft-jdfalk-maawg-cfblbcp-02 Sam Hartman T 2011-10-12 draft-melnikov-mmhs-header-fields-04 Sam Weiler T 2011-10-12 draft-ietf-grow-no-more-unallocated-slash8s-04 Brian Weis T - draft-ietf-appsawg-rfc3462bis-01 Klaas Wierenga T - draft-ietf-ccamp-attribute-bnf-02 Glen Zorn T 2011-10-20 draft-ietf-eai-rfc5335bis-12 For telechat 2011-11-03 Reviewer LC end Draft Alan DeKok T - draft-ietf-pim-port-08 Tobias Gondrom T 2011-10-18 draft-ietf-tls-dtls-heartbeat-03 Love Hornquist-Astrand T 2011-10-31 draft-salter-rfc5430bis-01 Jeffrey Hutzelman T 2011-10-24 draft-sprecher-mpls-tp-oam-considerations-01 Matt Lepinski T 2011-08-16 draft-ietf-ospf-auth-trailer-ospfv3-07 Last calls and special requests: Reviewer LC end Draft Richard Barnes 2011-10-24 draft-ietf-ippm-metrictest-03 Donald Eastlake - draft-ietf-savi-framework-05 Phillip Hallam-Baker - draft-irtf-hiprg-dht-04 Steve Hanna 2011-10-20 draft-ietf-vcarddav-kind-app-00 Paul Hoffman 2011-10-21 draft-oreirdan-mody-bot-remediation-16 Leif Johansson 2011-10-24 draft-ietf-avtcore-srtp-vbr-audio-03 Charlie Kaufman 2011-10-25 draft-ietf-geopriv-deref-protocol-03 Scott Kelly 2011-10-25 draft-ietf-geopriv-policy-uri-02 Stephen Kent 2011-10-25 draft-ietf-kitten-sasl-openid-06 Catherine Meadows R2011-04-13 draft-ietf-speechsc-mrcpv2-25 Tina TSOU 2011-04-23 draft-shin-augmented-pake-08 Carl Wallace 2011-11-07 draft-davis-t-langtag-ext-06 Tom Yu 2011-10-19 draft-ietf-codec-guidelines-05 Larry Zhu 2011-10-13 draft-ietf-cuss-sip-uui-reqs-06 From dharkins@lounge.org Fri Oct 14 10:17:23 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092AC21F8BD3; Fri, 14 Oct 2011 10:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+2V-uV0DGlM; Fri, 14 Oct 2011 10:17:22 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDBD21F8997; Fri, 14 Oct 2011 10:17:22 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 740D2A88811A; Fri, 14 Oct 2011 10:17:22 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 14 Oct 2011 10:17:22 -0700 (PDT) Message-ID: Date: Fri, 14 Oct 2011 10:17:22 -0700 (PDT) From: "Dan Harkins" To: iesg@ietf.org, secdir@ietf.org, draft-jdfalk-maawg-cfblbcp.all@tools.ietf.org User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [secdir] review of draft-jdfalk-maawg-cfblbcp-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 17:17:23 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft codifies some best practices, developed over the past several years, involving a "complaint feedback loop" to deal with abusive or unwanted email, i.e. spam. It is full of lots of motherhood-and-apple-pie statements like this, "The decision to provide a Complaint Feedback Loop service should not be taken lightly. The benefits of a Feedback Loop are great, but success depends on a sound plan, organized implementation, and dedication to upkeep." Indeed. There doesn't seem to be a whole lot of behavior that requires standardization. As a BCP-type of RFC this seems OK, though. The security considerations consist of a single line that refers readers to 3 other sections of the draft, none of which it appears to me deal with security. I would suggest a rewording of this to make the section broadly address the security implications of implementing, joining, or contributing to a "complaint feedback loop". Maybe also have a little something about countermeasures or dealing with spammers trying to game the system. regards, Dan. From lberger@labn.net Fri Oct 14 12:09:02 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A3D21F8D44 for ; Fri, 14 Oct 2011 12:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.971 X-Spam-Level: X-Spam-Status: No, score=-99.971 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XliSLWKF7TrW for ; Fri, 14 Oct 2011 12:09:01 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id A7B8921F8CF5 for ; Fri, 14 Oct 2011 12:09:01 -0700 (PDT) Received: (qmail 7148 invoked by uid 0); 14 Oct 2011 19:08:59 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 14 Oct 2011 19:08:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=tds9mGsLtl7WMq390kfscOj0/oQwiR50zM8aTQH/P4o=; b=fz+ur4nJjX4XW9B4xneDFRs70H2XGEy4H008BA/rI88X3xrZj5E3u3ArjKT3q6o8QFypC/SwYRdFnt7Qsm+D12OqF1BrXO1u1QcJ6I5e/qmlIOzaZmbSQ6+Kd2I0KJga; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1REn7r-0000tq-BJ; Fri, 14 Oct 2011 13:08:59 -0600 Message-ID: <4E9888CB.1080208@labn.net> Date: Fri, 14 Oct 2011 15:08:59 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Klaas Wierenga References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: Adrian Farrel , draft-ietf-ccamp-attribute-bnf@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-ccamp-attribute-bnf-02.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 19:09:02 -0000 Klaas, Thank you for the comments. Please see responses in-line below. Lou On 10/14/2011 11:06 AM, Klaas Wierenga wrote: > Hi, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This (short) document specifies how LSP (Label Switched Path) > attributes are to be carried in RSVP Path and Resv messages using the > Routing Backus-Naur Form, and clarifies related Resv message formats. > The document updates RFC 4875 and RFC 5420. Section 9 of RFC5420 > contains a narrative description of the message formats for the > definition of the object carrying information on the LSP. This > document provides the BNF for Path and Resv messages carrying the LSP > Attributes related object. > > Given my lack of expertise in MPLS I have not much to offer in terms > of general comments on the draft for the draft authors to take into > consideration, but here goes: > > - Section 1 > > Gives a short explanation as to why you need to update 5420, but not > why the same goes for 4875, this may be obvious for most, but it was > not for me. I think it would help to add a sentence on the necessary > changes for 4875. > I think this is obvious to any involved in the technology, but how about: OLD: processed in Resv messages of P2MP LSPs. NEW processed in Resv messages of P2MP LSPs (which are defined in [RFC4875]). > - Section 1, p3 states: "The current message format description has > led to an issue in how the LSP Attributes related objects are to be > processed in Resv messages of P2MP LSPs." > > Is this just the fact that the lack of a formal definition of the > message format leads to inconstant implementations? If so, why not > state just that? If not, what is the problem? > How about: OLD: The current message format description has led to an issue in how the LSP Attributes related objects are to be processed... NEW The current message format description has led to the open question of how the LSP Attributes related objects are to be processed... Thanks, Lou > - The security considerations section states: "This document > clarifies usage of objects defined in [RFC5420]. No new information > is conveyed and therefore neither are there any additional security > considerations. " > > Which I think that is a fair statement. So concerning the security > considerations part I see no objection for this document to advance. > > Regards, > > Klaas > > > > > > > From adrian@olddog.co.uk Fri Oct 14 12:31:54 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D32921F8C83 for ; Fri, 14 Oct 2011 12:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Km-7pZoMwNtf for ; Fri, 14 Oct 2011 12:31:53 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 434C021F8C9E for ; Fri, 14 Oct 2011 12:31:48 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id p9EJVjip006811; Fri, 14 Oct 2011 20:31:45 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id p9EJVhCf006802 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Oct 2011 20:31:44 +0100 From: "Adrian Farrel" To: "'Lou Berger'" , "'Klaas Wierenga'" References: <4E9888CB.1080208@labn.net> In-Reply-To: <4E9888CB.1080208@labn.net> Date: Fri, 14 Oct 2011 20:31:43 +0100 Message-ID: <041001cc8aa7$e849e470$b8ddad50$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-language: en-gb Thread-index: AQKevjEplp2bVEy5uX6OVXzUjvMlegG/Eeq5k8naLxA= Cc: draft-ietf-ccamp-attribute-bnf@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-ccamp-attribute-bnf-02.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 19:31:54 -0000 RFC Editors notes added. Adrian > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: 14 October 2011 20:09 > To: Klaas Wierenga > Cc: secdir@ietf.org; draft-ietf-ccamp-attribute-bnf@tools.ietf.org; Adrian Farrel > Subject: Re: secdir review of draft-ietf-ccamp-attribute-bnf-02.txt > > Klaas, > Thank you for the comments. Please see responses in-line below. > > Lou > > On 10/14/2011 11:06 AM, Klaas Wierenga wrote: > > Hi, > > > > I have reviewed this document as part of the security directorate's > > ongoing effort to review all IETF documents being processed by the > > IESG. These comments were written primarily for the benefit of the > > security area directors. Document editors and WG chairs should treat > > these comments just like any other last call comments. > > > > This (short) document specifies how LSP (Label Switched Path) > > attributes are to be carried in RSVP Path and Resv messages using the > > Routing Backus-Naur Form, and clarifies related Resv message formats. > > The document updates RFC 4875 and RFC 5420. Section 9 of RFC5420 > > contains a narrative description of the message formats for the > > definition of the object carrying information on the LSP. This > > document provides the BNF for Path and Resv messages carrying the LSP > > Attributes related object. > > > > Given my lack of expertise in MPLS I have not much to offer in terms > > of general comments on the draft for the draft authors to take into > > consideration, but here goes: > > > > - Section 1 > > > > Gives a short explanation as to why you need to update 5420, but not > > why the same goes for 4875, this may be obvious for most, but it was > > not for me. I think it would help to add a sentence on the necessary > > changes for 4875. > > > > I think this is obvious to any involved in the technology, but how about: > OLD: > processed in Resv messages of P2MP LSPs. > NEW > processed in Resv messages of P2MP LSPs (which are defined in > [RFC4875]). > > > > - Section 1, p3 states: "The current message format description has > > led to an issue in how the LSP Attributes related objects are to be > > processed in Resv messages of P2MP LSPs." > > > > Is this just the fact that the lack of a formal definition of the > > message format leads to inconstant implementations? If so, why not > > state just that? If not, what is the problem? > > > > How about: > OLD: > The current message format description has led > to an issue in how the LSP Attributes related objects are to be > processed... > NEW > The current message format description has led to the open > question of how the LSP Attributes related objects are to be > processed... > > Thanks, > Lou > > > > - The security considerations section states: "This document > > clarifies usage of objects defined in [RFC5420]. No new information > > is conveyed and therefore neither are there any additional security > > considerations. " > > > > Which I think that is a fair statement. So concerning the security > > considerations part I see no objection for this document to advance. > > > > Regards, > > > > Klaas > > > > > > > > > > > > > > From paul.hoffman@vpnc.org Fri Oct 14 15:57:50 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C20521F8AFE for ; Fri, 14 Oct 2011 15:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtwaVRwrmqRe for ; Fri, 14 Oct 2011 15:57:50 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id F209021F8AFC for ; Fri, 14 Oct 2011 15:57:49 -0700 (PDT) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p9EMvmTB025564 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Oct 2011 15:57:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Oct 2011 15:57:48 -0700 Message-Id: To: secdir Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Cc: draft-oreirdan-mody-bot-remediation.all@tools.ietf.org Subject: [secdir] Secdir review of draft-oreirdan-mody-bot-remediation X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 22:57:50 -0000 This is a review of the security-related aspects of = draft-oreirdan-mody-bot-remediation, primarily for the benefit of the = Security ADs and the authors or draft-oreirdan-mody-bot-remediation. The document is a set of recommendations to ISPs on how to deal with = customer computers that have been botted. It is informational in nature, = and (wisely) avoids any 2119ish language. Topics covered include = determining which customers might be infected, communicating with the = customers, and remediation. In other words, the entire document covers security-related topics. = Fortunately, it does so in a very clear fashion throughout. Suggestions = for actions than an ISP might take are often accompanied with warnings = and discussion of the security aspects of those actions. The Security = Considerations section, while short, emphasizes the need for the reader = to read carefully, particularly the section on the security aspects of = sending mail to potentially-infected customers. One editorial comment: the first sentence of the abstract has a = superfluous comma that imbues unintended humorous semantics: This document contains recommendations on how Internet Service Providers can manage the effects of computers used by their subscribers, which have been infected with malicious bots, via various remediation techniques. It is unlikely that subscribers themselves have been infected with = malicious bots. A better wording might be: This document contains recommendations on how Internet Service Providers can use various remediation techniques to manage the effects of malicious bots on their subscribers' computers. --Paul Hoffman From shawn.emery@oracle.com Sat Oct 15 23:34:35 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A78811E8085; Sat, 15 Oct 2011 23:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uolJ72UvpKB; Sat, 15 Oct 2011 23:34:35 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 0615411E8082; Sat, 15 Oct 2011 23:34:34 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p9G6YWmi006933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 16 Oct 2011 06:34:34 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p9G6YUAv017255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Oct 2011 06:34:32 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p9G6YOZr015245; Sun, 16 Oct 2011 01:34:25 -0500 Received: from [10.159.208.113] (/10.159.208.113) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 15 Oct 2011 23:34:24 -0700 Message-ID: <4E9A7AC9.1000803@oracle.com> Date: Sun, 16 Oct 2011 00:33:45 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:6.0.2) Gecko/20110923 Thunderbird/6.0.2 MIME-Version: 1.0 To: secdir@ietf.org References: <4E1EA3BF.1060604@oracle.com> In-Reply-To: <4E1EA3BF.1060604@oracle.com> X-Forwarded-Message-Id: <4E1EA3BF.1060604@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4E9A7AFA.0088:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: draft-ietf-sidr-ghostbusters.all@toosl.ietf.org, iesg@ietf.org Subject: [secdir] Review of draft-ietf-sidr-ghostbusters-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 06:34:35 -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 standards track draft describes a new record that allows a Resource Public Key Infrastructure (RPKI) user the ability to look up a point of contact for notification of current or eventual issues (e.g. certificate expiration along a path to the trust anchor). The security considerations section does exist and states that there is no OTW protocol implication. It goes on to state that Ghostbuster Records could provide information for telemarketers and spammers. However, this is no different from what already exists in whois data, for example. General comments: I love the name of this draft, quite fitting ;) Thank you for the background reading section, lots of reading but very helpful. Editorial comments: s/who responsible a the CA/who is responsible for the CA/ s/a NOC, ..../NOC, etc./ Shawn. -- From weiler@watson.org Mon Oct 17 09:12:54 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E237321F8D5D; Mon, 17 Oct 2011 09:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8US5Gzf9TgW; Mon, 17 Oct 2011 09:12:54 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD0021F8D59; Mon, 17 Oct 2011 09:12:54 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id p9HGClCY092025; Mon, 17 Oct 2011 12:12:47 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p9HGCjBi092009; Mon, 17 Oct 2011 12:12:46 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 17 Oct 2011 12:12:45 -0400 (EDT) From: Samuel Weiler To: iesg@ietf.org, draft-ietf-grow-no-more-unallocated-slash8s.all@tools.ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Mon, 17 Oct 2011 12:12:47 -0400 (EDT) Cc: secdir@ietf.org Subject: [secdir] secdir review of draft-ietf-grow-no-more-unallocated-slash8s-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 16:12:55 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This short doc tells operators that they should no longer have (most) v4 /8's in their bogon filter lists. I'm not sure why that statement needs its own draft, but it seems like an obvious and harmless thing to say. I have no concerns with the doc. -- Sam From leifj@sunet.se Mon Oct 17 16:43:32 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 517471F0C4B; Mon, 17 Oct 2011 16:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftsQEU-o0+D8; Mon, 17 Oct 2011 16:43:31 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 51F2C1F0C43; Mon, 17 Oct 2011 16:43:31 -0700 (PDT) Received: from [10.66.224.31] (h-64-236-139-254.aoltw.net [64.236.139.254]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p9HNhK5x012003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Oct 2011 01:43:25 +0200 (CEST) Message-ID: <4E9CBD98.2060207@sunet.se> Date: Tue, 18 Oct 2011 01:43:20 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: secdir@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-avtcore-srtp-vbr-audio@tools.ietf.org, iesg@ietf.org Subject: [secdir] secdir review of draft-ietf-avtcore-srtp-vbr-audio-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 23:43:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This BCP-track document talks about potential information-leakage resulting from the use of variable bit rate audio codecs with secure RTP. The document is well written and clearly explains the situations where information-leakage can occur. The most realistic scenario presented is eavesdropping on an RTP audio stream where one endpoint is an IVR or other automated voice systems that use pre-recorded messages. The only think I missed was a discussion (perhaps in the security section) about the risk of negotiating parameters (eg VAD) which could lead to increased risk of information-leakage, however this is perhaps a minor issue. Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6cvZcACgkQ8Jx8FtbMZnfdrQCeInYzkao2scRc5I2WWAbb7mvt dlIAn2iH6v1atyye5ky4xiJGNU4AVq2K =O/yj -----END PGP SIGNATURE----- From glenzorn@gmail.com Tue Oct 18 08:02:44 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5E321F8BAA; Tue, 18 Oct 2011 08:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPxbxlUqy0CE; Tue, 18 Oct 2011 08:02:43 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 87EEB21F8BBD; Tue, 18 Oct 2011 08:02:42 -0700 (PDT) Received: by qyk34 with SMTP id 34so2009046qyk.10 for ; Tue, 18 Oct 2011 08:02:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=spG2Hz38JABr/ScJdltibDq/ReS8P/oFqVhZ5Sn2eDA=; b=MJVIz9m2wkbGRASHHldU50ogcsfAZhT9VtBW8zL4lnUOXRNkgAIYVmnI1UjfkufBKF Ebsmb2vNS5jy7Z9YRz4uglLTUmCxSknhW1haS2fyTU7TGN/jbnc9Wr7XGMA61xU86Kb/ gSRwqgLMLrgIyZuMOPBeg5W/2tnoqddLKgldY= Received: by 10.229.91.16 with SMTP id k16mr601494qcm.104.1318950161836; Tue, 18 Oct 2011 08:02:41 -0700 (PDT) Received: from [192.168.1.98] (ppp-124-122-122-201.revip2.asianet.co.th. [124.122.122.201]) by mx.google.com with ESMTPS id cb11sm2759461qab.3.2011.10.18.08.02.37 (version=SSLv3 cipher=OTHER); Tue, 18 Oct 2011 08:02:40 -0700 (PDT) Message-ID: <4E9D950A.8080507@gmail.com> Date: Tue, 18 Oct 2011 22:02:34 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: The IESG , secdir@ietf.org, eai-chairs@tools.ietf.org, abelyang@twnic.net.tw, Shawn.Steele@microsoft.com, ned+ietf@mrochek.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] secdir review of draft-ietf-eai-rfc5335bis-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 15:02:44 -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. EDITORIAL COMMENTS Section 3., last paragraph: s/&UTF8SMTPbis;/UTF8SMTPbis/ Section 3.1, last paragraph: I've pretty much given up complaining about the abominable practice of using pointers as if they were real objects (e.g., "See [RFC5198] for a discussion...") but the use of a pointer to a document as a noun ("normalization form [NFC] SHOULD be used" is much too much: both confusing (Is there a document describing the NFKC normalization form? Sure, it's [NFC]!) and too precious by far. STRONGLY suggest changing the text to read See RFC 5198 [RFC5198] for a discussion of Unicode normalization; normalization form NFC [UNF] SHOULD be used. Actually, if one is going to do internationalization properly, one of the most often-cited goals is to permit people to spell their names correctly. Since many mailbox local parts reflect personal names, that principle applies to mailboxes as well. The NFKC [UNF] normalization form SHOULD NOT be used because it may lose information that is needed to correctly spell some names in some unusual circumstances. From stephen.farrell@cs.tcd.ie Tue Oct 18 14:08:20 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82FC21F8ADE for ; Tue, 18 Oct 2011 14:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hD6sO-Tp18eg for ; Tue, 18 Oct 2011 14:08:20 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC9121F8AD3 for ; Tue, 18 Oct 2011 14:08:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 174D6171C6E; Tue, 18 Oct 2011 22:08:19 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1318972098; bh=xDxqQZ5WWH/XKqn2F5IdYN32 CtNrtKKr04psQw5kNsw=; b=iiIoDNzuplYQ8xPSQ3bFlr04zLU9jvQOhEr9jH5H 6QTZgzpSg3z2T6YuDXVgHuxJ9QDsfuGIIEeEtzZw8gpjEe8AQ7UtkbXYN8mOLuJ4 GL0tTsH3x2ZRXoeuOV8L6GcVJSVWX/CNxCMAbol6P91y3vfwOlxq7ce3kxTXPYBD uOV2BSp5LjBpiGNGFYLECGgJu4FSjLlgD1obVNy3jvArbouVOTwWpS3U9Gn2M0NX ZIj0tslkoY2SDTKi176hN1+GQrkHOPWfRVvRs2yJZmFtgJk0wTgoY35uUdvcgpsr 1CRvsX4CfY8eFHO6yEYyetL8XV93fUKp0v4T19pGiFpvFg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id qNf5zzLAZDKs; Tue, 18 Oct 2011 22:08:18 +0100 (IST) Received: from [10.87.48.8] (unknown [86.44.65.222]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 8F23F171C47; Tue, 18 Oct 2011 22:08:18 +0100 (IST) Message-ID: <4E9DEAB8.6060603@cs.tcd.ie> Date: Tue, 18 Oct 2011 22:08:08 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "secdir@ietf.org" , Jeffrey Hutzelman Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] pgp key signing X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 21:08:20 -0000 Hiya, Jeff's not going to make it to Taipei. It'd be good to get a few secdir folks who'd be interested in keeping up the pgp key signing session for the next meeting and maybe going forward with Jeff. Any takers? On- or off-list replies are fine. Ta, S. From tobias.gondrom@gondrom.org Wed Oct 19 05:32:33 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67BA621F8BA0 for ; Wed, 19 Oct 2011 05:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.164 X-Spam-Level: X-Spam-Status: No, score=-96.164 tagged_above=-999 required=5 tests=[AWL=0.613, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tr9qfJQEo4J for ; Wed, 19 Oct 2011 05:32:32 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 3D39021F8B5B for ; Wed, 19 Oct 2011 05:32:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=aa1/aSR8LboQSwkrIgbjeiOPxGFpPnplpQOi60oSCJYVsGewE8IW7sqxrYGmu5U1wmQRYIoOHLZIv6U5uG3BtPgdyZwnlztIlw2TCqEZ83y9CrbErl0uP57VWyOjs6hl; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type; Received: (qmail 27938 invoked from network); 19 Oct 2011 14:31:56 +0200 Received: from d1-231-46-143-118-on-nets.com (HELO ?118.143.46.231?) (118.143.46.231) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 19 Oct 2011 14:31:55 +0200 Message-ID: <4E9EC337.1070404@gondrom.org> Date: Wed, 19 Oct 2011 13:31:51 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: iesg@ietf.org, secdir@ietf.org Content-Type: multipart/alternative; boundary="------------080802080006030305050108" Cc: draft-ietf-tls-dtls-heartbeat.all@tools.ietf.org Subject: [secdir] secdir review of draft-ietf-tls-dtls-heartbeat-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 12:32:33 -0000 This is a multi-part message in MIME format. --------------080802080006030305050108 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. The draft introduces a Heartbeat Extension for TLS and DTLS. The Security Considerations sections states: "This document does not add any additional security considerations in addition to the ones given in [I-D.ietf-tls-rfc4347-bis] and [RFC5246]." I agree and have no concerns with the draft. Best regards, Tobias --------------080802080006030305050108 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.


The draft introduces a Heartbeat Extension for TLS and DTLS.

The Security Considerations sections states:
"This document does not add any additional security considerations in addition to the ones given in [I-D.ietf-tls-rfc4347-bis] and [RFC5246]."

I agree and have no concerns with the draft.

Best regards, Tobias

 --------------080802080006030305050108-- From nico@cryptonector.com Wed Oct 19 08:18:21 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 669AF21F8C63; Wed, 19 Oct 2011 08:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXOPYgnDcz1e; Wed, 19 Oct 2011 08:18:20 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id E5E3521F8C4B; Wed, 19 Oct 2011 08:18:20 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 4D8E358407D; Wed, 19 Oct 2011 08:18:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=kRg7wKrMVyDSXQ73H1CfsTgI0+52sqICB3XUukJj4KsD JaNFecxsjHvQqRNueCDcL+CHTqeItpGRcqq/WQRz3w0My3tnT+EDBml17agqxerZ AxcOtxSzP7A/pFiesM0LO0mCVuQeBWsf4OAPoCCxlYH1lgZDKnNPRMvqZHhSvAM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=QCrIVzYlHVLRdWAAHT/K6LpOH04=; b=GA1JFmNtyvO 7fi9zaXCXi04hI1zN16ok93Wk3VF//x0GIjSuAnGJSJ6fezqWA0yplUVuvCleN+O xoO75GYLE8cx2E2pE+FIl204xKZd8WQiM1jDoYCpO6ioD3rIuLgCfVJEKiu8s6c1 ScgkJ/xo1FJY52KBu4mOdswYMjKZD9Dk= Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id 9DBEA5840B2; Wed, 19 Oct 2011 08:14:20 -0700 (PDT) Received: by qyk34 with SMTP id 34so3067597qyk.10 for ; Wed, 19 Oct 2011 08:14:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.20.135 with SMTP id n7mr3710358pbe.41.1319037259058; Wed, 19 Oct 2011 08:14:19 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Wed, 19 Oct 2011 08:14:18 -0700 (PDT) In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1718181C1B@DFWEML501-MBX.china.huawei.com> References: <7AEB3D6833318045B4AE71C2C87E8E171817FEAA@DFWEML501-MBX.china.huawei.com> <7AEB3D6833318045B4AE71C2C87E8E1718181C1B@DFWEML501-MBX.china.huawei.com> Date: Wed, 19 Oct 2011 10:14:18 -0500 Message-ID: From: Nico Williams To: Leeyoung Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "iesg@ietf.org" , "draft-ietf-ccamp-wson-impairments@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Review of draft-ietf-ccamp-wson-impairments-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 15:18:21 -0000 On Tue, Oct 18, 2011 at 10:16 PM, Leeyoung wrote: > As you indicated in the latest response, this document is first of all in= formational and does not define any new protocols beyond the family of OSPF= -TE, RSVP-TE and PCEP. There are no new requirements caused by IA-RWA other= than the need for processing additional routing/signaling related data bey= ond the regular TE networks. > These additional data would not add any particular security requirements = in my opinion. The fact that this is an informational document doesn't mean there's no need to be thorough. On the contrary, since a beginner to the subject might start by reading the informational documents, this one's a good place to discuss security issues. > Anyhow, please see the following changes if you would be satisfied with t= hem. I'm happy with the proposed text. Thanks! Nico -- From rbarnes@bbn.com Wed Oct 19 11:19:41 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9212F1F0C63; Wed, 19 Oct 2011 11:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNSs2FIFrKNP; Wed, 19 Oct 2011 11:19:40 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id B5CC41F0C49; Wed, 19 Oct 2011 11:19:40 -0700 (PDT) Received: from ros-dhcp192-1-51-60.bbn.com ([192.1.51.60]:54155) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RGajs-000Iof-8Z; Wed, 19 Oct 2011 14:19:40 -0400 From: "Richard L. Barnes" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Oct 2011 14:19:38 -0400 Message-Id: <387C6403-9D7A-49C3-ABD0-CC2C9CEF10E4@bbn.com> To: secdir@ietf.org, The IESG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [secdir] secdir review of draft-ietf-ippm-metrictest-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 18:19:41 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes a process for evaluating performance measurement = documents. The security considerations correctly note that this = document does not raise any security considerations. --Richard= From tlyu@mit.edu Wed Oct 19 12:15:09 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D3F21F8C7E; Wed, 19 Oct 2011 12:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ay+la7hyJVc5; Wed, 19 Oct 2011 12:15:08 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by ietfa.amsl.com (Postfix) with ESMTP id A048F21F8C91; Wed, 19 Oct 2011 12:15:08 -0700 (PDT) X-AuditID: 1209190d-b7f726d0000008d1-c1-4e9f21bbf114 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id B3.31.02257.BB12F9E4; Wed, 19 Oct 2011 15:15:07 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id p9JJF6FJ028710; Wed, 19 Oct 2011 15:15:07 -0400 Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p9JJF2Rg024008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Oct 2011 15:15:03 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id p9JJF130004303; Wed, 19 Oct 2011 15:15:01 -0400 (EDT) To: iesg@ietf.org, secdir@ietf.org, draft-ietf-codec-guidelines.all@tools.ietf.org From: Tom Yu Date: Wed, 19 Oct 2011 15:15:01 -0400 Message-ID: Lines: 32 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFIsWRmVeSWpSXmKPExsUixCmqrbtbcb6fQc9UM4tX2y6xWMz4M5HZ 4sPChywOzB5Llvxk8vhy+TNbAFMUl01Kak5mWWqRvl0CV8bBdzPZC67xVDy58YapgXEzVxcj J4eEgInEpvkvmCBsMYkL99azdTFycQgJ7GOU2PjuJxOEs4FR4s7VT1CZK0wSjXu2QTldjBJv mi8zgvSLCERLrPvzEWyWsICFxIJJB9m7GDk42ASkJY4uLgMJswioSpxZsYoNxOYFKpnT1cEM YvMIcEqcnvWZBSIuKHFy5hMwm1lAS+LGv5dMExj5ZiFJzUKSWsDItIpRNiW3Sjc3MTOnODVZ tzg5MS8vtUjXSC83s0QvNaV0EyM42CR5dzC+O6h0iFGAg1GJh1eSc76fEGtiWXFl7iFGSQ4m JVFeRzmgEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHenW/m+QnxpiRWVqUW5cOkpDlYlMR5C3c4 +AkJpCeWpGanphakFsFkZTg4lCR4FYBRJSRYlJqeWpGWmVOCkGbi4AQZzgM03B2khre4IDG3 ODMdIn+KUZdje9ehk4xCLHn5ealS4rw6IEUCIEUZpXlwc2BJ4hWjONBbwrzSIFU8wAQDN+kV 0BImoCVHFeeCLClJREhJNTBe8Lv9c7M674u9RTU2hyaWpOyduFt2n1SpTmbJrxvf+NJ3tU5j 0FxuwaWgw3tdMm7R+YCnM1WcBV0k9a5Umkk2ykQvLeNY6cLblWyfLJNmtMRrOS+XcobAPM/q qxHMxdcVH305mZJ1YU9Y3wXJVKuPUun37VWO7P3oddfQbU46Y/LtKTd//FJiKc5INNRiLipO BABPvHSa7QIAAA== Subject: [secdir] secdir review of draft-ietf-codec-guidelines-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 19:15:09 -0000 This document gives procedural guidance on the development of codecs within the IETF. In its Security Considerations section, it says: The procedural guidelines for codec development do not have security considerations. However, the resulting codec needs to take appropriate security considerations into account, for example as outlined in [DOS] and [SECGUIDE]. I think that additionally, authors of codec specifications should consider what implementation vulnerabilities are likely to arise, and document them in the specification. As I recall, audio, video, and image codecs have a long history of implementation vulnerabilities shared among multiple implementations. These shared vulnerabilities could be due to the encodings being mostly binary in nature, sometimes with explicit length counts for arrays, inviting buffer overflows when implemented in languages such as C. (I have not extensively studied these vulnerabilities, but I'm sure other people have done so in much more detail.) Editorial: It's not clear what kinds of codecs are being considered. Text in the document implies that the focus is audio codecs rather than video or other codecs, but perhaps the document should clarify what kinds of codecs are in scope. I misinterpreted "RF license" as "radio-frequency license" initially, but a few clauses earlier, I found that "RF" is used to represent "royalty-free". As there are no other occurrences of "RF" with this meaning, consider writing it in expanded form in both places (possibly leaving the "RF" parenthetical for the first occurrence). From leeyoung@huawei.com Tue Oct 18 20:16:57 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F8C21F8783; Tue, 18 Oct 2011 20:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAiGSfR9QMwY; Tue, 18 Oct 2011 20:16:56 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id A368F21F877F; Tue, 18 Oct 2011 20:16:56 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTA00HQTMG7AW@usaga02-in.huawei.com>; Tue, 18 Oct 2011 22:16:55 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LTA002Q9MG7MC@usaga02-in.huawei.com>; Tue, 18 Oct 2011 22:16:55 -0500 (CDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 18 Oct 2011 20:16:51 -0700 Received: from DFWEML501-MBX.china.huawei.com ([10.124.31.87]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Tue, 18 Oct 2011 20:16:46 -0700 Date: Wed, 19 Oct 2011 03:16:46 +0000 From: Leeyoung In-reply-to: X-Originating-IP: [10.195.40.173] To: Nico Williams Message-id: <7AEB3D6833318045B4AE71C2C87E8E1718181C1B@DFWEML501-MBX.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US Thread-topic: Review of draft-ietf-ccamp-wson-impairments-07 Thread-index: AQHMiK1k/aUAVZm3CECvsX0ct9xRXZV4912AgAB+a4CACZDzwA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <7AEB3D6833318045B4AE71C2C87E8E171817FEAA@DFWEML501-MBX.china.huawei.com> X-Mailman-Approved-At: Wed, 19 Oct 2011 12:25:17 -0700 Cc: "iesg@ietf.org" , "draft-ietf-ccamp-wson-impairments@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Review of draft-ietf-ccamp-wson-impairments-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 03:16:57 -0000 SGkgTmljb2xlLA0KDQpBcyB5b3UgaW5kaWNhdGVkIGluIHRoZSBsYXRlc3QgcmVzcG9uc2UsIHRo aXMgZG9jdW1lbnQgaXMgZmlyc3Qgb2YgYWxsIGluZm9ybWF0aW9uYWwgYW5kIGRvZXMgbm90IGRl ZmluZSBhbnkgbmV3IHByb3RvY29scyBiZXlvbmQgdGhlIGZhbWlseSBvZiBPU1BGLVRFLCBSU1ZQ LVRFIGFuZCBQQ0VQLiBUaGVyZSBhcmUgbm8gbmV3IHJlcXVpcmVtZW50cyBjYXVzZWQgYnkgSUEt UldBIG90aGVyIHRoYW4gdGhlIG5lZWQgZm9yIHByb2Nlc3NpbmcgYWRkaXRpb25hbCByb3V0aW5n L3NpZ25hbGluZyByZWxhdGVkIGRhdGEgYmV5b25kIHRoZSByZWd1bGFyIFRFIG5ldHdvcmtzLiAN ClRoZXNlIGFkZGl0aW9uYWwgZGF0YSB3b3VsZCBub3QgYWRkIGFueSBwYXJ0aWN1bGFyIHNlY3Vy aXR5IHJlcXVpcmVtZW50cyBpbiBteSBvcGluaW9uLiANCg0KQW55aG93LCBwbGVhc2Ugc2VlIHRo ZSBmb2xsb3dpbmcgY2hhbmdlcyBpZiB5b3Ugd291bGQgYmUgc2F0aXNmaWVkIHdpdGggdGhlbS4g DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgZG9jdW1lbnQgZGlzY3Vzc2VzIGEgbnVtYmVyIG9mIGNv bnRyb2wgcGxhbmUgYXJjaGl0ZWN0dXJlcyB0aGF0DQppbmNvcnBvcmF0ZSBrbm93bGVkZ2Ugb2Yg aW1wYWlybWVudHMgaW4gb3B0aWNhbCBuZXR3b3Jrcy4gSWYgc3VjaA0KYXJjaGl0ZWN0dXJlIGlz IHB1dCBpbnRvIHVzZSB3aXRoaW4gYSBuZXR3b3JrIGl0IHdpbGwgYnkgaXRzIG5hdHVyZQ0KY29u dGFpbiBkZXRhaWxzIG9mIHRoZSBwaHlzaWNhbCBjaGFyYWN0ZXJpc3RpY3Mgb2YgYW4gb3B0aWNh bA0KbmV0d29yay4gU3VjaCBpbmZvcm1hdGlvbiB3b3VsZCBuZWVkIHRvIGJlIHByb3RlY3RlZCBm cm9tIGludGVudGlvbmFsDQpvciB1bmludGVudGlvbmFsIGRpc2Nsb3N1cmUgc2ltaWxhciB0byBv dGhlciBuZXR3b3JrIGluZm9ybWF0aW9uIHVzZWQNCndpdGhpbiBpbnRyYS1kb21haW4gcHJvdG9j b2xzLg0KDQpUaGlzIGRvY3VtZW50IGRvZXMgbm90IHJlcXVpcmUgY2hhbmdlcyB0byB0aGUgc2Vj dXJpdHkgbW9kZWxzIHdpdGhpbg0KR01QTFMgYW5kIGFzc29jaWF0ZWQgcHJvdG9jb2xzLiAgVGhh dCBpcywgdGhlIE9TUEYtVEUsIFJTVlAtVEUsIGFuZA0KUENFUCBzZWN1cml0eSBtb2RlbHMgY291 bGQgYmUgb3BlcmF0ZWQgdW5jaGFuZ2VkLiBIb3dldmVyLCBzYXRpc2Z5aW5nDQp0aGUgcmVxdWly ZW1lbnRzIGZvciBpbXBhaXJtZW50IGluZm9ybWF0aW9uIGRpc3NlbWluYXRpb24gdXNpbmcgdGhl IGV4aXN0aW5nDQpwcm90b2NvbHMgbWF5IHNpZ25pZmljYW50bHkgYWZmZWN0IHRoZSBsb2FkaW5n IG9mIHRob3NlIHByb3RvY29scy4NClRoaXMgbWF5IG1ha2UgdGhlIG9wZXJhdGlvbiBvZiB0aGUg bmV0d29yayBtb3JlIHZ1bG5lcmFibGUgdG8gYWN0aXZlIGF0dGFja3MgDQpzdWNoIGFzIGluamVj dGlvbnMsIGltcGVyc29uYXRpb24sIGFuZCBNSVRNcy4gVGhlcmVmb3JlLCBhZGRpdGlvbmFsIGNh cmUgbWF5YmUNCnJlcXVpcmVkIHRvIGVuc3VyZSB0aGF0IHRoZSBwcm90b2NvbHMgYXJlIHNlY3Vy ZSBpbiB0aGUgaW1wYWlybWVudC1hd2FyZQ0KV1NPTiBlbnZpcm9ubWVudC4NCg0KRnVydGhlcm1v cmUsIHRoZSBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGRpc3RyaWJ1dGVkIGluIG9yZGVyIHRvDQph ZGRyZXNzIGltcGFpcm1lbnQgaW5mb3JtYXRpb24gcmVwcmVzZW50cyBhIGRpc2Nsb3N1cmUgb2Yg bmV0d29yaw0KY2FwYWJpbGl0aWVzIHRoYXQgYW4gb3BlcmF0b3IgbWF5IHdpc2ggdG8ga2VlcCBw cml2YXRlLiBDb25zaWRlcmF0aW9uDQpzaG91bGQgYmUgZ2l2ZW4gdG8gc2VjdXJpbmcgdGhpcyBp bmZvcm1hdGlvbi4gIEZvciBhIGdlbmVyYWwgZGlzY3Vzc2lvbg0Kb24gTVBMUy0gYW5kIEdNUExT LXJlbGF0ZWQgc2VjdXJpdHkgaXNzdWVzLCBzZWUgdGhlIE1QTFMvR01QTFMgc2VjdXJpdHkNCmZy YW1ld29yayBbUkZDNTkyMF0uDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkJlc3QgUmVnYXJk cywNCllvdW5nDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBOaWNvIFdpbGxp YW1zIFttYWlsdG86bmljb0BjcnlwdG9uZWN0b3IuY29tXSANClNlbnQ6IFdlZG5lc2RheSwgT2N0 b2JlciAxMiwgMjAxMSAxOjAxIFBNDQpUbzogTGVleW91bmcNCkNjOiBzZWNkaXJAaWV0Zi5vcmc7 IGllc2dAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtY2NhbXAtd3Nvbi1pbXBhaXJtZW50c0B0b29scy5p ZXRmLm9yZw0KU3ViamVjdDogUmU6IFJldmlldyBvZiBkcmFmdC1pZXRmLWNjYW1wLXdzb24taW1w YWlybWVudHMtMDcNCg0KT24gV2VkLCBPY3QgMTIsIDIwMTEgYXQgMTI6MzAgUE0sIExlZXlvdW5n IDxsZWV5b3VuZ0BodWF3ZWkuY29tPiB3cm90ZToNCj4gTW9kaWZpZWQgc2VjdXJpdHkgc2VjdGlv biByZWFkczoNCj4NCj4gwqAgVGhpcyBkb2N1bWVudCBkaXNjdXNzZXMgYSBudW1iZXIgb2YgY29u dHJvbCBwbGFuZSBhcmNoaXRlY3R1cmVzIHRoYXQNCj4gwqAgaW5jb3Jwb3JhdGUga25vd2xlZGdl IG9mIGltcGFpcm1lbnRzIGluIG9wdGljYWwgbmV0d29ya3MuIElmIHN1Y2gNCj4gwqAgYXJjaGl0 ZWN0dXJlIGlzIHB1dCBpbnRvIHVzZSB3aXRoaW4gYSBuZXR3b3JrIGl0IHdpbGwgYnkgaXRzIG5h dHVyZQ0KPiDCoCBjb250YWluIGRldGFpbHMgb2YgdGhlIHBoeXNpY2FsIGNoYXJhY3RlcmlzdGlj cyBvZiBhbiBvcHRpY2FsDQo+IMKgIG5ldHdvcmsuIFN1Y2ggaW5mb3JtYXRpb24gd291bGQgbmVl ZCB0byBiZSBwcm90ZWN0ZWQgZnJvbSBpbnRlbnRpb25hbA0KPiDCoCBvciB1bmludGVudGlvbmFs IGRpc2Nsb3N1cmUgc2ltaWxhciB0byBvdGhlciBuZXR3b3JrIGluZm9ybWF0aW9uIHVzZWQNCj4g wqAgd2l0aGluIGludHJhLWRvbWFpbiBwcm90b2NvbHMuDQo+DQo+IMKgIFRoaXMgZG9jdW1lbnQg ZG9lcyBub3QgcmVxdWlyZSBjaGFuZ2VzIHRvIHRoZSBzZWN1cml0eSBtb2RlbHMgd2l0aGluDQo+ IMKgIEdNUExTIGFuZCBhc3NvY2lhdGVkIHByb3RvY29scy4gwqBUaGF0IGlzLCB0aGUgT1NQRi1U RSwgUlNWUC1URSwgYW5kDQo+IMKgIFBDRVAgc2VjdXJpdHkgbW9kZWxzIGNvdWxkIGJlIG9wZXJh dGVkIHVuY2hhbmdlZC4gSG93ZXZlciwgc2F0aXNmeWluZw0KPiDCoCB0aGUgcmVxdWlyZW1lbnRz IGZvciBpbXBhaXJtZW50IGluZm9ybWF0aW9uIGRpc3NlbWluYXRpb24gdXNpbmcgdGhlIGV4aXN0 aW5nDQo+IMKgIHByb3RvY29scyBtYXkgc2lnbmlmaWNhbnRseSBhZmZlY3QgdGhlIGxvYWRpbmcg b2YgdGhvc2UgcHJvdG9jb2xzLg0KPiDCoCBUaGlzIG1heSBtYWtlIHRoZSBvcGVyYXRpb24gb2Yg dGhlIG5ldHdvcmsgbW9yZSB2dWxuZXJhYmxlIHRvIGRlbmlhbC0NCj4gwqAgb2Ytc2VydmljZSBh dHRhY2tzIG9yIGFjdGl2ZSBhdHRhY2tzLiDCoFRoZXJlZm9yZSwgYWRkaXRpb25hbCBjYXJlIG1h eWJlDQo+IMKgIHJlcXVpcmVkIHRvIGVuc3VyZSB0aGF0IHRoZSBwcm90b2NvbHMgYXJlIHNlY3Vy ZSBpbiB0aGUgaW1wYWlybWVudC1hd2FyZQ0KPiDCoCBXU09OIGVudmlyb25tZW50Lg0KPg0KPiDC oCBGdXJ0aGVybW9yZSwgdGhlIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gZGlzdHJpYnV0ZWQgaW4g b3JkZXIgdG8NCj4gwqAgYWRkcmVzcyBpbXBhaXJtZW50IGluZm9ybWF0aW9uIHJlcHJlc2VudHMg YSBkaXNjbG9zdXJlIG9mIG5ldHdvcmsNCj4gwqAgY2FwYWJpbGl0aWVzIHRoYXQgYW4gb3BlcmF0 b3IgbWF5IHdpc2ggdG8ga2VlcCBwcml2YXRlLiBDb25zaWRlcmF0aW9uDQo+IMKgIHNob3VsZCBi ZSBnaXZlbiB0byBzZWN1cmluZyB0aGlzIGluZm9ybWF0aW9uLiDCoEZvciBhIGdlbmVyYWwgZGlz Y3Vzc2lvbg0KPiDCoCBvbiBNUExTLSBhbmQgR01QTFMtcmVsYXRlZCBzZWN1cml0eSBpc3N1ZXMs IHNlZSB0aGUgTVBMUy9HTVBMUyBzZWN1cml0eQ0KPiDCoCBmcmFtZXdvcmsgW1JGQzU5MjBdLg0K Pg0KPiBQbGVhc2Ugc3VnZ2VzdCBzb21lIHRleHRzIGlmIHRoZXNlIGFyZSBub3Qgc2F0aXNmYWN0 b3J5IHRvIHlvdXIgbmVlZC4gVGhhbmtzLg0KDQpJJ20gbm90IGNvbmNlcm5lZCBhYm91dCBkZW5p YWwgb2Ygc2VydmljZSBhdHRhY2tzIGluIHBhcnRpY3VsYXIgYXMgaXQNCmlzIG9mdGVuIHRoZSBj YXNlIHRoYXQgdGhlcmUgYXJlIGRlbmlhbCBvZiBzZXJ2aWNlIGF0dGFjayBzdXJmYWNlcw0KYWJv dXQgd2hpY2ggdGhlcmUncyBsaXR0bGUgd2UgY2FuIGRvLiAgV2hhdCBJJ20gY29uY2VybmVkIGFi b3V0IGlzDQp3aGV0aGVyIHRoZSBmcmFtZXdvcmsgY2FuIGhhbmRsZSBhY3RpdmUgYXR0YWNrcyBz dWNoIGFzIGluamVjdGlvbnMsDQppbXBlcnNvbmF0aW9uLCBhbmQgTUlUTXMuICBUaGUgcmVmZXJl bmNlIHRvIE9TUEYgYW5kIGZyaWVuZHMgaXMNCnByb2JhYmx5IHN1ZmZpY2llbnQgaW4gdGhpcyBy ZWdhcmQgZm9yIG1lIHRvIGZpZ3VyZSBvdXQgYW4gYW5zd2VyLA0KdGhvdWdoIHNheWluZyBzb21l dGhpbmcgdG8gdGhlIGVmZmVjdCB0aGF0IGEpIHlvdSByZWx5IG9uIHN1Y2gNCnByb3RvY29scyBm b3Igc2VjdXJpdHkgKHlvdXIgcHJvcG9zZWQgY2hhbmdlIHNheXMgc28pLCBhbmQgYikgdGhhdA0K dGhvc2UgcHJvdG9jb2xzIG1lZXQgd2hhdGV2ZXIgeW91IHRoaW5rIHRoZSByZXF1aXJlbWVudHMg b3VnaHQgdG8gYmUNCmZvciBJQS1SV0EuICBPaCwgYW5kIEkgc3VwcG9zZSB5b3Ugc2hvdWxkIGMp IGxpc3Qgd2hhdCB5b3UgdGhpbmsgdGhvc2UNCnJlcXVpcmVtZW50cyBhcmUuICBPZiBjb3Vyc2Us IGlmIHRoZXNlIHByb3RvY29scyBkb24ndCB0b2RheSBtZWV0DQp0aG9zZSByZXF1aXJlbWVudHMs IHRoZW4gdGhhdCdkIGJlIGEgcHJvYmxlbSwgYnV0IEkgc3VzcGVjdCB0aGF0IHdvbid0DQpwcm92 ZSB0byBiZSB0aGUgY2FzZS4NCg0KVGhpcyBpcyBvbmUgb2YgdGhvc2Ugb2NjYXNpb25zIHdoZXJl IGl0J3MgZ29vZCB0byBhc2sgIndoYXQncyB5b3VyDQp0aHJlYXQgbW9kZWwiIHRvby4gIE15IGd1 ZXNzIGlzIHRoYXQgdGhlcmUgaXNuJ3QgdGhhdCBtdWNoIG9mIGEgdGhyZWF0DQpmcm9tIGVhdmVz ZHJvcHBpbmcgb24gSUEtUldBLCBzbyBwYXNzaXZlIGF0dGFja2VycyBhcmUgbm90IHBhcnQgb2Yg dGhlDQp0aHJlYXQgbW9kZWwuICBXaGF0IGFjdGl2ZSBhdHRhY2tzIG1pZ2h0IGJlIGluIHRoZSB0 aHJlYXQgbW9kZWw/DQoNCk5pY28NCi0tDQo= From mcgrew@cisco.com Wed Oct 19 15:37:02 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F9421F8A55; Wed, 19 Oct 2011 15:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.599 X-Spam-Level: X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8fSwI0yiJgp; Wed, 19 Oct 2011 15:37:01 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id A10F821F8A4E; Wed, 19 Oct 2011 15:37:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=9104; q=dns/txt; s=iport; t=1319063821; x=1320273421; h=cc:message-id:from:to:in-reply-to:mime-version:subject: date:references; bh=+n+DyLpz4mcVRWKNC0fC5VU3G/jD2fHEILYq3KGHh1Y=; b=kFIo3t0ds3vXwF+vh9Jubsfe8PD7gB/TZUJpgVUyelIjD/ez3TjaU06c yZbiHbqyLVUUdfIpQ4DSBS/TE5HozfiXuy791rOICTEmNTBwqAWQviEw5 0OVmMXxarNNn2FphNpwHEMo2Gacw6gOFCqnH/mtyShPLLtvW7YG5ikvuF o=; X-Files: smime.p7s : 3497 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAERQn06rRDoG/2dsb2JhbABEqQKBBYFuAQEBAQIBAQEBDwFbCwULCy0ZAiUwBxIih14ImAoBnkuEf4I7YQSIAot8kXc X-IronPort-AV: E=Sophos;i="4.69,374,1315180800"; d="p7s'?scan'208";a="8599903" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 19 Oct 2011 22:37:01 +0000 Received: from stealth-10-32-254-214.cisco.com (stealth-10-32-254-214.cisco.com [10.32.254.214]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9JMb0MW002337; Wed, 19 Oct 2011 22:37:00 GMT Message-Id: From: David McGrew To: draft-ietf-codec-guidelines.all@tools.ietf.org, secdir@ietf.org In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-281--693280101; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 19 Oct 2011 15:36:59 -0700 References: X-Mailer: Apple Mail (2.936) Cc: "iesg@ietf.org IESG" Subject: Re: [secdir] secdir review of draft-ietf-codec-guidelines-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 22:37:02 -0000 --Apple-Mail-281--693280101 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Oct 19, 2011, at 12:15 PM, Tom Yu wrote: > This document gives procedural guidance on the development of codecs > within the IETF. In its Security Considerations section, it says: > > The procedural guidelines for codec development do not have > security considerations. However, the resulting codec needs to > take appropriate security considerations into account, for example > as outlined in [DOS] and [SECGUIDE]. That text implies that there are no security considerations in codec design, and that is not true. One important consideration is that variable bit rate codecs can leak information through packet lengths; this is discussed in draft-ietf-avtcore-srtp-vbr-audio-03, which I suggest be referenced. It is important to note that this issue is *not* specific to SRTP; it applies to any implementation of any encryption protocol in which the length of the plaintext can be inferred from that of the ciphertext (in other words, most implementations of most protocols). There are actually a lot of security considerations in codec designs. VBR codecs can save bandwidth by making some packets shorter, but having plaintext-dependent packet lengths will introduce a side channel. Packet lengths could be made more uniform using a short buffering strategy, but that would introduce latency. Security is directly in tension with bandwidth and latency. It is potentially valuable for codec designers to take this into consideration, because the codec design is the only place where we have a chance to resolve this tension. (We can mitigate the VBR packet length side channel by padding out packets, but that negates most of the VBR benefits.) Note that the SPEEX codec that was shown to be most vulnerable in the [spot-me] reference in ietf-avtcore-srtp-vbr-audio-03 is particularly bad security-wise because it maps phonemes to codewords (and thus there is an association between phonemes and packet lengths). I would guess that it could be re-designed to be more leak-resistant without losing all of its bandwidth efficiency. (For example, if it had fewer codeword lengths, that would make it harder to distinguish outputs. For bandwidth saving, you want to shave every byte off. To prevent a side-channel though, you will sometimes want to leave in a padding byte so that two different codewords have the same length.) David > > I think that additionally, authors of codec specifications should > consider what implementation vulnerabilities are likely to arise, and > document them in the specification. As I recall, audio, video, and > image codecs have a long history of implementation vulnerabilities > shared among multiple implementations. > > These shared vulnerabilities could be due to the encodings being > mostly binary in nature, sometimes with explicit length counts for > arrays, inviting buffer overflows when implemented in languages such > as C. (I have not extensively studied these vulnerabilities, but I'm > sure other people have done so in much more detail.) > > Editorial: > > It's not clear what kinds of codecs are being considered. Text in the > document implies that the focus is audio codecs rather than video or > other codecs, but perhaps the document should clarify what kinds of > codecs are in scope. > > I misinterpreted "RF license" as "radio-frequency license" initially, > but a few clauses earlier, I found that "RF" is used to represent > "royalty-free". As there are no other occurrences of "RF" with this > meaning, consider writing it in expanded form in both places (possibly > leaving the "RF" parenthetical for the first occurrence). > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --Apple-Mail-281--693280101 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPDCCA5ow ggKCoAMCAQICAWQwCwYJKoZIhvcNAQEFMG0xFTATBgNVBAMMDERhdmlkIE1jR3JldzETMBEGA1UE CAwKQ2FsaWZvcm5pYTELMAkGA1UEBhMCVVMxETAPBgNVBAcMCFNhbiBKb3NlMR8wHQYJKoZIhvcN AQkBFhBtY2dyZXdAY2lzY28uY29tMB4XDTA4MTIwOTIyMDMzMFoXDTA5MTIwOTIyMDMzMFowbTEV MBMGA1UEAwwMRGF2aWQgTWNHcmV3MRMwEQYDVQQIDApDYWxpZm9ybmlhMQswCQYDVQQGEwJVUzER MA8GA1UEBwwIU2FuIEpvc2UxHzAdBgkqhkiG9w0BCQEWEG1jZ3Jld0BjaXNjby5jb20wggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDh5WR1gATRK4ubbWwmG2T/XTUeVc2FAxnmtoYy00fM 5jp3DYFXHkWj4Cl8RVVfAJxP/2PhKsTl0qx2b7N9pIZZa6BaODEyJ8yVMRHloHrpzHeU8DIrst/H SFVkcJvl3p9LFD42BCvznzQ48VxnWX68OCk7GAwg6XoKMY8Z1F70PVvcZ0JcbnDuKx0efQ+P74uY UdpjRYSXb2xJUziGs5k6b1kTr5754B3tnYCGkum49YAbONpsOL4R+e4HNNrkVTx254ggrcDb1GDr IpZYCSPh6lZWwOp0XBoJiLYEKXuBf/jSNEv15/Kt/Uu5Oh8jUBxkBHGAVZuaVu25s3Zk9waLAgMB AAGjRzBFMA4GA1UdDwEB/wQEAwIEsDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDBDAbBgNVHREEFDAS gRBtY2dyZXdAY2lzY28uY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCbD+Y6Yu0d5FZHSGd7WTP7vlo+ SE2rF0YzqvcMYrEuu6VBbkOFGfq3leu2WVJinXYQwAgaZ7vJpH43/bjDIK4YuOqAUv57ZQjtCJ6W 6b0rdG8/A2cWcGoDjqmjAGJ4TC8oMIc0h33QPEjsGdon0nsV0QCxrgWcWEjFSzlE6kbR4pT3yA2V zo7byNoDoYpH5otGH0/cRQM9i6ENTytxzczPeNTt2uaMp/3s8MZ5W/0Yz8U/yy5bcS5TGrqgTvN7 mI+nngoJ4TNKapSpdSqCyEK86z51VWtRRFyBosLQsNhMYb7HWzW/mIQCG0SygOVjUcRPKxhYUokR gCmxsHqcL1uMMIIFmjCCA4ICCQD8XsAekzPPFDANBgkqhkiG9w0BAQUFADCBjjELMAkGA1UEBhMC VVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBKb3NlMRwwGgYDVQQKExNDaXNj byBTeXN0ZW1zLCBJbmMuMRgwFgYDVQQDEw9EYXZpZCBBLiBNY0dyZXcxHzAdBgkqhkiG9w0BCQEW EG1jZ3Jld0BjaXNjby5jb20wHhcNMTEwMzE0MTgwOTAyWhcNMTMwMzEzMTgwOTAyWjCBjjELMAkG A1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBKb3NlMRwwGgYDVQQK ExNDaXNjbyBTeXN0ZW1zLCBJbmMuMRgwFgYDVQQDEw9EYXZpZCBBLiBNY0dyZXcxHzAdBgkqhkiG 9w0BCQEWEG1jZ3Jld0BjaXNjby5jb20wggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDL KlHKr3WA3U7qp3aPD6XqP+nSwKGxXYA2Sn/rgpxo34tTS9CpCqhQUU7oNxGJ1/534P8GhpwP8Ufg HVqNa6wDAWUsHJBRdqLT2qqjnFFmEa4G7V2Hmis6nbAnQ+vu9TdZVMDJDEakTiAh6XCgzGRWYTiJ XgIn6UT+aIWQ63VRVTnOQVN+fhzhoKzmd3opwHiavo/gfavu/2t4S/hSLTZikroi0h68df4w3nRo b/1ksC+NVbG8LHnHQ3fjyhdrxZwl9aH2k1hNS8LosET9rIQbzOvwkueC/9xYBjfr4yZcTlpDtixZ fh26rg/AFLkzXrtBBt4Sqi3niI+zWTXUOx1JMwFKEQBTn2z+RYPi9Q1VWCIg93Rh5RT6nkH/ZOyp HbmElrYoThYH+duDASssKyX3yXRu4F6UMoC897ynR7g9aV3RLF9PevN4k8UeIQQR6e0+aFvoo/zm xKYCCZIGnqWmMa6cnlzKWoMD5sTu+ILDk7Ty67+7LijhJxCO14erj4/XYmY1uvSuN/axd587emXu BmdWI3sDQoC1l/H7QxRROoONTWK5wAEGpNUUMllJmYDW//LxIiDhEsKC6wc1rOIhHy3FuykMA1BI xkIVaqOwYvokVdH/jXwpZNHoMEhS6hXCvWKt4mwIEJQRQsYGSC/TAB25D5cTkVmo/RCE/sTzXQID AQABMA0GCSqGSIb3DQEBBQUAA4ICAQCUtnHAg+JXVgQPFwz2hiIdD+MB14I3vThsphpEkD4PgdJz /KbIegcEe60ZaOvvDYVcLnY0dE3Z6kSXSS8Y5GCoXh9gKTL1mmzT+Rux0gFgbQHHd9xtnIeEUjuq E2MvznfgipTCvEIAqTZaonvilTeJJie4oEAPHX8Jjy7De3HM11bjbq4qZJhWv/9RE8CG08YUFmC3 /LQcGEdo4qSH16juGst5NuacAqg3Hugt9LCwLiSwoTpLXfhykd58kvTmPawrTszstDOvQAR1Q3TY zMw3/cbaKN2b/WMkxYZFwxmzwy7pYYgnkGPf3ehxfrwEmVzlzXUnMZVTqyk7KlF5sUE1ahS8mu1k jKOyGtOOPuFmGydDTFHHAHLGO5I8zoR3qfzeeOLEqr0tdG8ye7ZprVZyYVEa2EMUBl0vyH0+aAOy oPP5mba7eDyZLs357Xy8277x/2t2Zmcu6IkYdkQ3/yIfAb/99Ws7020X+zyaiiImsHangUmw9DKy LirSIeI03ZFcyEy8pMFFoIZFhg3/DM9md8YcUDubJjneWQaU5PpskcjfmOTzzhGag23ow9vw+upX mLVErB5jB2O0WCOMZZbAC837+Od3nAJhaIAXtk7OU67KbOgM/tfph71ZS/OhfQnu3+o9FQJwCTKM U+3z3+45mPYuaPT5+MPyGep06MXlczGCBC8wggQrAgEBMIGcMIGOMQswCQYDVQQGEwJVUzETMBEG A1UECBMKQ2FsaWZvcm5pYTERMA8GA1UEBxMIU2FuIEpvc2UxHDAaBgNVBAoTE0Npc2NvIFN5c3Rl bXMsIEluYy4xGDAWBgNVBAMTD0RhdmlkIEEuIE1jR3JldzEfMB0GCSqGSIb3DQEJARYQbWNncmV3 QGNpc2NvLmNvbQIJAPxewB6TM88UMAkGBSsOAwIaBQCgggFnMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTAxOTIyMzY2MFowIwYJKoZIhvcNAQkEMRYEFHjHc8WZ Jh8eRzvtgKbX6fDfNfCEMIGBBgkrBgEEAYI3EAQxdDByMG0xFTATBgNVBAMMDERhdmlkIE1jR3Jl dzETMBEGA1UECAwKQ2FsaWZvcm5pYTELMAkGA1UEBhMCVVMxETAPBgNVBAcMCFNhbiBKb3NlMR8w HQYJKoZIhvcNAQkBFhBtY2dyZXdAY2lzY28uY29tAgFkMIGDBgsqhkiG9w0BCRACCzF0oHIwbTEV MBMGA1UEAwwMRGF2aWQgTWNHcmV3MRMwEQYDVQQIDApDYWxpZm9ybmlhMQswCQYDVQQGEwJVUzER MA8GA1UEBwwIU2FuIEpvc2UxHzAdBgkqhkiG9w0BCQEWEG1jZ3Jld0BjaXNjby5jb20CAWQwDQYJ KoZIhvcNAQEBBQAEggIAC0MtgMiiD0fybF0zE4mXWNE3zW2lsQPYLHG5zup1Tg5YZwNM1L/N61WW QLMM0UcnfCJKzgGs3hCfK9ROXZtbWaZ8lnBDseVnwVeKGeYy6OVRqSbpSKI5o+mxFS2okTMjvwKc VlZfIK4dNlNCM3jN3NwzJyDXkCj2rmUUvTkFITDQQl+JU+xUNfXev6RIc/yxbCSwBLC/IUFHHzvd bmkB8eEDBVyWzFvqf0y/ln7am9Up8D3WiuGHhaXbkLjVwCsIWoBHbsPuOGmMHuzlJ3/422NdhyFu yH2LVPLI/cwBDip82Sr9MkAzLI3TVDZwQavuhA263O7vCiFlRwEGJSgsUVViLZu+JTAtZByAZ8I2 Tyu8kzLK17307AWTwzm3TEIYnTkwb1XVvRzEVe4C0uwb2x4bVCWDZWJNpUukdDLljFo4gwjaxvQL BPTuv+L0YRYCxdkKDF3KrfPwvUhGz05AkPjxV8yz+fxix41OuHzUa6nhTcVqYmSs1Fv5zjpOWNtg gEv6Hi87NvX4FxVrUjY/OZw6MY/yqlfSMOjEkWSyt9eVCwrDRLCMjeCIWsXVBJHvtPqGGHe8bHXk 92mUfm1etjlCFrLNJeTW7EbPX5/DjtloCgq9QMel3CPfgfNbKyySqDyNR+GazCIVDMztqzChyeII RlZkM54asesaKTWN3zIAAAAAAAA= --Apple-Mail-281--693280101-- From jhutz@cmu.edu Wed Oct 19 17:06:43 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E812721F88A0; Wed, 19 Oct 2011 17:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7+1AMIvk9gP; Wed, 19 Oct 2011 17:06:43 -0700 (PDT) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id 40BA821F889A; Wed, 19 Oct 2011 17:06:43 -0700 (PDT) Received: from [128.2.216.42] (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id p9K06efR020212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Oct 2011 20:06:40 -0400 (EDT) From: Jeffrey Hutzelman To: David McGrew In-Reply-To: <11222_1319063825_p9JMb3Dt016165_F9F22981-194E-4E31-8F16-D16228FA2102@cisco.com> References: <11222_1319063825_p9JMb3Dt016165_F9F22981-194E-4E31-8F16-D16228FA2102@cisco.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 19 Oct 2011 20:06:40 -0400 Message-ID: <1319069200.16180.65.camel@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: "iesg@ietf.org IESG" , secdir@ietf.org, draft-ietf-codec-guidelines.all@tools.ietf.org, jhutz@cmu.edu Subject: Re: [secdir] secdir review of draft-ietf-codec-guidelines-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 00:06:44 -0000 On Wed, 2011-10-19 at 15:36 -0700, David McGrew wrote: > On Oct 19, 2011, at 12:15 PM, Tom Yu wrote: > > > This document gives procedural guidance on the development of codecs > > within the IETF. In its Security Considerations section, it says: > > > > The procedural guidelines for codec development do not have > > security considerations. However, the resulting codec needs to > > take appropriate security considerations into account, for example > > as outlined in [DOS] and [SECGUIDE]. > > That text implies that there are no security considerations in codec > design No, it certainly does not. It implies that there are no security considerations in _the procedural guidelines_. This is a process document, and having just read large parts of it, I agree with the statement as written. That said, I would not be opposed to seeing this section grow to include a list of specific security considerations that codec specificiations proposed under this process must address. -- Jeff From shanna@juniper.net Thu Oct 20 03:04:39 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC1E121F8BA6; Thu, 20 Oct 2011 03:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.59 X-Spam-Level: X-Spam-Status: No, score=-105.59 tagged_above=-999 required=5 tests=[AWL=1.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6N4cGUxzZ5je; Thu, 20 Oct 2011 03:04:39 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id E333F21F8BA4; Thu, 20 Oct 2011 03:04:38 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP; Thu, 20 Oct 2011 03:04:39 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 20 Oct 2011 03:00:32 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 20 Oct 2011 06:00:31 -0400 From: Stephen Hanna To: "secdir@ietf.org" , "ietf@ietf.org" Date: Thu, 20 Oct 2011 06:00:29 -0400 Thread-Topic: secdir review of draft-ietf-vcarddav-kind-app-00.txt Thread-Index: AcyPDxkDxYHMlKhpR9u8exbF6CFuFA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-vcarddav-kind-app.all@tools.ietf.org" Subject: [secdir] secdir review of draft-ietf-vcarddav-kind-app-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 10:04:39 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines a new value for the vCard kind property: application. This value is to be used for vCards that represent software applications. The Security Considerations section of this document states: Use of vCards to represent software applications is not envisioned to introduce security considerations beyond those specified for vCards in general as described in [VCARD]. However, the Security Considerations section of [VCARD] doesn't seem adequate to the task. It merely points out that vCards don't have any security protections and therefore SHOULD be transported over a secure mechanism such as S/MIME or PGP if security is a concern. This advice may be adequate if the vCard is only used to transmit contact information for a person but it's generally not adequate when the vCard contains information about a software application. For example, this draft suggests that the KEY property can be used to convey a public key associated with an application. What a weak way to convey a public key! Will the recipient be able to determine whether the key is accurate? How might the key be revoked if necessary? No provisions are made for this. Other vCard properties such as URL may cause problems if malicious. Without proper security protections, the application vCard kind seems like a great tool for phishing and social engineering. Attackers can forge an email apparently from a trusted party, including an application vCard and instructions to click on it to see something cool. A naive email client may easily decide that clicking on an application vCard should run the application referenced in the vCard or visit the URL in the vCard or whatever. I suggest that the Security Considerations section of the draft be updated to include specific warnings that the contents of an application vCard should be considered untrustworthy and dangerous unless they have been securely delivered from a trustworthy source. Even then, there's a real possibility that the source may have been compromised before the vCard was sent. So information obtained from vCards should not be regarded as ipso facto trustworthy. Software should not act on information contained in a vCard unless there's a strong reason to believe it's accurate. And the KEY property SHOULD NOT be used for an application. Instead, more robust techniques for managing software public keys should be used. Thanks, Steve From mcgrew@cisco.com Thu Oct 20 04:44:28 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD6821F8AE6; Thu, 20 Oct 2011 04:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.932 X-Spam-Level: X-Spam-Status: No, score=-105.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIlucs3VgaMR; Thu, 20 Oct 2011 04:44:27 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id DF9B921F86A6; Thu, 20 Oct 2011 04:44:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=9688; q=dns/txt; s=iport; t=1319111067; x=1320320667; h=cc:message-id:from:to:in-reply-to:mime-version:subject: date:references; bh=ndd15EdEwLdNQBVewsjSnHCtp4FcIyuKGpfOnhrUE6k=; b=ItTB/eSXnyWV770g2Rt7F3fYgBZqQyrrAEAee2q9iPksNQQ4GDsZlhFp Dw9g8s4HlWYfl5S0tmveajQC2moz71okHex+8KudJcbORAXNbpnkuy7tm y+aXZJCtL6l6szF41ngL9G/9Fao9KjrvBcdVt8986kKNh0egITobB5eKu g=; X-Files: smime.p7s : 3497 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGoJoE6rRDoG/2dsb2JhbABDqRaBBYFuAQEBAwEBAQEPAVsLBQsLGC4CJTAGEyKHXgiXHgGeOIdIYQSIA4t9kXc X-IronPort-AV: E=Sophos;i="4.69,378,1315180800"; d="p7s'?scan'208";a="8680321" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 20 Oct 2011 11:44:21 +0000 Received: from stealth-10-32-254-214.cisco.com (stealth-10-32-254-214.cisco.com [10.32.254.214]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9KBiKJt030806; Thu, 20 Oct 2011 11:44:20 GMT Message-Id: <2A87333E-74B8-4A29-85D3-68BD7E73DE8A@cisco.com> From: David McGrew To: Jean-Marc Valin In-Reply-To: <4E9F74AA.7020307@jmvalin.ca> Content-Type: multipart/signed; boundary=Apple-Mail-286--646040022; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 20 Oct 2011 04:44:19 -0700 References: <4E9F74AA.7020307@jmvalin.ca> X-Mailer: Apple Mail (2.936) Cc: "iesg@ietf.org IESG" , draft-ietf-codec-guidelines.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-codec-guidelines-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 11:44:28 -0000 --Apple-Mail-286--646040022 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Jean-Marc, On Oct 19, 2011, at 6:08 PM, Jean-Marc Valin wrote: > On 19/10/11 06:36 PM, David McGrew wrote: >> Note that the >> SPEEX codec that was shown to be most vulnerable in the [spot-me] >> reference in ietf-avtcore-srtp-vbr-audio-03 is particularly bad >> security-wise because it maps phonemes to codewords (and thus there >> is >> an association between phonemes and packet lengths). > > As the author of Speex, I can assure you that it is far from being > sufficiently advanced to "map phonemes to codewords". It only has a > handful rates it can use at any time and chooses between those based > on > (too) simple heuristics. apologies for my simplistic characterization. > >> I would guess >> that it could be re-designed to be more leak-resistant without losing >> all of its bandwidth efficiency. (For example, if it had fewer >> codeword >> lengths, that would make it harder to distinguish outputs. For >> bandwidth saving, you want to shave every byte off. To prevent a >> side-channel though, you will sometimes want to leave in a padding >> byte >> so that two different codewords have the same length.) > > As I said, there's only a few possible rates. There's a total of 8 > rates > but at most 4-5 can be used for a certain target rate. From an > experiment I did, when one considers the correlation in rate between > adjacent frames, the entropy contained in the rate switching is > about 1 > bit/frame. So if one wanted to create a covert channel based on Speex > bit-rates, the max throughput without being detected would be ~50 b/s. > Considering that most of the 50 b/s is noise, the actual leak is quite > small. > > I think the VBR leak is really blown out of proportion and is really a > concern only in a handful of applications, I agree. > as detailed in > ietf-avtcore-srtp-vbr-audio. With that in mind, I don't really see > anything to add in the guidelines -- especially considering that the > issue is addressed in the actual codec requirements (see > http://tools.ietf.org/html/rfc6366 ). It would be good to have the security considerations point to that section of RFC6366. That RFC says that codecs should have a constant bitrate mode. ietf- avtcore-srtp-vbr-audio says that CBR should be used in scenarios where VBR is considered unsafe. That's all good advice, but the implication is that VBR should be turned off when security is a goal (since it is unrealistic to suppose that users or applications could do a good job of dynamically switching between CBR/VBR to reflect their current situation). Are you comfortable with this, or do you think that there should be guildelines that encourage the development and use of codecs that make an effort to minimize the leakage of plaintext information through packet lengths and timings? David > > Cheers, > > Jean-Marc > >> David >> >> >>> >>> I think that additionally, authors of codec specifications should >>> consider what implementation vulnerabilities are likely to arise, >>> and >>> document them in the specification. As I recall, audio, video, and >>> image codecs have a long history of implementation vulnerabilities >>> shared among multiple implementations. >>> >>> These shared vulnerabilities could be due to the encodings being >>> mostly binary in nature, sometimes with explicit length counts for >>> arrays, inviting buffer overflows when implemented in languages such >>> as C. (I have not extensively studied these vulnerabilities, but >>> I'm >>> sure other people have done so in much more detail.) >>> >>> Editorial: >>> >>> It's not clear what kinds of codecs are being considered. Text in >>> the >>> document implies that the focus is audio codecs rather than video or >>> other codecs, but perhaps the document should clarify what kinds of >>> codecs are in scope. >>> >>> I misinterpreted "RF license" as "radio-frequency license" >>> initially, >>> but a few clauses earlier, I found that "RF" is used to represent >>> "royalty-free". As there are no other occurrences of "RF" with this >>> meaning, consider writing it in expanded form in both places >>> (possibly >>> leaving the "RF" parenthetical for the first occurrence). >>> _______________________________________________ >>> secdir mailing list >>> secdir@ietf.org >>> https://www.ietf.org/mailman/listinfo/secdir >>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > --Apple-Mail-286--646040022 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPDCCA5ow ggKCoAMCAQICAWQwCwYJKoZIhvcNAQEFMG0xFTATBgNVBAMMDERhdmlkIE1jR3JldzETMBEGA1UE CAwKQ2FsaWZvcm5pYTELMAkGA1UEBhMCVVMxETAPBgNVBAcMCFNhbiBKb3NlMR8wHQYJKoZIhvcN AQkBFhBtY2dyZXdAY2lzY28uY29tMB4XDTA4MTIwOTIyMDMzMFoXDTA5MTIwOTIyMDMzMFowbTEV MBMGA1UEAwwMRGF2aWQgTWNHcmV3MRMwEQYDVQQIDApDYWxpZm9ybmlhMQswCQYDVQQGEwJVUzER MA8GA1UEBwwIU2FuIEpvc2UxHzAdBgkqhkiG9w0BCQEWEG1jZ3Jld0BjaXNjby5jb20wggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDh5WR1gATRK4ubbWwmG2T/XTUeVc2FAxnmtoYy00fM 5jp3DYFXHkWj4Cl8RVVfAJxP/2PhKsTl0qx2b7N9pIZZa6BaODEyJ8yVMRHloHrpzHeU8DIrst/H SFVkcJvl3p9LFD42BCvznzQ48VxnWX68OCk7GAwg6XoKMY8Z1F70PVvcZ0JcbnDuKx0efQ+P74uY UdpjRYSXb2xJUziGs5k6b1kTr5754B3tnYCGkum49YAbONpsOL4R+e4HNNrkVTx254ggrcDb1GDr IpZYCSPh6lZWwOp0XBoJiLYEKXuBf/jSNEv15/Kt/Uu5Oh8jUBxkBHGAVZuaVu25s3Zk9waLAgMB AAGjRzBFMA4GA1UdDwEB/wQEAwIEsDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDBDAbBgNVHREEFDAS gRBtY2dyZXdAY2lzY28uY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCbD+Y6Yu0d5FZHSGd7WTP7vlo+ SE2rF0YzqvcMYrEuu6VBbkOFGfq3leu2WVJinXYQwAgaZ7vJpH43/bjDIK4YuOqAUv57ZQjtCJ6W 6b0rdG8/A2cWcGoDjqmjAGJ4TC8oMIc0h33QPEjsGdon0nsV0QCxrgWcWEjFSzlE6kbR4pT3yA2V zo7byNoDoYpH5otGH0/cRQM9i6ENTytxzczPeNTt2uaMp/3s8MZ5W/0Yz8U/yy5bcS5TGrqgTvN7 mI+nngoJ4TNKapSpdSqCyEK86z51VWtRRFyBosLQsNhMYb7HWzW/mIQCG0SygOVjUcRPKxhYUokR gCmxsHqcL1uMMIIFmjCCA4ICCQD8XsAekzPPFDANBgkqhkiG9w0BAQUFADCBjjELMAkGA1UEBhMC VVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBKb3NlMRwwGgYDVQQKExNDaXNj byBTeXN0ZW1zLCBJbmMuMRgwFgYDVQQDEw9EYXZpZCBBLiBNY0dyZXcxHzAdBgkqhkiG9w0BCQEW EG1jZ3Jld0BjaXNjby5jb20wHhcNMTEwMzE0MTgwOTAyWhcNMTMwMzEzMTgwOTAyWjCBjjELMAkG A1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBKb3NlMRwwGgYDVQQK ExNDaXNjbyBTeXN0ZW1zLCBJbmMuMRgwFgYDVQQDEw9EYXZpZCBBLiBNY0dyZXcxHzAdBgkqhkiG 9w0BCQEWEG1jZ3Jld0BjaXNjby5jb20wggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDL KlHKr3WA3U7qp3aPD6XqP+nSwKGxXYA2Sn/rgpxo34tTS9CpCqhQUU7oNxGJ1/534P8GhpwP8Ufg HVqNa6wDAWUsHJBRdqLT2qqjnFFmEa4G7V2Hmis6nbAnQ+vu9TdZVMDJDEakTiAh6XCgzGRWYTiJ XgIn6UT+aIWQ63VRVTnOQVN+fhzhoKzmd3opwHiavo/gfavu/2t4S/hSLTZikroi0h68df4w3nRo b/1ksC+NVbG8LHnHQ3fjyhdrxZwl9aH2k1hNS8LosET9rIQbzOvwkueC/9xYBjfr4yZcTlpDtixZ fh26rg/AFLkzXrtBBt4Sqi3niI+zWTXUOx1JMwFKEQBTn2z+RYPi9Q1VWCIg93Rh5RT6nkH/ZOyp HbmElrYoThYH+duDASssKyX3yXRu4F6UMoC897ynR7g9aV3RLF9PevN4k8UeIQQR6e0+aFvoo/zm xKYCCZIGnqWmMa6cnlzKWoMD5sTu+ILDk7Ty67+7LijhJxCO14erj4/XYmY1uvSuN/axd587emXu BmdWI3sDQoC1l/H7QxRROoONTWK5wAEGpNUUMllJmYDW//LxIiDhEsKC6wc1rOIhHy3FuykMA1BI xkIVaqOwYvokVdH/jXwpZNHoMEhS6hXCvWKt4mwIEJQRQsYGSC/TAB25D5cTkVmo/RCE/sTzXQID AQABMA0GCSqGSIb3DQEBBQUAA4ICAQCUtnHAg+JXVgQPFwz2hiIdD+MB14I3vThsphpEkD4PgdJz /KbIegcEe60ZaOvvDYVcLnY0dE3Z6kSXSS8Y5GCoXh9gKTL1mmzT+Rux0gFgbQHHd9xtnIeEUjuq E2MvznfgipTCvEIAqTZaonvilTeJJie4oEAPHX8Jjy7De3HM11bjbq4qZJhWv/9RE8CG08YUFmC3 /LQcGEdo4qSH16juGst5NuacAqg3Hugt9LCwLiSwoTpLXfhykd58kvTmPawrTszstDOvQAR1Q3TY zMw3/cbaKN2b/WMkxYZFwxmzwy7pYYgnkGPf3ehxfrwEmVzlzXUnMZVTqyk7KlF5sUE1ahS8mu1k jKOyGtOOPuFmGydDTFHHAHLGO5I8zoR3qfzeeOLEqr0tdG8ye7ZprVZyYVEa2EMUBl0vyH0+aAOy oPP5mba7eDyZLs357Xy8277x/2t2Zmcu6IkYdkQ3/yIfAb/99Ws7020X+zyaiiImsHangUmw9DKy LirSIeI03ZFcyEy8pMFFoIZFhg3/DM9md8YcUDubJjneWQaU5PpskcjfmOTzzhGag23ow9vw+upX mLVErB5jB2O0WCOMZZbAC837+Od3nAJhaIAXtk7OU67KbOgM/tfph71ZS/OhfQnu3+o9FQJwCTKM U+3z3+45mPYuaPT5+MPyGep06MXlczGCBC8wggQrAgEBMIGcMIGOMQswCQYDVQQGEwJVUzETMBEG A1UECBMKQ2FsaWZvcm5pYTERMA8GA1UEBxMIU2FuIEpvc2UxHDAaBgNVBAoTE0Npc2NvIFN5c3Rl bXMsIEluYy4xGDAWBgNVBAMTD0RhdmlkIEEuIE1jR3JldzEfMB0GCSqGSIb3DQEJARYQbWNncmV3 QGNpc2NvLmNvbQIJAPxewB6TM88UMAkGBSsOAwIaBQCgggFnMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTAyMDExNDQyMFowIwYJKoZIhvcNAQkEMRYEFB8lQo7s X48fz5uQrNoo6cf5t6aiMIGBBgkrBgEEAYI3EAQxdDByMG0xFTATBgNVBAMMDERhdmlkIE1jR3Jl dzETMBEGA1UECAwKQ2FsaWZvcm5pYTELMAkGA1UEBhMCVVMxETAPBgNVBAcMCFNhbiBKb3NlMR8w HQYJKoZIhvcNAQkBFhBtY2dyZXdAY2lzY28uY29tAgFkMIGDBgsqhkiG9w0BCRACCzF0oHIwbTEV MBMGA1UEAwwMRGF2aWQgTWNHcmV3MRMwEQYDVQQIDApDYWxpZm9ybmlhMQswCQYDVQQGEwJVUzER MA8GA1UEBwwIU2FuIEpvc2UxHzAdBgkqhkiG9w0BCQEWEG1jZ3Jld0BjaXNjby5jb20CAWQwDQYJ KoZIhvcNAQEBBQAEggIABsivyGS/AWx0Go4x77fzPLlrjcu+waGOVyVfXZJYI7/Fk5cqoYxM4t8f W7eL0/LxMeWZMKGwQ/4mR25HtKf73DUGeaSBwSQhx1oU3euVd+diQHGgRYc/U0b2fxDhlpY+Kdqo pSCDkUNe2W915B0olvVow4HjsJWD5anGtG1SvhZgzUcLjOxU744dLWRhPOU6+T+O+xoeW9tQ4zM1 kOpLa8i6E4UX5J/dmi0NTsbgtY2rD4x3UwbL1nleugYZDBYR2LYCGdR+lCZmeH3tQep9gtYWrrPb UyWt/GHgyuG71Ff//Fbi1edGmaOvB8xD9zHB6aGMuRhYFv7hBoCojaWK338/XoC6U5AvyTaiRG79 fyetK2M4favJ6T2TgrUJ9jwE3WoQKJgC7OQh9nA/hvK4Dp4/31PB0cWd4Zkh31/YtSTDpP80DoA8 Bx1F7894HWOg66T6WOOrj0689BFHAqoXAEYnGVGKQslDz8LskVZvCEwc8JY2q/795foGNZfSh4X1 0yW8/NtmQFDRkC8XTARkX/9sUoi3ftTI8LiIAkeMTwHVDfacSu8JuPlfyUD446V/6AiB3YUAsa/g 2e+LJ7yB3czdAp6qRnowc9C1VeUYIFfE+RQruulDAq5kIN/dNs0svVwJUsEEmt1izZmmNWQD8IBo SXifHMmAxIMCDfDs4BUAAAAAAAA= --Apple-Mail-286--646040022-- From derek@ihtfp.com Thu Oct 20 06:26:48 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB2F721F8AED; Thu, 20 Oct 2011 06:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.988 X-Spam-Level: X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nuGtTrh-0-d; Thu, 20 Oct 2011 06:26:47 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 18A6421F8672; Thu, 20 Oct 2011 06:26:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 2C9362602A6; Thu, 20 Oct 2011 09:26:46 -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 28390-08; Thu, 20 Oct 2011 09:26:45 -0400 (EDT) Received: from mocana.ihtfp.org (IHTFP-DHCP-158.IHTFP.ORG [192.168.248.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id E016F260294; Thu, 20 Oct 2011 09:26:44 -0400 (EDT) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id p9KDQcUc031021; Thu, 20 Oct 2011 09:26:38 -0400 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Date: Thu, 20 Oct 2011 09:26:36 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: yaojk@cnnic.cn, eai-chairs@tools.ietf.org, maowei_ietf@cnnic.cn Subject: [secdir] sec-dir review of draft-ietf-roll-of0-15.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 13:26:48 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. The security considerations sections lists a number of issues to consider with this document, and presents the issues well. It does not go into particular depth about what could happen if those issues are not addressed. For example, 3.7.2 mentions "surprising rejections" but doesn't go into any depth beyond that nor does it explain what other failures can happen. Operationally it might be hard to make sure that all or none of the MX servers support UTF8SMTPbis, especially if the MX servers might MX for multiple domains, or be under different operational control. What are the situations where mixed-MX support will work or fail? Should MX servers need the ability to turn on or off support for this protocol on a per-domain basis to protect against these types of failures? Thanks, -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From derek@ihtfp.com Thu Oct 20 06:58:36 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF5721F8BAB; Thu, 20 Oct 2011 06:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.988 X-Spam-Level: X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdWyOOCOIuGh; Thu, 20 Oct 2011 06:58:36 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 356B121F8B9C; Thu, 20 Oct 2011 06:58:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 815552602A6; Thu, 20 Oct 2011 09:58:35 -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 28573-10; Thu, 20 Oct 2011 09:58:34 -0400 (EDT) Received: from mocana.ihtfp.org (IHTFP-DHCP-158.IHTFP.ORG [192.168.248.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 4D82D26002E; Thu, 20 Oct 2011 09:58:34 -0400 (EDT) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id p9KDwS0x031504; Thu, 20 Oct 2011 09:58:28 -0400 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org References: Date: Thu, 20 Oct 2011 09:58:27 -0400 In-Reply-To: (Derek Atkins's message of "Thu, 20 Oct 2011 09:26:36 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: yaojk@cnnic.cn, eai-chairs@tools.ietf.org, maowei_ietf@cnnic.cn Subject: [secdir] sec-dir review of draft-ietf-eai-rfc5336bis-14.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 13:58:37 -0000 Sorry, that previous email was a review of draft-ietf-eai-rfc5336bis-14.txt. I appologize for any confusion. -derek Derek Atkins writes: > Hi, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document specifies an SMTP extension for transport and delivery > of email messages with internationalized email addresses or header > information. > > The security considerations sections lists a number of issues to > consider with this document, and presents the issues well. It does > not go into particular depth about what could happen if those issues > are not addressed. > > For example, 3.7.2 mentions "surprising rejections" but doesn't go > into any depth beyond that nor does it explain what other failures can > happen. > > Operationally it might be hard to make sure that all or none of the MX > servers support UTF8SMTPbis, especially if the MX servers might MX for > multiple domains, or be under different operational control. What are > the situations where mixed-MX support will work or fail? Should MX > servers need the ability to turn on or off support for this protocol > on a per-domain basis to protect against these types of failures? > > Thanks, > > -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From tlyu@mit.edu Thu Oct 20 11:07:21 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8482511E8073; Thu, 20 Oct 2011 11:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNQPkQjoXQKP; Thu, 20 Oct 2011 11:07:21 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU [18.9.25.15]) by ietfa.amsl.com (Postfix) with ESMTP id BF22F21F85F2; Thu, 20 Oct 2011 11:07:20 -0700 (PDT) X-AuditID: 1209190f-b7f6e6d0000008df-9b-4ea063571410 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 22.AE.02271.75360AE4; Thu, 20 Oct 2011 14:07:19 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id p9KI7GPu030110; Thu, 20 Oct 2011 14:07:16 -0400 Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p9KI7BeW002957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Oct 2011 14:07:11 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id p9KI79i8011136; Thu, 20 Oct 2011 14:07:09 -0400 (EDT) To: Jean-Marc Valin References: <4E9F74AA.7020307@jmvalin.ca> From: Tom Yu Date: Thu, 20 Oct 2011 14:07:09 -0400 In-Reply-To: <4E9F74AA.7020307@jmvalin.ca> (Jean-Marc Valin's message of "Wed, 19 Oct 2011 21:08:58 -0400") Message-ID: Lines: 16 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjleLIzCtJLcpLzFFi42IR4hTV1g1PXuBnsHijgcWrbZdYLGb8mchs 8W3xbXaLq6v+sFt8WPiQxYHVY8rvjaweS5b8ZPJ48mw3o8eXy5/ZAliiuGxSUnMyy1KL9O0S uDIO3frFVnCLreL5zU8sDYwHWLsYOTkkBEwkrizbzgJhi0lcuLeerYuRi0NIYB+jxKKXT9gh nA2MEhNu3GCGcK4wScxcsIEFwulilNja+gbI4eAQEdCQmDKRCyTOLDCHUeJN2ys2kLnCAq4S szvaoBq6GSV+b+1mBWlgE5CWOLq4DKSGRUBV4vPTK0wgNqdAtsTqpRPB7uMVsJA4c/cKG0g5 jwCnxO3XjhBhQYmTM5+Anc0soCVx499LpgmMgrOQpGYhSS1gZFrFKJuSW6Wbm5iZU5yarFuc nJiXl1qka6KXm1mil5pSuokRHNyS/DsYvx1UOsQowMGoxMO7IHGBnxBrYllxZe4hRkkOJiVR 3idJQCG+pPyUyozE4oz4otKc1OJDjBIczEoivPmxQDnelMTKqtSifJiUNAeLkjhv4w4HPyGB 9MSS1OzU1ILUIpisDAeHkgTvK5ChgkWp6akVaZk5JQhpJg5OkOE8QMMfgdTwFhck5hZnpkPk TzEqSonz7gJJCIAkMkrz4HphyecVozjQK8IQd/MAExdc9yugwUxAg48qzgUZXJKIkJJqYCxP FD3j7XjQ+OEyh4sclxonzSnVVTmhM3ul6fL5t+7/TJ035/TJE6t721iy3pwurcx/MNl8dk39 68RfoRUyeyJL1O/ee7xeOdHOJiD92pfpC5w/bqiXelHzi9vc9+eB6p88CjMPty7U3zjJVsP3 x6oVQvu+Skh8kvX9MPmvUYzzxlTh6JKjZ/2UWIozEg21mIuKEwHWblfNGQMAAA== Cc: "iesg@ietf.org IESG" , draft-ietf-codec-guidelines.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-codec-guidelines-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 18:07:21 -0000 Jean-Marc Valin writes: > I think the VBR leak is really blown out of proportion and is really a > concern only in a handful of applications, as detailed in > ietf-avtcore-srtp-vbr-audio. With that in mind, I don't really see > anything to add in the guidelines -- especially considering that the > issue is addressed in the actual codec requirements (see > http://tools.ietf.org/html/rfc6366 ). I think this document should reference the Security Considerations section of RFC 6366. (It currently does not.) I think RFC 6366 could additionally emphasize that independent implementations of codecs can have shared vulnerabilities due to things like binary encodings and explicit length counts for arrays, but it may be too late to bother making such an update (either in a successor to RFC 6366 or in this document). From jmvalin@jmvalin.ca Wed Oct 19 18:08:17 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 967F621F8AEA; Wed, 19 Oct 2011 18:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZX6G5lHdTey; Wed, 19 Oct 2011 18:08:17 -0700 (PDT) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id 0D48321F8AD2; Wed, 19 Oct 2011 18:08:16 -0700 (PDT) Received: from [192.168.1.102] (modemcable027.68-201-24.mc.videotron.ca [24.201.68.27]) (Authenticated sender: jvalin@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id C21D94AEE16; Wed, 19 Oct 2011 18:08:15 -0700 (PDT) Message-ID: <4E9F74AA.7020307@jmvalin.ca> Date: Wed, 19 Oct 2011 21:08:58 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: David McGrew References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 20 Oct 2011 12:50:26 -0700 Cc: "iesg@ietf.org IESG" , draft-ietf-codec-guidelines.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-codec-guidelines-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 01:08:17 -0000 On 19/10/11 06:36 PM, David McGrew wrote: > Note that the > SPEEX codec that was shown to be most vulnerable in the [spot-me] > reference in ietf-avtcore-srtp-vbr-audio-03 is particularly bad > security-wise because it maps phonemes to codewords (and thus there is > an association between phonemes and packet lengths). As the author of Speex, I can assure you that it is far from being sufficiently advanced to "map phonemes to codewords". It only has a handful rates it can use at any time and chooses between those based on (too) simple heuristics. > I would guess > that it could be re-designed to be more leak-resistant without losing > all of its bandwidth efficiency. (For example, if it had fewer codeword > lengths, that would make it harder to distinguish outputs. For > bandwidth saving, you want to shave every byte off. To prevent a > side-channel though, you will sometimes want to leave in a padding byte > so that two different codewords have the same length.) As I said, there's only a few possible rates. There's a total of 8 rates but at most 4-5 can be used for a certain target rate. From an experiment I did, when one considers the correlation in rate between adjacent frames, the entropy contained in the rate switching is about 1 bit/frame. So if one wanted to create a covert channel based on Speex bit-rates, the max throughput without being detected would be ~50 b/s. Considering that most of the 50 b/s is noise, the actual leak is quite small. I think the VBR leak is really blown out of proportion and is really a concern only in a handful of applications, as detailed in ietf-avtcore-srtp-vbr-audio. With that in mind, I don't really see anything to add in the guidelines -- especially considering that the issue is addressed in the actual codec requirements (see http://tools.ietf.org/html/rfc6366 ). Cheers, Jean-Marc > David > > >> >> I think that additionally, authors of codec specifications should >> consider what implementation vulnerabilities are likely to arise, and >> document them in the specification. As I recall, audio, video, and >> image codecs have a long history of implementation vulnerabilities >> shared among multiple implementations. >> >> These shared vulnerabilities could be due to the encodings being >> mostly binary in nature, sometimes with explicit length counts for >> arrays, inviting buffer overflows when implemented in languages such >> as C. (I have not extensively studied these vulnerabilities, but I'm >> sure other people have done so in much more detail.) >> >> Editorial: >> >> It's not clear what kinds of codecs are being considered. Text in the >> document implies that the focus is audio codecs rather than video or >> other codecs, but perhaps the document should clarify what kinds of >> codecs are in scope. >> >> I misinterpreted "RF license" as "radio-frequency license" initially, >> but a few clauses earlier, I found that "RF" is used to represent >> "royalty-free". As there are no other occurrences of "RF" with this >> meaning, consider writing it in expanded form in both places (possibly >> leaving the "RF" parenthetical for the first occurrence). >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From leeyoung@huawei.com Thu Oct 20 21:33:59 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC2C21F84E5; Thu, 20 Oct 2011 21:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.436 X-Spam-Level: X-Spam-Status: No, score=-6.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Suts3j2oMoNr; Thu, 20 Oct 2011 21:33:59 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2304B21F84DD; Thu, 20 Oct 2011 21:33:59 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTE00LBFFCLTB@usaga02-in.huawei.com>; Thu, 20 Oct 2011 23:33:58 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LTE00DTMFCLYE@usaga02-in.huawei.com>; Thu, 20 Oct 2011 23:33:57 -0500 (CDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 20 Oct 2011 21:33:59 -0700 Received: from DFWEML501-MBX.china.huawei.com ([10.124.31.87]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0270.001; Thu, 20 Oct 2011 21:33:52 -0700 Date: Fri, 21 Oct 2011 04:33:50 +0000 From: Leeyoung In-reply-to: X-Originating-IP: [10.18.29.181] To: Nico Williams Message-id: <7AEB3D6833318045B4AE71C2C87E8E17181821C9@DFWEML501-MBX.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: Review of draft-ietf-ccamp-wson-impairments-07 Thread-index: AQHMiK1k/aUAVZm3CECvsX0ct9xRXZV4912AgAB+a4CACZDzwIABQM0AgAH7whA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <7AEB3D6833318045B4AE71C2C87E8E171817FEAA@DFWEML501-MBX.china.huawei.com> <7AEB3D6833318045B4AE71C2C87E8E1718181C1B@DFWEML501-MBX.china.huawei.com> Cc: "iesg@ietf.org" , "draft-ietf-ccamp-wson-impairments@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Review of draft-ietf-ccamp-wson-impairments-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 04:33:59 -0000 Hi Nico, Thanks for your thorough review and suggestions, and accepting the modified texts. Best Regards, Young -----Original Message----- From: Nico Williams [mailto:nico@cryptonector.com] Sent: Wednesday, October 19, 2011 10:14 AM To: Leeyoung Cc: secdir@ietf.org; iesg@ietf.org; draft-ietf-ccamp-wson-impairments@tools.ietf.org Subject: Re: Review of draft-ietf-ccamp-wson-impairments-07 On Tue, Oct 18, 2011 at 10:16 PM, Leeyoung wrote: > As you indicated in the latest response, this document is first of all informational and does not define any new protocols beyond the family of OSPF-TE, RSVP-TE and PCEP. There are no new requirements caused by IA-RWA other than the need for processing additional routing/signaling related data beyond the regular TE networks. > These additional data would not add any particular security requirements in my opinion. The fact that this is an informational document doesn't mean there's no need to be thorough. On the contrary, since a beginner to the subject might start by reading the informational documents, this one's a good place to discuss security issues. > Anyhow, please see the following changes if you would be satisfied with them. I'm happy with the proposed text. Thanks! Nico -- From leeyoung@huawei.com Fri Oct 21 05:25:01 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C32721F8C5B; Fri, 21 Oct 2011 05:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.454 X-Spam-Level: X-Spam-Status: No, score=-6.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFSrM6FMV-8F; Fri, 21 Oct 2011 05:24:58 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 4496321F8C45; Fri, 21 Oct 2011 05:24:58 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTF007S615KQZ@usaga02-in.huawei.com>; Fri, 21 Oct 2011 07:24:57 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LTF00MMZ15K1Y@usaga02-in.huawei.com>; Fri, 21 Oct 2011 07:24:56 -0500 (CDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 21 Oct 2011 05:24:49 -0700 Received: from DFWEML501-MBX.china.huawei.com ([10.124.31.87]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0270.001; Fri, 21 Oct 2011 05:24:46 -0700 Date: Fri, 21 Oct 2011 12:24:46 +0000 From: Leeyoung In-reply-to: X-Originating-IP: [10.18.29.181] To: Acee Lindem Message-id: <7AEB3D6833318045B4AE71C2C87E8E1718182301@DFWEML501-MBX.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: Routing-Directory Review of "A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments" - draft-ietf-ccamp-wson-impairments-07.txt Thread-index: AcyHcDhDr14yzGLLTbmWYTQof9WvVgA61EbQAGTJcAABe+hnoA== X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: EOQx EY4W MwVz NYS6 PtMT U8jU VQcg W4gs d0QQ gj8u hDRK o2nd sMfc tN5X uzPS 0vqF; 5; YQBjAGUAZQAuAGwAaQBuAGQAZQBtAEAAZQByAGkAYwBzAHMAbwBuAC4AYwBvAG0AOwBhAGQAcgBpAGEAbgBAAG8AbABkAGQAbwBnAC4AYwBvAC4AdQBrADsAZAByAGEAZgB0AC0AaQBlAHQAZgAtAGMAYwBhAG0AcAAtAHcAcwBvAG4ALQBpAG0AcABhAGkAcgBtAGUAbgB0AHMAQAB0AG8AbwBsAHMALgBpAGUAdABmAC4AbwByAGcAOwBpAGUAcwBnAEAAaQBlAHQAZgAuAG8AcgBnADsAcwBlAGMAZABpAHIAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {4230616F-A163-4899-9382-9B626B911754}; bABlAGUAeQBvAHUAbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Fri, 21 Oct 2011 12:24:35 GMT; UgBFADoAIABSAG8AdQB0AGkAbgBnAC0ARABpAHIAZQBjAHQAbwByAHkAIABSAGUAdgBpAGUAdwAgAG8AZgAgACIAQQAgAEYAcgBhAG0AZQB3AG8AcgBrACAAZgBvAHIAIAB0AGgAZQAgAEMAbwBuAHQAcgBvAGwAIABvAGYAIABXAGEAdgBlAGwAZQBuAGcAdABoACAAUwB3AGkAdABjAGgAZQBkACAATwBwAHQAaQBjAGEAbAAgAE4AZQB0AHcAbwByAGsAcwAgACgAVwBTAE8ATgApACAAdwBpAHQAaAAgAEkAbQBwAGEAaQByAG0AZQBuAHQAcwAiACAALQAgAGQAcgBhAGYAdAAtAGkAZQB0AGYALQBjAGMAYQBtAHAALQB3AHMAbwBuAC0AaQBtAHAAYQBpAHIAbQBlAG4AdABzAC0AMAA3AC4AdAB4AHQA x-cr-puzzleid: {4230616F-A163-4899-9382-9B626B911754} References: <486FA0F6-EE68-4AAA-AA12-58F43B1F6903@ericsson.com> <7AEB3D6833318045B4AE71C2C87E8E171817FD6E@DFWEML501-MBX.china.huawei.com> Cc: "adrian@olddog.co.uk" , "iesg@ietf.org" , "draft-ietf-ccamp-wson-impairments@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Routing-Directory Review of "A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments" - draft-ietf-ccamp-wson-impairments-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 12:25:01 -0000 Hi Acee, Thanks a lot for your feedback. I think we are merging. Please see in-line for my comment. If you are satisfied with these changes, I will update the revision. Thanks, Young -----Original Message----- From: Acee Lindem [mailto:acee.lindem@ericsson.com] Sent: Thursday, October 13, 2011 9:26 AM To: Leeyoung Subject: Re: Routing-Directory Review of "A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments" - draft-ietf-ccamp-wson-impairments-07.txt Hi Young, On Oct 11, 2011, at 9:09 PM, Leeyoung wrote: > Hi Acee, > > Thanks for your thorough review and suggestions. Please see in-line if my response would satisfy you. Before I edit, I just wanted to know if these would be good enough for you. > > Thanks. > > Young > > -----Original Message----- > From: Acee Lindem [mailto:acee.lindem@ericsson.com] > Sent: Monday, October 10, 2011 12:16 PM > To: Greg Bernstein; Huawei danli; Leeyoung; Giovanni Martinelli > Cc: rtg-dir@ietf.org; ccamp-chairs@tools.ietf.org; Adrian Farrel > Subject: Routing-Directory Review of "A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments" - draft-ietf-ccamp-wson-impairments-07.txt > > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. > > > Document: draft-ietf-ccamp-wson-impairments-07.txt > Reviewer: Acee Lindem > Review Date: 2011-10-10 > IETF LC End Date: TBD > Intended Status: Informational > > Summary: > I have no major concerns about this document that I think must be > resolved before publication. I have some suggestions below. > > Major Issues: > No major issues found. > > Minor Issues: > The document is somewhat hard to read and I've included some editorial suggestions below. Some of tthese are subjective and style based. For example, I prefer a comma after a prepositional phase preceding an independent clause. Other suggested edits are obvious typos (so you'll need to look at them all ;^). > > Additionally, I'd suggest the following: > > Abstract: Mention the components included in the framework in the abstract and introduction > to set the context for the remainder of the document. > > Current Abstract: > > As an optical signal progresses along its path it may be altered by the various physical processes in the optical fibers and devices it encounters. When such alterations result in signal degradation, these processes are usually referred to as "impairments". These physical characteristics may be important constraints to consider when using a GMPLS control plane to support path setup and maintenance in wavelength switched optical networks. > This document provides a framework for applying GMPLS protocols and the PCE architecture to support Impairment Aware Routing and Wavelength Assignment (IA-RWA) in wavelength switched optical networks. This document does not define optical data plane aspects; impairment parameters, measurement of, or assessment and qualification of a route, but rather it describes the architectural and information components for protocol solutions. > > Suggested Abstract: > > As an optical signal progresses along its path it may be altered by the various physical processes in the optical fibers and devices it encounters. When such alterations result in signal degradation, these processes are usually referred to as "impairments". These physical characteristics may be important constraints to consider when using a GMPLS control plane to support path setup and maintenance in wavelength switched optical networks. > This document provides a framework for applying GMPLS protocols and the PCE architecture to support Impairment Aware Routing and Wavelength Assignment (IA-RWA) in wavelength switched optical networks. Specifically, this documents discusses key computing constraints, scenarios and impairment estimation processes. This document does not define optical data plane aspects; impairment parameters, measurement of, or assessment and qualification of a route, but rather it describes the architectural and information components for protocol solutions. That's better - do you think it should mention the architectural processes: Routing, Wavelength Assignment, and Impairment Validation. YOUNG>> I will add these processes in the abstract. The new text will look like as follows: As an optical signal progresses along its path it may be altered by the various physical processes in the optical fibers and devices it encounters. When such alterations result in signal degradation, these processes are usually referred to as "impairments". These physical characteristics may be important constraints to consider when using a GMPLS control plane to support path setup and maintenance in wavelength switched optical networks. This document provides a framework for applying GMPLS protocols and the PCE architecture to support Impairment Aware Routing and Wavelength Assignment (IA-RWA) in wavelength switched optical networks. Specifically, this documents discusses key computing constraints, scenarios and architectural processes: Routing, Wavelength Assignment, and Impairment Validation. This document does not define optical data plane aspects; impairment parameters, measurement of, or assessment and qualification of a route, but rather it describes the architectural and information components for protocol solutions. > > 2 - Include "black link". > > Black links: Black links refer to tributary interfaces where only link characteristics are defined. This approach enables transverse compatibility at the single-channel point using a direct wavelength-multiplexing configuration. Ok. > > 4.1.1, Scenario D - The detailed case is designated as out of scope yet it is referred to > in later sections. For example, section 4.3. > > I am not sure where in Section 4.3 we are referring to Scenario D. All the discussions in section 4.3 are actually in the spirit of Scenario C - approximated impairment estimation. Then it is unclear to me what the difference is between IV and IV-Detailed in the remainder of the document. YOUNG>> I realized that Scenario D - Detailed is a confusing term since we use IV-Detailed in the remainder of the document. In section 4.1.1. Scenario D - the detailed case is now changed to "Accurate Impairment Computation." YOUNG>> I also added the following text: "All the variations of impairment validation discussed in this section is based on Scenario C (Approximated Impairment Estimation) as discussed in Section 4.1.1." is section 4.2. to make sure we are discussing all IV discussion in the spirit of Scenario C. > > 4.1.3 - What is the Q factor? > > The Q-factor provides a qualitative description of the receiver performance. It is a function of the signal to noise ratio (optical). The Q-factor suggests the minimum SNR required to obtain a specific BER for a given signal. (Would you like to suggest Q-factor in the definition?) Yes - that would be good. > > 4.2 - Explain what you mean by "at-most K paths". Define K. > > K refers to the "K" value in K-shortest path algorithm. I see I get a lot of Google hits on this but I had never heard of it before and I work on SPF and LFA. Could you add a definition and, possibly, a reference? YOUNG>> Yes. I will add the definition and reference as follows: K-shortest path algorithm refers to an algorithm that finds multiple (k) short paths connecting the source and the destination in a graph (allowing repeated vertices and edges in the paths). D. Eppstein. "Finding the k shortest paths," 35th IEEE Symp. Foundations of Comp. Sci., Santa Fe, 1994, pp. 154-165. > > 4.2 - Why is there assumed to be one IV process and multiple RWA processes? > > Actually section 4.2 shows a number of options as to how to do with R and WA with respect to IV. R and WA can be combined before IV; or sequentially R, WA and IV; or once R is determined WA can be done in a distributed fashion with IV on a hop by hop. > > General: Would it make sense to include a discussion of the order in which > PCE, WA, and IV should be done to avoid redundant computation? > > Figures 5 and 6 show each entity that involves R, WA and IV (detail, approximation) respectively. I thought these figures show non-redundant computation in a sequential manner. It is implied and maybe obvious to those familiar with optical path computation. However, it occurred to me that other functional distributions wouldn't work (at least not without lots of inefficiency ;^). YOUNG>> Actually I will add the following text in Section 5.4.3. "Please note that there is some inefficiency by separating the IV-Candidates-PCE from the IV-Detailed-PCE from a message flow perspective in order to achieve a high degree of potential optimality." Thanks, Acee > > Editorial Comments: > > Missing acronyms expansions: ADM, NEs, OSNR, DGD, PXCs, and OADMs > YOUNG>> I will add the following acronyms: ADM: Add Drop Multiplexer NEs: Network Elements OSNR: Optical Signal to Noise Ratio DGD: differential group delay PXCs: Photonic Cross Connects OADMs: Optical Add Drop Multiplexers > > Acee-Lindems-MacBook-Pro:Desktop ealflin$ diff draft-ietf-ccamp-wson-impairments-07.txt.orig draft-ietf-ccamp-wson-impairments-07.txt > 136c136 > < As an optical signal progresses along its path it may be altered by > --- >> As an optical signal progresses along its path, it may be altered by > 142c142 > < used, the types and placement of various optical devices and the > --- >> used, the types and placement of various optical devices, and the > 149c149 > < a WSON, a combination of path continuity, resource availability and > --- >> a WSON, a combination of path continuity, resource availability, and > 157c157 > < that use time division multiplexing, and WDM. The Path Computation > --- >> that use time division multiplexing and WDM. The Path Computation > 189c189 > < CWDM: Coarse Wavelength Division Multiplexing. > --- >> CWDM: Coarse Wavelength Division Multiplexing > 191c191 > < DWDM: Dense Wavelength Division Multiplexing. > --- >> DWDM: Dense Wavelength Division Multiplexing > 193c193 > < FOADM: Fixed Optical Add/Drop Multiplexer. > --- >> FOADM: Fixed Optical Add/Drop Multiplexer > 195c195 > < GMPLS: Generalized Multi-Protocol Label Switching. > --- >> GMPLS: Generalized Multi-Protocol Label Switching > 204c204 > < OXC: Optical cross connect. An optical switching element in which a > --- >> OXC: Optical cross connect - An optical switching element in which a > 207c207 > < PCC: Path Computation Client. Any client application requesting a > --- >> PCC: Path Computation Client - Any client application requesting a > 210c210 > < PCE: Path Computation Element. An entity (component, application, or > --- >> PCE: Path Computation Element - An entity (component, application, or > 219c219 > < PCEP: PCE Communication Protocol. The communication protocol between > --- >> PCEP: PCE Communication Protocol - The communication protocol between > 222c222 > < ROADM: Reconfigurable Optical Add/Drop Multiplexer. A wavelength > --- >> ROADM: Reconfigurable Optical Add/Drop Multiplexer - A wavelength > 226c226 > < RWA: Routing and Wavelength Assignment. > --- >> RWA: Routing and Wavelength Assignment > 247c247 > < WDM: Wavelength Division Multiplexing. > --- >> WDM: Wavelength Division Multiplexing > 281c281 > < cross connects to increase network flexibility. In such cases > --- >> cross connects to increase network flexibility. In such cases, > 335,336c335,336 > < contains transparent elements and electro-optical elements such as > < OEO regenerations. In such networks a generic light path can go > --- >> contain transparent elements and electro-optical elements such as >> OEO regenerations. In such networks, a generic light path can go > 341,342c341,342 > < (i) wavelength conversion to assist RWA to avoid wavelength blocking. > < This is the impairment free case covered by [RFC6163]. > --- >> (i) Due to wavelength conversion to assist RWA to avoid wavelength >> blocking. This is the impairment free case covered by [RFC6163]. > 344,345c344,345 > < (ii) the optical signal without regeneration would be too degraded > < to meet end to end BER requirements. This is the case when RWA > --- >> (ii) The optical signal without regeneration would be too degraded >> to meet end-to-end BER requirements. This is the case when RWA > 349c349 > < In the latter case an optical path can be seen as a set of transparent > --- >> In the latter case, an optical path can be seen as a set of transparent > 371,372c371,372 > < constraints that an impairment aware optical control plane may have > < to operate under. These requirements and constraints motivate the IA- > --- >> constraints under which an impairment aware optical control plane may have >> to operate. These requirements and constraints motivate the IA- > 396,397c396,397 > < In this case impairments are only taken into account during network > < design and after that, for example during optical path computation, > --- >> In this case, impairments are only taken into account during network >> design. After that, for example during optical path computation, > 452c452 > < channel interfaces to multi-channel DWDM systems only the single > --- >> channel interfaces to multi-channel DWDM systems, only the single > 456c456 > < available. Note however the overall impact of a black link at the > --- >> available. However, note that the overall impact of a black link at the > 461c461 > < spans and to estimate the validity of optical paths. For example, > --- >> spans in order to estimate the validity of optical paths. For example, > 468c468 > < for optical networks with "black links" (path) could not be performed > --- >> for optical networks with "black links" in the path could not be performed > 473c473 > < entity. Such a vendor specific IA computation, could utilize > --- >> entity. Such a vendor specific IA computation could utilize > 477c477 > < In the following the term "black links" will be used to describe > --- >> In the following, the term "black links" will be used to describe > 479c479 > < networks. From the control plane perspective the following options > --- >> networks. From the control plane perspective, the following options > 493,495c493,495 > < computation entity. The difficulty here is for larger networks > < such a list of paths along with any wavelength constraints could > < get unmanageably large. > --- >> computation entity. The difficulty here is that such a list of >> paths along with any wavelength constraints could get unmanageably >> large as the size of the network increases. > 497,498c497,498 > < 2. The authority in control of the "black links" could provide a PCE > < like entity a list of viable paths/wavelengths between two > --- >> 2. The authority in control of the "black links" could provide a >> PCE-like entity that returns a list of viable paths/wavelengths between two > 500,501c500,501 > < and can reduce the scaling issue previously mentioned. Such a PCE > < like entity would not need to perform a full RWA computation, > --- >> and can reduce the scaling issue previously mentioned. Such a PCE-like >> entity would not need to perform a full RWA computation, > 563c563 > < Starting from functional block on the left the Optical Interface > --- >> Starting from functional block on the left, the Optical Interface > 565,567c565,567 > < defines the properties at the path end points. Even the no-impairment > < case like scenario B in section 4.1.1 needs to consider a minimum set > < of interface characteristics. In such case only a few parameters used > --- >> defines the properties at the path end-points. Even the impairment-free >> case, like scenario B in section 4.1.1, needs to consider a minimum set >> of interface characteristics. In such case, only a few parameters used > 569,570c569,570 > < [RFC6163]). For the impairment-aware case these parameters may be > < sufficient or not depending on the accepted level of approximation > --- >> [RFC6163]). For the impairment-aware case, these parameters may or may >> not be sufficient depending on the accepted level of approximation > 572c572 > < consider a set of interface parameters during an Impairment > --- >> consider a set of interface parameters during the Impairment > 580,582c580,582 > < Options for this will be given in the next section on architectural > < alternatives. This block implementation (e.g. through routing, > < signaling or PCE) may influence the way the control plane distributes > --- >> Architectural alternatives to acommplish this are provided in >> section 4.2. This block implementation (e.g., through routing, >> signaling, or PCE) may influence the way the control plane distributes > 586,587c586,587 > < Depending on the IA level of approximation this function can be more > < or less complex. For example in case of no IA only the signal class > --- >> Depending on the IA level of approximation, this function can be more >> or less complex. For example, in the case of no IA, only the signal class > 599c599 > < taken in the physical modeling (worst-case, statistical or based on > --- >> taken in the physical modeling (worst-case, statistical, or based on > 602,603c602,603 > < marking some paths as not-feasible while they are very likely to be > < feasible in reality. > --- >> marking some paths as not-feasible which are very likely to be, in >> reality, feasible. > 609c609 > < From a control plane point of view optical impairments are additional > --- >> From a control plane point of view, optical impairments are additional > 614c614 > < Validation (estimation) (IV). > --- >> Validation (IV), i.e., estimation. > 618c618 > < point of view the following three forms of impairment validation will > --- >> point of view, the following three forms of impairment validation will > 623c623 > < In this case an Impairment Validation (IV) process furnishes a set of > --- >> In this case, an Impairment Validation (IV) process furnishes a set of > 630c630 > < discloses optical impairment information. Note that that this case > --- >> discloses optical impairment information. Note that this case > 634c634 > < In this case the control plane simply makes use of candidate paths > --- >> In this case, the control plane simply makes use of candidate paths > 636c636 > < is when the path validity is assessed within the control plane. The > --- >> is to assess the path validity within the control plane. The > 656c656 > < In this case an IV process is given a particular path and wavelength > --- >> In this case, an IV process is given a particular path and wavelength > 667c667 > < In this case impairments to a path are computed at a single entity. > --- >> In this case, impairments to a path are computed at a single entity. > 669c669 > < gathered from network elements. Depending how information is gathered > --- >> gathered from network elements. Depending how information is gathered, > 676c676 > < as OSNR, dispersion, DGD, etc. may be accumulated along the path via > --- >> as OSNR, dispersion, DGD, etc., may be accumulated along the path via > 679c679 > < measures reach the destination node a decision on the impairment > --- >> measures reach the destination node, a decision on the impairment > 685,686c685,686 > < The Control Plane must not preclude the possibility to operate one or > < all the above cases concurrently in the same network. For example > --- >> The Control Plane must not preclude the possibility to concurrently >> perform one or all the above cases in the same network. For example, > 690c690 > < same network however the control plane may compute a path outside the > --- >> same network, however, the control plane may compute a path outside the > 695c695 > < computation architectures and reviews some of their respective > --- >> computation architectures and review some of their respective > 708c708 > < solutions can be achieved if the path computation entity (PCE) can > --- >> solutions can be achieved if the Path Computation Entity (PCE) can > 710c710 > < wavelength assignment and impairment validation. > --- >> wavelength assignment, and impairment validation. > 718c718 > < Separating the processes of routing, WA and/or IV can reduce the need > --- >> Separating the processes of routing, WA, and/or IV can reduce the need > 721c721 > < [RFC6163]. In addition, as was discussed some impairment information > --- >> [RFC6163]. In addition, as was discussed, some impairment information > 724c724 > < precision it may be advantageous to offload this computation to a > --- >> precision, it may be advantageous to offload this computation to a > 735c735 > < validation is typically wavelength dependent hence combining WA > --- >> validation is typically wavelength dependent. Hence, combining WA > 743c743 > < selected path and wavelength. If IV comes first it would need to > --- >> selected path and wavelength. If IV comes first, it would need to > 749,751c749,751 > < In the non-impairment RWA situation [RFC6163] it was shown that a > < distributed wavelength assignment (WA) process carried out via > < signaling can eliminate the need to distribute wavelength > --- >> In the non-impairment RWA situation [RFC6163], it was shown that a >> distributed wavelength assignment (WA) process, carried out via >> signaling, can eliminate the need to distribute wavelength > 761,762c761,762 > < characteristics of network elements and links via routing protocols > < or by other means. So the following conceptual options belong to this > --- >> characteristics of network elements and links by routing protocols >> or other means. So the following conceptual options belong to this > 779,781c779,782 > < all wavelengths that could be used. This is somewhat windowed down as > < potential wavelengths are discovered to be in use, but could be a > < significant burden for lightly loaded high channel count networks. > --- >> all wavelengths that could be used. The amount of information is redunced >> somewhat as potential wavelengths are discovered to be in use, but could >> be a significant burden for lightly loaded network with high channel >> counts. > 785c786 > < Figure 2 shows process flows for three main architectural > --- >> Figure 2 shows process flows for the three main architectural > 787c788 > < sufficient. Figure 3 shows process flows for two main architectural > --- >> sufficient. Figure 3 shows process flows for the two main architectural > 841c842 > < The advantages, requirements and suitability of these options are as > --- >> The advantages, requirements, and suitability of these options are as > 847c848 > < entity enabling highest potential optimality and efficiency in IA- > --- >> entity enabling the highest potential optimality and efficiency in IA- > 870c871 > < and RWA are very different and prone to specialization. > --- >> and RWA are very different and conducive to specialization. > 874c875 > < In this alternative a signaling protocol may be extended and > --- >> In this alternative, a signaling protocol may be extended and > 877c878 > < optimality of optimality as (a) or (b), it does not require > --- >> optimality as (a) or (b), it does not require > 903c904 > < The advantages, requirements and suitability of these detailed > --- >> The advantages, requirements, and suitability of these detailed > 909,911c910,912 > < computation entity enabling highest potential optimality and > < efficiency in IA-RWA; then has a separate entity performing detailed > < impairment validation. In the case of "black links" the authority > --- >> computation entity enabling the highest potential optimality and >> efficiency in IA-RWA while a separate entity performs detailed >> impairment validation. In the case of "black links", the authority > 925c926 > < high degree of potential optimality and efficiency in IA-RWA; then a > --- >> high degree of potential optimality and efficiency in IA-RWA while a > 963,966c964,967 > < As previously discussed most IA-RWA scenarios to a greater or lesser > < extent rely on a common impairment information model. A number of > < ITU-T recommendations cover detailed as well as approximate > < impairment characteristics of fibers and a variety of devices and > --- >> As previously discussed, most IA-RWA scenarios rely, to a greater or lesser >> extent, on a common impairment information model. A number of >> ITU-T recommendations cover detailed, as well as, approximate >> impairment characteristics of fibers, a variety of devices, and > 979,980c980,981 > < the networks composed of a single WDM line system vendor combined > < with OADMs and/or PXCs from potentially multiple other vendors, this > --- >> networks composed of a single WDM line system vendor combined >> with OADMs and/or PXCs from potentially multiple other vendors. This > 982,984c983,985 > < planed in the future that [G.680] will include networks incorporating > < line systems from multiple vendors as well as OADMs and/or PXCs from > < potentially multiple other vendors, this is known as situation 2 and > --- >> planned in the future that [G.680] will include networks incorporating >> line systems from multiple vendors, as well as, OADMs and/or PXCs kfrom >> potentially from multiple other vendors. This is known as situation 2 and > 990c991 > < distributed IV case one needs to standardize the accumulated > --- >> distributed IV case, one needs to standardize the accumulated > 996c997 > < and in what form for the protocol would need to be standardized for > --- >> and in what form would need to be standardized for protocol > 1005c1006 > < Different approaches to path/wavelength impairment validation gives > --- >> Different approaches to path/wavelength impairment validation give > 1008c1009 > < paths GMPLS routing may be used to distribute the impairment > --- >> paths, GMPLS routing may be used to distribute the impairment > 1012,1013c1013,1014 > < Depending on the computational alternative the routing protocol may > < need to advertise information necessary to impairment validation > --- >> Depending on the computational alternative, the routing protocol may >> need to advertise information necessary to the impairment validation > 1015,1018c1016,1019 > < high amount of data that need to be advertised. Such issue can be > < addressed separating data that need to be advertised rarely and data > < that need to be advertised more frequently or adopting other form of > < awareness solutions described in previous sections (e.g. centralized > --- >> volume of data that needs to be advertised. Such issue can be >> addressed by separating data that need to be advertised rarely from data >> that need to be advertised more frequently or adopting the other forms of >> awareness solutions as described in previous sections (e.g., centralized > 1029,1030c1030,1031 > < In term of approximated scenario (see Section 4.1.1.) the model > < defined by [G.680] will apply and routing protocol will need to > --- >> In term of approximated scenario (see Section 4.1.1.), the model >> defined by [G.680] will apply and the routing protocols will need to > 1033c1034 > < In the case of distributed-IV no new demands would be placed on the > --- >> In the case of distributed-IV, no new demands would be placed on the > 1054c1055 > < In section 4.3. a number of computation architectural alternatives > --- >> In section 4.3, a number of computation architectural alternatives > 1058,1059c1059,1060 > < cooperating PCEs, and the impacts on the PCEP protocol. This document > < is providing this evaluation to aid solutions work. The protocol > --- >> cooperating PCEs, and the impacts on the PCEP. This document >> provide this evaluation to aid solutions work. The protocol > 1085c1086 > < wavelength. If the computations could not complete successfully it > --- >> wavelength. If the computations could not complete successfully, it > 1087,1088c1088,1089 > < it is of interest to know if this was due to lack of wavelength > < availability or impairment considerations or both. The information > --- >> it is of interest to know if failure was due to lack of wavelength >> availability, impairment considerations, or both. The information > 1098c1099 > < functionality can be added to one of previously defined entities. > --- >> functionality could be added to one of previously defined entities. > 1100c1101 > < process coordinator. The roles, responsibilities and information > --- >> process coordinator. The roles, responsibilities, and information > 1107,1108c1108,1109 > < as needed during RWA computations. In particular it needs to know to > < use the Candidates-PCE to obtain potential set of routes and > --- >> as needed during RWA computations. In particular, it needs to know to >> use the Candidates-PCE to obtain the potential set of routes and > 1130c1131 > < computation. It needs not take into account current link wavelength > --- >> computation. It need not take into account current link wavelength > 1139,1140c1140,1141 > < initiating PCC. (Note: RWA-Coord PCE is also a PCC with respect to > < the IV-Candidate) > --- >> initiating PCC. Note that the RWA-Coord PCE is also a PCC with respect to >> the IV-Candidate. > 1174c1175 > < Coordinating-PCE and the IV-Candidates-PCE. > --- >> Coordinating-PCE, and the IV-Candidates-PCE. > 1176c1177 > < In step (a) the PCC requests a path meeting specified quality > --- >> In step (a), the PCC requests a path meeting specified quality > 1179,1181c1180,1182 > < associated parameters. In step (b) the RWA-Coordinating-PCE requests > < up to K candidate paths between nodes A and Z and associated > < acceptable wavelengths. In step (c) The IV-Candidates PCE returns > --- >> associated parameters. In step (b), the RWA-Coordinating-PCE requests >> up to K candidate paths and their associated acceptable wavelengths >> between nodes A and Z . In step (c), the IV-Candidates PCE returns > 1183c1184 > < paths and wavelengths as input (e.g. a constraint) to its RWA > --- >> paths and wavelengths as input (e.g., a constraint) to its RWA > 1191c1192 > < computation. In step (d) the RWA-Coordinating PCE returns the overall > --- >> computation. In step (d), the RWA-Coordinating PCE returns the overall > 1196c1197 > < Previously Figure 3 showed two cases where a separate detailed > --- >> Previously, Figure 3 showed two cases where a separate detailed > 1200c1201 > < the PCC it is possible to keep the interactions with this separate > --- >> the PCC, it is possible to keep the interactions with this separate > 1211c1212 > < will furnish signal characteristics, quality requirements, path > --- >> will furnish signal characteristics, quality requirements, path, > 1216c1217 > < actually be met. In the case where the impairment validation fails > --- >> actually be met. In the case where the impairment validation fails, > 1218c1219 > < quantify the failure, e.g., so a judgment can be made whether to > --- >> quantify the failure, e.g., so that a judgment can be made whether to > 1221c1222 > < Figure 6 shows a sequence diagram for the interactions for the > --- >> Figure 6 shows a sequence diagram for the interactions corresponding to the > 1223c1224 > < PCC, RWA-PCE (acting as coordinator), IV-Candidates-PCE and the IV- > --- >> PCC, RWA-PCE (acting as coordinator), IV-Candidates-PCE, and the IV- > 1226c1227 > < In step (a) the PCC requests a path meeting specified quality > --- >> In step (a), the PCC requests a path meeting specified quality > 1229,1231c1230,1232 > < associated parameters. In step (b) the RWA-Coordinating-PCE requests > < up to K candidate paths between nodes A and Z and associated > < acceptable wavelengths. In step (c) The IV-Candidates-PCE returns > --- >> associated parameters. In step (b), the RWA-Coordinating-PCE requests >> up to K candidate paths and their associated acceptable wavelengths >> between nodes A and Z. In step (c), the IV-Candidates-PCE returns > 1233,1234c1234,1235 > < paths and wavelengths as input (e.g. a constraint) to its RWA > < computation. In step (d) the RWA-Coordinating-PCE request a detailed > --- >> paths and wavelengths as input (e.g., a constraint) to its RWA >> computation. In step (d), the RWA-Coordinating-PCE requests a detailed > 1236,1237c1237,1238 > < (e) the IV-Detailed-PCE returns the results of the validation to the > < RWA-Coordinating-PCE. Finally in step (f)IA-RWA-Coordinating PCE > --- >> (e), the IV-Detailed-PCE returns the results of this validation to the >> RWA-Coordinating-PCE. Finally in step (f), the IA-RWA-Coordinating PCE > 1277c1278 > < Coordinating-PCE, IV-Candidates-PCE and IV-Detailed-PCE. > --- >> Coordinating-PCE, IV-Candidates-PCE, and IV-Detailed-PCE. > 1285c1286 > < architecture is put into use within a network it will by its nature > --- >> architecture is put into use within a network, it will by its nature > 1290c1291 > < work will address any issues on the use of impairment information. > --- >> work will address any issues on the protection of impairment information. > > Thanks, > Acee > > From acee.lindem@ericsson.com Fri Oct 21 14:49:05 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44ACB21F8A70; Fri, 21 Oct 2011 14:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.512 X-Spam-Level: X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38qKUuhgffCq; Fri, 21 Oct 2011 14:49:02 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7DFC521F8A6C; Fri, 21 Oct 2011 14:49:02 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p9LLmt7x031656; Fri, 21 Oct 2011 16:48:57 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.60]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 21 Oct 2011 17:48:49 -0400 From: Acee Lindem To: Leeyoung Date: Fri, 21 Oct 2011 17:48:46 -0400 Thread-Topic: Routing-Directory Review of "A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments" - draft-ietf-ccamp-wson-impairments-07.txt Thread-Index: AcyQOzbVTmBaUu2OS5GoIBUidWBZtw== Message-ID: <432264E0-158A-428B-8D7C-171FA912AB25@ericsson.com> References: <486FA0F6-EE68-4AAA-AA12-58F43B1F6903@ericsson.com> <7AEB3D6833318045B4AE71C2C87E8E171817FD6E@DFWEML501-MBX.china.huawei.com> <7AEB3D6833318045B4AE71C2C87E8E1718182301@DFWEML501-MBX.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1718182301@DFWEML501-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 23 Oct 2011 12:18:50 -0700 Cc: "adrian@olddog.co.uk" , "iesg@ietf.org" , "draft-ietf-ccamp-wson-impairments@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Routing-Directory Review of "A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments" - draft-ietf-ccamp-wson-impairments-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 21:49:05 -0000 Hi Young, I believe you've addressed all my comments. Thanks, Acee On Oct 21, 2011, at 8:24 AM, Leeyoung wrote: > Hi Acee, > > Thanks a lot for your feedback. I think we are merging. Please see in-lin= e for my comment. > If you are satisfied with these changes, I will update the revision. > > Thanks, > Young > > -----Original Message----- > From: Acee Lindem [mailto:acee.lindem@ericsson.com] > Sent: Thursday, October 13, 2011 9:26 AM > To: Leeyoung > Subject: Re: Routing-Directory Review of "A Framework for the Control of = Wavelength Switched Optical Networks (WSON) with Impairments" - draft-ietf-= ccamp-wson-impairments-07.txt > > Hi Young, > > On Oct 11, 2011, at 9:09 PM, Leeyoung wrote: > >> Hi Acee, >> >> Thanks for your thorough review and suggestions. Please see in-line if m= y response would satisfy you. Before I edit, I just wanted to know if these= would be good enough for you. >> >> Thanks. >> >> Young >> >> -----Original Message----- >> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >> Sent: Monday, October 10, 2011 12:16 PM >> To: Greg Bernstein; Huawei danli; Leeyoung; Giovanni Martinelli >> Cc: rtg-dir@ietf.org; ccamp-chairs@tools.ietf.org; Adrian Farrel >> Subject: Routing-Directory Review of "A Framework for the Control of Wav= elength Switched Optical Networks (WSON) with Impairments" - draft-ietf-cca= mp-wson-impairments-07.txt >> >> Hello, >> >> I have been selected as the Routing Directorate reviewer for this draft.= The Routing Directorate seeks to review all routing or routing-related dra= fts as they pass through IETF last call and IESG review. The purpose of the= review is to provide assistance to the Routing ADs. For more information a= bout the Routing Directorate, please see http://www.ietf.org/iesg/directora= te/routing.html >> >> Although these comments are primarily for the use of the Routing ADs, it= would be helpful if you could consider them along with any other IETF Last= Call comments that you receive, and strive to resolve them through discuss= ion or by updating the draft. >> >> >> Document: draft-ietf-ccamp-wson-impairments-07.txt >> Reviewer: Acee Lindem >> Review Date: 2011-10-10 >> IETF LC End Date: TBD >> Intended Status: Informational >> >> Summary: >> I have no major concerns about this document that I think must be >> resolved before publication. I have some suggestions below. >> >> Major Issues: >> No major issues found. >> >> Minor Issues: >> The document is somewhat hard to read and I've included some editorial s= uggestions below. Some of tthese are subjective and style based. For exampl= e, I prefer a comma after a prepositional phase preceding an independent cl= ause. Other suggested edits are obvious typos (so you'll need to look at th= em all ;^). >> >> Additionally, I'd suggest the following: >> >> Abstract: Mention the components included in the framework in the abstra= ct and introduction >> to set the context for the remainder of the document. >> >> Current Abstract: >> >> As an optical signal progresses along its path it may be altered by the = various physical processes in the optical fibers and devices it encounters.= When such alterations result in signal degradation, these processes are us= ually referred to as "impairments". These physical characteristics may be i= mportant constraints to consider when using a GMPLS control plane to suppor= t path setup and maintenance in wavelength switched optical networks. >> This document provides a framework for applying GMPLS protocols and the = PCE architecture to support Impairment Aware Routing and Wavelength Assignm= ent (IA-RWA) in wavelength switched optical networks. This document does no= t define optical data plane aspects; impairment parameters, measurement of,= or assessment and qualification of a route, but rather it describes the ar= chitectural and information components for protocol solutions. >> >> Suggested Abstract: >> >> As an optical signal progresses along its path it may be altered by the = various physical processes in the optical fibers and devices it encounters.= When such alterations result in signal degradation, these processes are us= ually referred to as "impairments". These physical characteristics may be i= mportant constraints to consider when using a GMPLS control plane to suppor= t path setup and maintenance in wavelength switched optical networks. >> This document provides a framework for applying GMPLS protocols and the = PCE architecture to support Impairment Aware Routing and Wavelength Assignm= ent (IA-RWA) in wavelength switched optical networks. Specifically, this do= cuments discusses key computing constraints, scenarios and impairment estim= ation processes. This document does not define optical data plane aspects; = impairment parameters, measurement of, or assessment and qualification of a= route, but rather it describes the architectural and information component= s for protocol solutions. > > That's better - do you think it should mention the architectural processe= s: Routing, Wavelength Assignment, and Impairment Validation. > > YOUNG>> I will add these processes in the abstract. The new text will loo= k like as follows: > > As an optical signal progresses along its path it may be altered by the v= arious physical processes in the optical fibers and devices it encounters. = When such alterations result in signal degradation, these processes are usu= ally referred to as "impairments". These physical characteristics may be im= portant constraints to consider when using a GMPLS control plane to support= path setup and maintenance in wavelength switched optical networks. > This document provides a framework for applying GMPLS protocols and the P= CE architecture to support Impairment Aware Routing and Wavelength Assignme= nt (IA-RWA) in wavelength switched optical networks. Specifically, this doc= uments discusses key computing constraints, scenarios and architectural pro= cesses: Routing, Wavelength Assignment, and Impairment Validation. This doc= ument does not define optical data plane aspects; impairment parameters, me= asurement of, or assessment and qualification of a route, but rather it des= cribes the architectural and information components for protocol solutions. > > >> >> 2 - Include "black link". >> >> Black links: Black links refer to tributary interfaces where only link c= haracteristics are defined. This approach enables transverse compatibility = at the single-channel point using a direct wavelength-multiplexing configur= ation. > > Ok. > >> >> 4.1.1, Scenario D - The detailed case is designated as out of scope yet = it is referred to >> in later sections. For example, section 4.3. >> >> I am not sure where in Section 4.3 we are referring to Scenario D. All t= he discussions in section 4.3 are actually in the spirit of Scenario C - ap= proximated impairment estimation. > > Then it is unclear to me what the difference is between IV and IV-Detaile= d in the remainder of the document. > > YOUNG>> I realized that Scenario D - Detailed is a confusing term since w= e use IV-Detailed in the remainder of the document. In section 4.1.1. Scena= rio D - the detailed case is now changed to "Accurate Impairment Computatio= n." > > YOUNG>> I also added the following text: "All the variations of impairmen= t validation discussed in this section is based on Scenario C (Approximated= Impairment Estimation) as discussed in Section 4.1.1." is section 4.2. to = make sure we are discussing all IV discussion in the spirit of Scenario C. > > >> >> 4.1.3 - What is the Q factor? >> >> The Q-factor provides a qualitative description of the receiver performa= nce. It is a function of the signal to noise ratio (optical). The Q-factor = suggests the minimum SNR required to obtain a specific BER for a given sign= al. (Would you like to suggest Q-factor in the definition?) > > Yes - that would be good. > >> >> 4.2 - Explain what you mean by "at-most K paths". Define K. >> >> K refers to the "K" value in K-shortest path algorithm. > > I see I get a lot of Google hits on this but I had never heard of it befo= re and I work on SPF and LFA. Could you add a definition and, possibly, a r= eference? > > YOUNG>> Yes. I will add the definition and reference as follows: > > K-shortest path algorithm refers to an algorithm that finds multiple (k) = short paths connecting the source and the destination in a graph (allowing = repeated vertices and edges in the paths). > > D. Eppstein. "Finding the k shortest paths," 35th IEEE Symp. Foundations = of Comp. Sci., Santa Fe, 1994, pp. 154-165. > >> >> 4.2 - Why is there assumed to be one IV process and multiple RWA process= es? >> >> Actually section 4.2 shows a number of options as to how to do with R an= d WA with respect to IV. R and WA can be combined before IV; or sequentiall= y R, WA and IV; or once R is determined WA can be done in a distributed fas= hion with IV on a hop by hop. >> >> General: Would it make sense to include a discussion of the order in whi= ch >> PCE, WA, and IV should be done to avoid redundant computation? >> >> Figures 5 and 6 show each entity that involves R, WA and IV (detail, app= roximation) respectively. I thought these figures show non-redundant comput= ation in a sequential manner. > > > It is implied and maybe obvious to those familiar with optical path compu= tation. However, it occurred to me that other functional distributions woul= dn't work (at least not without lots of inefficiency ;^). > > YOUNG>> Actually I will add the following text in Section 5.4.3. "Please = note that there is some inefficiency by separating the IV-Candidates-PCE fr= om the IV-Detailed-PCE from a message flow perspective in order to achieve = a high degree of potential optimality." > > Thanks, > Acee > > >> >> Editorial Comments: >> >> Missing acronyms expansions: ADM, NEs, OSNR, DGD, PXCs, and OADMs >> > > YOUNG>> I will add the following acronyms: > > ADM: Add Drop Multiplexer > NEs: Network Elements > OSNR: Optical Signal to Noise Ratio > DGD: differential group delay > PXCs: Photonic Cross Connects > OADMs: Optical Add Drop Multiplexers >> >> Acee-Lindems-MacBook-Pro:Desktop ealflin$ diff draft-ietf-ccamp-wson-imp= airments-07.txt.orig draft-ietf-ccamp-wson-impairments-07.txt >> 136c136 >> < As an optical signal progresses along its path it may be altered by >> --- >>> As an optical signal progresses along its path, it may be altered by >> 142c142 >> < used, the types and placement of various optical devices and the >> --- >>> used, the types and placement of various optical devices, and the >> 149c149 >> < a WSON, a combination of path continuity, resource availability and >> --- >>> a WSON, a combination of path continuity, resource availability, and >> 157c157 >> < that use time division multiplexing, and WDM. The Path Computation >> --- >>> that use time division multiplexing and WDM. The Path Computation >> 189c189 >> < CWDM: Coarse Wavelength Division Multiplexing. >> --- >>> CWDM: Coarse Wavelength Division Multiplexing >> 191c191 >> < DWDM: Dense Wavelength Division Multiplexing. >> --- >>> DWDM: Dense Wavelength Division Multiplexing >> 193c193 >> < FOADM: Fixed Optical Add/Drop Multiplexer. >> --- >>> FOADM: Fixed Optical Add/Drop Multiplexer >> 195c195 >> < GMPLS: Generalized Multi-Protocol Label Switching. >> --- >>> GMPLS: Generalized Multi-Protocol Label Switching >> 204c204 >> < OXC: Optical cross connect. An optical switching element in which a >> --- >>> OXC: Optical cross connect - An optical switching element in which a >> 207c207 >> < PCC: Path Computation Client. Any client application requesting a >> --- >>> PCC: Path Computation Client - Any client application requesting a >> 210c210 >> < PCE: Path Computation Element. An entity (component, application, = or >> --- >>> PCE: Path Computation Element - An entity (component, application, or >> 219c219 >> < PCEP: PCE Communication Protocol. The communication protocol betwee= n >> --- >>> PCEP: PCE Communication Protocol - The communication protocol between >> 222c222 >> < ROADM: Reconfigurable Optical Add/Drop Multiplexer. A wavelength >> --- >>> ROADM: Reconfigurable Optical Add/Drop Multiplexer - A wavelength >> 226c226 >> < RWA: Routing and Wavelength Assignment. >> --- >>> RWA: Routing and Wavelength Assignment >> 247c247 >> < WDM: Wavelength Division Multiplexing. >> --- >>> WDM: Wavelength Division Multiplexing >> 281c281 >> < cross connects to increase network flexibility. In such cases >> --- >>> cross connects to increase network flexibility. In such cases, >> 335,336c335,336 >> < contains transparent elements and electro-optical elements such as >> < OEO regenerations. In such networks a generic light path can go >> --- >>> contain transparent elements and electro-optical elements such as >>> OEO regenerations. In such networks, a generic light path can go >> 341,342c341,342 >> < (i) wavelength conversion to assist RWA to avoid wavelength blockin= g. >> < This is the impairment free case covered by [RFC6163]. >> --- >>> (i) Due to wavelength conversion to assist RWA to avoid wavelength >>> blocking. This is the impairment free case covered by [RFC6163]. >> 344,345c344,345 >> < (ii) the optical signal without regeneration would be too degraded >> < to meet end to end BER requirements. This is the case when RWA >> --- >>> (ii) The optical signal without regeneration would be too degraded >>> to meet end-to-end BER requirements. This is the case when RWA >> 349c349 >> < In the latter case an optical path can be seen as a set of transparent >> --- >>> In the latter case, an optical path can be seen as a set of transparent >> 371,372c371,372 >> < constraints that an impairment aware optical control plane may have >> < to operate under. These requirements and constraints motivate the I= A- >> --- >>> constraints under which an impairment aware optical control plane may = have >>> to operate. These requirements and constraints motivate the IA- >> 396,397c396,397 >> < In this case impairments are only taken into account during network >> < design and after that, for example during optical path computation, >> --- >>> In this case, impairments are only taken into account during network >>> design. After that, for example during optical path computation, >> 452c452 >> < channel interfaces to multi-channel DWDM systems only the single >> --- >>> channel interfaces to multi-channel DWDM systems, only the single >> 456c456 >> < available. Note however the overall impact of a black link at the >> --- >>> available. However, note that the overall impact of a black link at th= e >> 461c461 >> < spans and to estimate the validity of optical paths. For example, >> --- >>> spans in order to estimate the validity of optical paths. For example, >> 468c468 >> < for optical networks with "black links" (path) could not be perform= ed >> --- >>> for optical networks with "black links" in the path could not be perfo= rmed >> 473c473 >> < entity. Such a vendor specific IA computation, could utilize >> --- >>> entity. Such a vendor specific IA computation could utilize >> 477c477 >> < In the following the term "black links" will be used to describe >> --- >>> In the following, the term "black links" will be used to describe >> 479c479 >> < networks. From the control plane perspective the following options >> --- >>> networks. From the control plane perspective, the following options >> 493,495c493,495 >> < computation entity. The difficulty here is for larger networks >> < such a list of paths along with any wavelength constraints could >> < get unmanageably large. >> --- >>> computation entity. The difficulty here is that such a list of >>> paths along with any wavelength constraints could get unmanageably >>> large as the size of the network increases. >> 497,498c497,498 >> < 2. The authority in control of the "black links" could provide a PC= E >> < like entity a list of viable paths/wavelengths between two >> --- >>> 2. The authority in control of the "black links" could provide a >>> PCE-like entity that returns a list of viable paths/wavelengths bet= ween two >> 500,501c500,501 >> < and can reduce the scaling issue previously mentioned. Such a PC= E >> < like entity would not need to perform a full RWA computation, >> --- >>> and can reduce the scaling issue previously mentioned. Such a PCE-l= ike >>> entity would not need to perform a full RWA computation, >> 563c563 >> < Starting from functional block on the left the Optical Interface >> --- >>> Starting from functional block on the left, the Optical Interface >> 565,567c565,567 >> < defines the properties at the path end points. Even the no-impairme= nt >> < case like scenario B in section 4.1.1 needs to consider a minimum s= et >> < of interface characteristics. In such case only a few parameters us= ed >> --- >>> defines the properties at the path end-points. Even the impairment-fre= e >>> case, like scenario B in section 4.1.1, needs to consider a minimum se= t >>> of interface characteristics. In such case, only a few parameters used >> 569,570c569,570 >> < [RFC6163]). For the impairment-aware case these parameters may be >> < sufficient or not depending on the accepted level of approximation >> --- >>> [RFC6163]). For the impairment-aware case, these parameters may or may >>> not be sufficient depending on the accepted level of approximation >> 572c572 >> < consider a set of interface parameters during an Impairment >> --- >>> consider a set of interface parameters during the Impairment >> 580,582c580,582 >> < Options for this will be given in the next section on architectural >> < alternatives. This block implementation (e.g. through routing, >> < signaling or PCE) may influence the way the control plane distribut= es >> --- >>> Architectural alternatives to acommplish this are provided in >>> section 4.2. This block implementation (e.g., through routing, >>> signaling, or PCE) may influence the way the control plane distributes >> 586,587c586,587 >> < Depending on the IA level of approximation this function can be mor= e >> < or less complex. For example in case of no IA only the signal class >> --- >>> Depending on the IA level of approximation, this function can be more >>> or less complex. For example, in the case of no IA, only the signal cl= ass >> 599c599 >> < taken in the physical modeling (worst-case, statistical or based on >> --- >>> taken in the physical modeling (worst-case, statistical, or based on >> 602,603c602,603 >> < marking some paths as not-feasible while they are very likely to be >> < feasible in reality. >> --- >>> marking some paths as not-feasible which are very likely to be, in >>> reality, feasible. >> 609c609 >> < From a control plane point of view optical impairments are addition= al >> --- >>> From a control plane point of view, optical impairments are additional >> 614c614 >> < Validation (estimation) (IV). >> --- >>> Validation (IV), i.e., estimation. >> 618c618 >> < point of view the following three forms of impairment validation wi= ll >> --- >>> point of view, the following three forms of impairment validation will >> 623c623 >> < In this case an Impairment Validation (IV) process furnishes a set = of >> --- >>> In this case, an Impairment Validation (IV) process furnishes a set of >> 630c630 >> < discloses optical impairment information. Note that that this case >> --- >>> discloses optical impairment information. Note that this case >> 634c634 >> < In this case the control plane simply makes use of candidate paths >> --- >>> In this case, the control plane simply makes use of candidate paths >> 636c636 >> < is when the path validity is assessed within the control plane. The >> --- >>> is to assess the path validity within the control plane. The >> 656c656 >> < In this case an IV process is given a particular path and wavelengt= h >> --- >>> In this case, an IV process is given a particular path and wavelength >> 667c667 >> < In this case impairments to a path are computed at a single entity. >> --- >>> In this case, impairments to a path are computed at a single entity. >> 669c669 >> < gathered from network elements. Depending how information is gather= ed >> --- >>> gathered from network elements. Depending how information is gathered, >> 676c676 >> < as OSNR, dispersion, DGD, etc. may be accumulated along the path vi= a >> --- >>> as OSNR, dispersion, DGD, etc., may be accumulated along the path via >> 679c679 >> < measures reach the destination node a decision on the impairment >> --- >>> measures reach the destination node, a decision on the impairment >> 685,686c685,686 >> < The Control Plane must not preclude the possibility to operate one = or >> < all the above cases concurrently in the same network. For example >> --- >>> The Control Plane must not preclude the possibility to concurrently >>> perform one or all the above cases in the same network. For example, >> 690c690 >> < same network however the control plane may compute a path outside t= he >> --- >>> same network, however, the control plane may compute a path outside th= e >> 695c695 >> < computation architectures and reviews some of their respective >> --- >>> computation architectures and review some of their respective >> 708c708 >> < solutions can be achieved if the path computation entity (PCE) can >> --- >>> solutions can be achieved if the Path Computation Entity (PCE) can >> 710c710 >> < wavelength assignment and impairment validation. >> --- >>> wavelength assignment, and impairment validation. >> 718c718 >> < Separating the processes of routing, WA and/or IV can reduce the ne= ed >> --- >>> Separating the processes of routing, WA, and/or IV can reduce the need >> 721c721 >> < [RFC6163]. In addition, as was discussed some impairment informatio= n >> --- >>> [RFC6163]. In addition, as was discussed, some impairment information >> 724c724 >> < precision it may be advantageous to offload this computation to a >> --- >>> precision, it may be advantageous to offload this computation to a >> 735c735 >> < validation is typically wavelength dependent hence combining WA >> --- >>> validation is typically wavelength dependent. Hence, combining WA >> 743c743 >> < selected path and wavelength. If IV comes first it would need to >> --- >>> selected path and wavelength. If IV comes first, it would need to >> 749,751c749,751 >> < In the non-impairment RWA situation [RFC6163] it was shown that a >> < distributed wavelength assignment (WA) process carried out via >> < signaling can eliminate the need to distribute wavelength >> --- >>> In the non-impairment RWA situation [RFC6163], it was shown that a >>> distributed wavelength assignment (WA) process, carried out via >>> signaling, can eliminate the need to distribute wavelength >> 761,762c761,762 >> < characteristics of network elements and links via routing protocols >> < or by other means. So the following conceptual options belong to th= is >> --- >>> characteristics of network elements and links by routing protocols >>> or other means. So the following conceptual options belong to this >> 779,781c779,782 >> < all wavelengths that could be used. This is somewhat windowed down = as >> < potential wavelengths are discovered to be in use, but could be a >> < significant burden for lightly loaded high channel count networks. >> --- >>> all wavelengths that could be used. The amount of information is redun= ced >>> somewhat as potential wavelengths are discovered to be in use, but cou= ld >>> be a significant burden for lightly loaded network with high channel >>> counts. >> 785c786 >> < Figure 2 shows process flows for three main architectural >> --- >>> Figure 2 shows process flows for the three main architectural >> 787c788 >> < sufficient. Figure 3 shows process flows for two main architectural >> --- >>> sufficient. Figure 3 shows process flows for the two main architectura= l >> 841c842 >> < The advantages, requirements and suitability of these options are a= s >> --- >>> The advantages, requirements, and suitability of these options are as >> 847c848 >> < entity enabling highest potential optimality and efficiency in IA- >> --- >>> entity enabling the highest potential optimality and efficiency in IA- >> 870c871 >> < and RWA are very different and prone to specialization. >> --- >>> and RWA are very different and conducive to specialization. >> 874c875 >> < In this alternative a signaling protocol may be extended and >> --- >>> In this alternative, a signaling protocol may be extended and >> 877c878 >> < optimality of optimality as (a) or (b), it does not require >> --- >>> optimality as (a) or (b), it does not require >> 903c904 >> < The advantages, requirements and suitability of these detailed >> --- >>> The advantages, requirements, and suitability of these detailed >> 909,911c910,912 >> < computation entity enabling highest potential optimality and >> < efficiency in IA-RWA; then has a separate entity performing detaile= d >> < impairment validation. In the case of "black links" the authority >> --- >>> computation entity enabling the highest potential optimality and >>> efficiency in IA-RWA while a separate entity performs detailed >>> impairment validation. In the case of "black links", the authority >> 925c926 >> < high degree of potential optimality and efficiency in IA-RWA; then = a >> --- >>> high degree of potential optimality and efficiency in IA-RWA while a >> 963,966c964,967 >> < As previously discussed most IA-RWA scenarios to a greater or lesse= r >> < extent rely on a common impairment information model. A number of >> < ITU-T recommendations cover detailed as well as approximate >> < impairment characteristics of fibers and a variety of devices and >> --- >>> As previously discussed, most IA-RWA scenarios rely, to a greater or l= esser >>> extent, on a common impairment information model. A number of >>> ITU-T recommendations cover detailed, as well as, approximate >>> impairment characteristics of fibers, a variety of devices, and >> 979,980c980,981 >> < the networks composed of a single WDM line system vendor combined >> < with OADMs and/or PXCs from potentially multiple other vendors, thi= s >> --- >>> networks composed of a single WDM line system vendor combined >>> with OADMs and/or PXCs from potentially multiple other vendors. This >> 982,984c983,985 >> < planed in the future that [G.680] will include networks incorporati= ng >> < line systems from multiple vendors as well as OADMs and/or PXCs fro= m >> < potentially multiple other vendors, this is known as situation 2 an= d >> --- >>> planned in the future that [G.680] will include networks incorporating >>> line systems from multiple vendors, as well as, OADMs and/or PXCs kfro= m >>> potentially from multiple other vendors. This is known as situation 2 = and >> 990c991 >> < distributed IV case one needs to standardize the accumulated >> --- >>> distributed IV case, one needs to standardize the accumulated >> 996c997 >> < and in what form for the protocol would need to be standardized for >> --- >>> and in what form would need to be standardized for protocol >> 1005c1006 >> < Different approaches to path/wavelength impairment validation gives >> --- >>> Different approaches to path/wavelength impairment validation give >> 1008c1009 >> < paths GMPLS routing may be used to distribute the impairment >> --- >>> paths, GMPLS routing may be used to distribute the impairment >> 1012,1013c1013,1014 >> < Depending on the computational alternative the routing protocol may >> < need to advertise information necessary to impairment validation >> --- >>> Depending on the computational alternative, the routing protocol may >>> need to advertise information necessary to the impairment validation >> 1015,1018c1016,1019 >> < high amount of data that need to be advertised. Such issue can be >> < addressed separating data that need to be advertised rarely and dat= a >> < that need to be advertised more frequently or adopting other form o= f >> < awareness solutions described in previous sections (e.g. centralize= d >> --- >>> volume of data that needs to be advertised. Such issue can be >>> addressed by separating data that need to be advertised rarely from da= ta >>> that need to be advertised more frequently or adopting the other forms= of >>> awareness solutions as described in previous sections (e.g., centraliz= ed >> 1029,1030c1030,1031 >> < In term of approximated scenario (see Section 4.1.1.) the model >> < defined by [G.680] will apply and routing protocol will need to >> --- >>> In term of approximated scenario (see Section 4.1.1.), the model >>> defined by [G.680] will apply and the routing protocols will need to >> 1033c1034 >> < In the case of distributed-IV no new demands would be placed on the >> --- >>> In the case of distributed-IV, no new demands would be placed on the >> 1054c1055 >> < In section 4.3. a number of computation architectural alternatives >> --- >>> In section 4.3, a number of computation architectural alternatives >> 1058,1059c1059,1060 >> < cooperating PCEs, and the impacts on the PCEP protocol. This docume= nt >> < is providing this evaluation to aid solutions work. The protocol >> --- >>> cooperating PCEs, and the impacts on the PCEP. This document >>> provide this evaluation to aid solutions work. The protocol >> 1085c1086 >> < wavelength. If the computations could not complete successfully = it >> --- >>> wavelength. If the computations could not complete successfully, it >> 1087,1088c1088,1089 >> < it is of interest to know if this was due to lack of wavelength >> < availability or impairment considerations or both. The informati= on >> --- >>> it is of interest to know if failure was due to lack of wavelength >>> availability, impairment considerations, or both. The information >> 1098c1099 >> < functionality can be added to one of previously defined entities. >> --- >>> functionality could be added to one of previously defined entities. >> 1100c1101 >> < process coordinator. The roles, responsibilities and information >> --- >>> process coordinator. The roles, responsibilities, and information >> 1107,1108c1108,1109 >> < as needed during RWA computations. In particular it needs to know t= o >> < use the Candidates-PCE to obtain potential set of routes and >> --- >>> as needed during RWA computations. In particular, it needs to know to >>> use the Candidates-PCE to obtain the potential set of routes and >> 1130c1131 >> < computation. It needs not take into account current link wavelength >> --- >>> computation. It need not take into account current link wavelength >> 1139,1140c1140,1141 >> < initiating PCC. (Note: RWA-Coord PCE is also a PCC with respect to >> < the IV-Candidate) >> --- >>> initiating PCC. Note that the RWA-Coord PCE is also a PCC with respect= to >>> the IV-Candidate. >> 1174c1175 >> < Coordinating-PCE and the IV-Candidates-PCE. >> --- >>> Coordinating-PCE, and the IV-Candidates-PCE. >> 1176c1177 >> < In step (a) the PCC requests a path meeting specified quality >> --- >>> In step (a), the PCC requests a path meeting specified quality >> 1179,1181c1180,1182 >> < associated parameters. In step (b) the RWA-Coordinating-PCE request= s >> < up to K candidate paths between nodes A and Z and associated >> < acceptable wavelengths. In step (c) The IV-Candidates PCE returns >> --- >>> associated parameters. In step (b), the RWA-Coordinating-PCE requests >>> up to K candidate paths and their associated acceptable wavelengths >>> between nodes A and Z . In step (c), the IV-Candidates PCE returns >> 1183c1184 >> < paths and wavelengths as input (e.g. a constraint) to its RWA >> --- >>> paths and wavelengths as input (e.g., a constraint) to its RWA >> 1191c1192 >> < computation. In step (d) the RWA-Coordinating PCE returns the overa= ll >> --- >>> computation. In step (d), the RWA-Coordinating PCE returns the overall >> 1196c1197 >> < Previously Figure 3 showed two cases where a separate detailed >> --- >>> Previously, Figure 3 showed two cases where a separate detailed >> 1200c1201 >> < the PCC it is possible to keep the interactions with this separate >> --- >>> the PCC, it is possible to keep the interactions with this separate >> 1211c1212 >> < will furnish signal characteristics, quality requirements, path >> --- >>> will furnish signal characteristics, quality requirements, path, >> 1216c1217 >> < actually be met. In the case where the impairment validation fai= ls >> --- >>> actually be met. In the case where the impairment validation fails, >> 1218c1219 >> < quantify the failure, e.g., so a judgment can be made whether to >> --- >>> quantify the failure, e.g., so that a judgment can be made whether = to >> 1221c1222 >> < Figure 6 shows a sequence diagram for the interactions for the >> --- >>> Figure 6 shows a sequence diagram for the interactions corresponding t= o the >> 1223c1224 >> < PCC, RWA-PCE (acting as coordinator), IV-Candidates-PCE and the IV- >> --- >>> PCC, RWA-PCE (acting as coordinator), IV-Candidates-PCE, and the IV- >> 1226c1227 >> < In step (a) the PCC requests a path meeting specified quality >> --- >>> In step (a), the PCC requests a path meeting specified quality >> 1229,1231c1230,1232 >> < associated parameters. In step (b) the RWA-Coordinating-PCE request= s >> < up to K candidate paths between nodes A and Z and associated >> < acceptable wavelengths. In step (c) The IV-Candidates-PCE returns >> --- >>> associated parameters. In step (b), the RWA-Coordinating-PCE requests >>> up to K candidate paths and their associated acceptable wavelengths >>> between nodes A and Z. In step (c), the IV-Candidates-PCE returns >> 1233,1234c1234,1235 >> < paths and wavelengths as input (e.g. a constraint) to its RWA >> < computation. In step (d) the RWA-Coordinating-PCE request a detaile= d >> --- >>> paths and wavelengths as input (e.g., a constraint) to its RWA >>> computation. In step (d), the RWA-Coordinating-PCE requests a detailed >> 1236,1237c1237,1238 >> < (e) the IV-Detailed-PCE returns the results of the validation to th= e >> < RWA-Coordinating-PCE. Finally in step (f)IA-RWA-Coordinating PCE >> --- >>> (e), the IV-Detailed-PCE returns the results of this validation to the >>> RWA-Coordinating-PCE. Finally in step (f), the IA-RWA-Coordinating PCE >> 1277c1278 >> < Coordinating-PCE, IV-Candidates-PCE and IV-Detailed-PCE. >> --- >>> Coordinating-PCE, IV-Candidates-PCE, and IV-Detailed-PCE. >> 1285c1286 >> < architecture is put into use within a network it will by its nature >> --- >>> architecture is put into use within a network, it will by its nature >> 1290c1291 >> < work will address any issues on the use of impairment information. >> --- >>> work will address any issues on the protection of impairment informati= on. >> >> Thanks, >> Acee >> >> > From bew@cisco.com Thu Oct 27 20:56:38 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD261F0C5E; Thu, 27 Oct 2011 20:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-Sg17gMmC1X; Thu, 27 Oct 2011 20:56:38 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 64ED41F0C53; Thu, 27 Oct 2011 20:56:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=1395; q=dns/txt; s=iport; t=1319774198; x=1320983798; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=qzFBVGOo02KCqfIO0lO7P6+nh2+w5bXbrj1UTIxe5xw=; b=mKawwuQqWhkqlt0RPsmBIxYV+E8TONNumrUB++CQH1heRL7tvd12Ynul /45eb8ctgFj0jm6Pq45fyfB+DHfhNq803wqq4M8ji1x8nEY7vxQVwBrFx plTHTCIaQLZ1ppW/dIrP/LtjXT43QsYBq2nqWq8GrtoCKoYQhhPHgfV8v o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAJsnqk6rRDoJ/2dsb2JhbABCqWKBBYILASc/gT4BCSueXQGeOYgdYQSIBowHkX8 X-IronPort-AV: E=Sophos;i="4.69,416,1315180800"; d="scan'208";a="10845084" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 28 Oct 2011 03:56:38 +0000 Received: from stealth-10-32-244-212.cisco.com (stealth-10-32-244-212.cisco.com [10.32.244.212]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9S3ubWo021102; Fri, 28 Oct 2011 03:56:37 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 27 Oct 2011 20:56:37 -0700 Message-Id: <576A0CFB-CD67-4E4F-B401-1D4500A5EB2B@cisco.com> To: secdir@ietf.org, The IESG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-appsawg-rfc3462bis.all@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-appsawg-rfc3462bis-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 03:56:39 -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 re-defines the multipart/report MIME Media Type, = previously published in RFC 3462. It does not substantially change the = definition of that MIME type. The documented security considerations = identical the RFC, and considers one risk: the use of report types = without authentication, which provides DoS opportunities resulting from = any entity forging reports. The section mentions that signatures could prevent forgeries, but = signatures are outside the scope of the document. This seems like a = reasonable statement. This section might also benefit from mentioning = that entities exchanging the reports could authenticate their messages = when passed from application to application (e.g., Mail User Agent to = Mail Transfer Agent) to limit the opportunities of a man-in-the-middle = from spoofing reports on behalf of authorized applications. However, = this too would be out of scope of this document. Other than possibly adding a statement as suggested above, I see no = further changes concerns. Brian= From barryleiba.mailing.lists@gmail.com Fri Oct 28 00:06:48 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9352511E80AB for ; Fri, 28 Oct 2011 00:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.927 X-Spam-Level: X-Spam-Status: No, score=-102.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-U7LxE2Z4dm for ; Fri, 28 Oct 2011 00:06:47 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id A4DDC11E80AA for ; Fri, 28 Oct 2011 00:06:47 -0700 (PDT) Received: by gyh20 with SMTP id 20so4046843gyh.31 for ; Fri, 28 Oct 2011 00:06:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=BaWvc/LmwSSIVqG2m+vwD/vwa/8gKzgdNlJxKlqj4FU=; b=JE3S8sFWT2JGGqabD2slpuDovVhvSawcJXiaNzJalINe+RC5BeTiPwPS4KAdEM05B8 OWGlfdLWgOTPqJNaYQH2PUb0eV/SmmzGT14VNomM5b0NaTSuahjQzupKSjbf1Aj0ghDn QkJUqYZEm5gZKtIWzfVvXvIJK69jx8iyXDNTQ= MIME-Version: 1.0 Received: by 10.147.116.9 with SMTP id t9mr238568yam.5.1319785606191; Fri, 28 Oct 2011 00:06:46 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.250.14 with HTTP; Fri, 28 Oct 2011 00:06:45 -0700 (PDT) In-Reply-To: <20111027171437.F117321F8B5A@ietfa.amsl.com> References: <20111027171437.F117321F8B5A@ietfa.amsl.com> Date: Fri, 28 Oct 2011 03:06:45 -0400 X-Google-Sender-Auth: RQNuk-cEHS8tEjRLHaKMU1btqCo Message-ID: From: Barry Leiba To: secdir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [secdir] IETF 82 - Meeting and Venue Information X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 07:06:48 -0000 > =C2=A0 =C2=A0 =C2=A0 =C2=A0No food or beverages shall be brought into the= Center from > outside vendors. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0No food or beverages are allowed to be brought= into the > meeting rooms and =C2=A0working group sessions unless specifically > served by TICC Catering. These rules, if taken seriously, will cause some interference with the secdir lunch meeting. I guess Paul won't be bringing tasty =E5=8C=85=E5=AD= =90 from the local grocer this time (and thanks again, Paul, for doing it in Beijing). Will the Secretariat be catering lunch for us, then? Barry From stephen.farrell@cs.tcd.ie Fri Oct 28 01:18:34 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1184E21F8888 for ; Fri, 28 Oct 2011 01:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.266 X-Spam-Level: X-Spam-Status: No, score=-103.266 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBObTtzQOIKP for ; Fri, 28 Oct 2011 01:18:33 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 33FF421F86EC for ; Fri, 28 Oct 2011 01:18:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 4DE66171CD7; Fri, 28 Oct 2011 09:18:30 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1319789909; bh=gXKCMkkSAkccTG LX/EiQTwFv5zW0amhbgMdtKMSrdJ0=; b=5ZCI/Dg6A9dhn/R/wR6YqxtUhVN9+r a1TOOGZwrGUwTkeVP+Wq/5oO9BlRh5RlwjKKCe7kMwrCRt0v5c0tWOYvoKdz+9zC Tw6diL7B5XTXJfl1QdjyFM9pt4dA9cLdcIa3iukgO7Qi1600fvjuNCYumOA0vAP1 gz38cD3wpExLXe+n+L0rvWGKdUhrdqgYuFTCo1jwRSo9fjSqDljvrwPmXFMapqeO 1P5xTzercHMaDa1vpync3/nb2qELdoZmQBAtIZNVgjWibzrpM36XmneIaP/gfoev ftyavbxun8oCs3s4PqAvu9+rnLntFFHpVo1z31F+D0+IPhiSugv9J/KQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id Zu6KrZC36OH9; Fri, 28 Oct 2011 09:18:29 +0100 (IST) Received: from [10.87.48.10] (unknown [86.44.69.103]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 97E64171CD6; Fri, 28 Oct 2011 09:18:28 +0100 (IST) Message-ID: <4EAA6553.2060202@cs.tcd.ie> Date: Fri, 28 Oct 2011 09:18:27 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Barry Leiba References: <20111027171437.F117321F8B5A@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: secdir Subject: Re: [secdir] IETF 82 - Meeting and Venue Information X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 08:18:34 -0000 On 10/28/2011 08:06 AM, Barry Leiba wrote: >> No food or beverages shall be brought into the Center from >> outside vendors. >> >> No food or beverages are allowed to be brought into the >> meeting rooms and working group sessions unless specifically >> served by TICC Catering. > > These rules, if taken seriously, will cause some interference with the > secdir lunch meeting. Good point. Checking... S > I guess Paul won't be bringing tasty 包子 from > the local grocer this time (and thanks again, Paul, for doing it in > Beijing). > > Will the Secretariat be catering lunch for us, then? > > Barry > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From weiler+secdir@watson.org Fri Oct 28 07:04:10 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471A621F8B76 for ; Fri, 28 Oct 2011 07:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8L0YykJZZrI for ; Fri, 28 Oct 2011 07:04:09 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id A22D821F8B3C for ; Fri, 28 Oct 2011 07:04:09 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id p9SE488R065738 for ; Fri, 28 Oct 2011 10:04:08 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p9SE48x1065734 for ; Fri, 28 Oct 2011 10:04:08 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 28 Oct 2011 10:04:08 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Fri, 28 Oct 2011 10:04:08 -0400 (EDT) Subject: [secdir] Assignmets (lots of last-minute ones!) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 14:04:10 -0000 There are several docs on next week's telechat that are being assigned today for the first time. Please take a moment to look at this list ASAP. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Ondrej Sury is next in the rotation. For telechat 2011-11-03 Reviewer LC end Draft Alan DeKok T - draft-ietf-pim-port-09 Donald Eastlake T - draft-ietf-savi-framework-05 Love Hornquist-Astrand T 2011-10-31 draft-salter-rfc5430bis-01 Jeffrey Hutzelman T 2011-10-24 draft-sprecher-mpls-tp-oam-considerations-01 Tero Kivinen T - draft-ietf-avtext-client-to-mixer-audio-level-05 Warren Kumari T - draft-ietf-avtext-mixer-to-client-audio-level-05 Julien Laganier T - draft-ietf-drinks-usecases-requirements-06 Matt Lepinski T 2011-08-16 draft-ietf-ospf-auth-trailer-ospfv3-08 David McGrew T 2011-11-01 draft-ietf-fecframe-config-signaling-06 Catherine Meadows T 2011-11-03 draft-ietf-fecframe-rtp-raptor-05 Russ Mundy T 2011-10-31 draft-ietf-mip4-nemo-haaro-06 Magnus Nystrom T 2011-11-01 draft-ietf-mip4-nemov4-dynamic-05 Hilarie Orman T - draft-ietf-mmusic-ice-tcp-15 Radia Perlman T - draft-ietf-payload-rfc3189bis-03 Tim Polk T - draft-ietf-pwe3-static-pw-status-09 Eric Rescorla T 2011-11-01 draft-ietf-rmt-simple-auth-for-alc-norm-05 Joe Salowey T 2011-11-02 draft-ietf-tcpm-rfc1948bis-01 Yaron Sheffer T - draft-ietf-vcarddav-birth-death-extensions-01 Larry Zhu T 2011-10-13 draft-ietf-cuss-sip-uui-reqs-07 For telechat 2011-12-01 Reviewer LC end Draft Vincent Roca T 2011-11-09 draft-ietf-sieve-convert-05 Carl Wallace T 2011-11-07 draft-davis-t-langtag-ext-06 Last calls and special requests: Reviewer LC end Draft Phillip Hallam-Baker - draft-irtf-hiprg-dht-04 Charlie Kaufman 2011-10-25 draft-ietf-geopriv-deref-protocol-03 Scott Kelly 2011-10-25 draft-ietf-geopriv-policy-uri-02 Stephen Kent 2011-10-25 draft-ietf-kitten-sasl-openid-06 Matt Lepinski 2011-10-31 draft-ietf-6man-rpl-option-04 Chris Lonvick 2011-10-31 draft-ietf-6man-rpl-routing-header-04 Catherine Meadows R2011-04-13 draft-ietf-speechsc-mrcpv2-25 Kathleen Moriarty 2011-11-07 draft-ietf-krb-wg-gss-cb-hash-agility-08 Sandy Murphy 2011-11-10 draft-ietf-v6ops-happy-eyeballs-05 Tina TSOU 2011-04-23 draft-shin-augmented-pake-08 From mlepinski@bbn.com Fri Oct 28 22:01:49 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C4C21F84FB; Fri, 28 Oct 2011 22:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtmtPLBVXwZ1; Fri, 28 Oct 2011 22:01:48 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9437321F84F8; Fri, 28 Oct 2011 22:01:48 -0700 (PDT) Received: from [128.89.255.11] (port=1838) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RK136-000J12-4Z; Sat, 29 Oct 2011 01:01:40 -0400 Message-ID: <4EAB88B8.80800@bbn.com> Date: Sat, 29 Oct 2011 01:01:44 -0400 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: secdir@ietf.org, iesg@ietf.org, draft-ietf-ospf-auth-trailer-ospfv3.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [secdir] Secdir review of draft-ietf-ospf-auth-trailer-ospfv3-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 05:01:49 -0000 I have reviewed this document as part of the security directorate's ongoi= ng effort to review all IETF documents being processed by the IESG. These= comments were written primarily for the benefit of the security area dir= ectors. Document editors and WG chairs should treat these comments just l= ike any other last call comments. This document specifies the use of the authentication trailer for OSPFv3.= Previously this trailer was defined for use in OSPFv2, but not present i= n OSPFv3. Note that when OSPFv3 was originally specified it was anticipat= ed that IPsec would be used to provide authentication for OSPFv3. The int= roduction of draft-ietf-ospf-auth-trailer-ospfv3 explains the limitations= of IPsec that necessitate specifying the authentication trailer for OSPF= v3. (However, I personally don't find the explanation in the introduction= to be fully convincing, see below.) --------------- Comments --------------- A) Section 1.1 describes the work in the IPSECME working group to address= the shortcomings of ESP-NULL as an authentication mechanism. However, it= is not clear to me why this work in IPSECME (RFCs 5879 and 5840) is insu= fficient to resolve the issues (described in Section 1) that make ESP-NUL= L unsuitable for use as an authentication OSPFv3. That is, Section 1.1 de= scribes what the IPSECME working group has done to solve the ESP-NULL iss= ues in IPsec, but Section 1.1 doesn't answer the question of why in light= of the recent IPSECME work that this specification is still needed? Note: I assume the answer to the question in the previous paragraph is th= at the authors of this specification feel that RFC 5879 is insufficient and that RFC 5840 will take too long to get deployed, and th= is might be a good justification for the current specification. Additionally, since this document, is a new standards track extension to = OSPFv3, I would like to see an explicit justification for why the protocol described in this document will see deployment sooner than RFC 5= 840 (which solves the same problem that is solved by the OSPFv3 authentic= ation trailer). There is also a statement in Section 1 that IPsec is not = available on some platforms or environments, but the authors to do go int= o enough detail (or provide suitable references) for me to evaluate wheth= er this claim justifies creating another standards track mechanism for so= lving authentication in OSPFv3. This document should site RFC 5879 (Heuristics for detecting ESP-NULL) in= Section 1.1 of the Introduction. B) In order to prevent cross-protocol replay attacks, this document creat= es a general IANA registry for cryptographic protocols (both native IPv4/= IPv6 protocols and UDP/TCP protocols). The registry is created with only = a single entry, but the text describing the registry is sufficiently broa= d as to suggest that all protocols that use cryptographic keys should be = registered. (My apologies if I am misinterpreting the IANA considerations= text in Section 7 ... it is also possible that only a subset of cryptogr= aphic protocols need to be registered, but it is not clear to me from the= text what subset this would be.) My understanding is that cross-protocol= replay attacks are prevented by appending the registered protocol ID to = the private key to obtain a subordinate key for use in the Message Authen= tication Code. However, I am not convinced that this is a good general-pu= rpose approach for preventing cross-protocol replay attacks. (Perhaps the= document could instead contain language that the private key for OSPFv3 = authentication trailers MUST NOT be used in other protocol.) If creating = such a general registry is a good approach to dealing with cross-protocol= replay attacks, then I question whether this document is the right place= to define such a registry. Such a registry seems much more likely to be = successful if the community in the Security Area is involved in specifyin= g the registry and populating it with an appropriate set of initial value= s. C) The first paragraph of the Security Considerations for this document c= laim that the authentication trailer represents an increase in the securi= ty of OSPFv3. In the introduction of the document the authors cite RFC 60= 39 which identifies security issues with OSPFv3 (and other routing protoc= ols). It would be helpful if the authors could indicate in the security c= onsiderations section to what extend (if any) the authentication trailer = addresses the issues raised in RFC 6039 (and, similarly, to what extend t= he authentication trailer is providing increased security for OSPFv3). The introduction cites RFC4552 for an explanation of why manual keying is= used. This reference should be repeated in the Security considerations s= ection. (I would even advocate copying the text from the Security Conside= rations of RFC 4552 that deals with the limitations of manual keying.) Ad= ditionally, RFC 4552 explicitly states that replay protection is not prov= ided in OSPFv3. Text from RFC 4552 is included in the Introduction, which= states that the use of manual keying limits the extent to which replay p= rotection can be achieved. This authentication header specification attem= pts to provide a degree of replay protection. It would be nice if the sec= urity considerations section described in some detail the extent to which= this specification prevents replays. D) This document states (in Section 4.3) that the OSPFv3 authentication t= railer supports the following four authentication algorithms: HMAC-SHA-1,= HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512. However, in Section 3, it d= oes not include references to a document where these authentication algorithms are defined. (I believe the right documents to = reference are RFC 2104 and RFC 4868.) Additionally, for interoperability I would suggest that the authors specify at least one of= these algorithms are mandatory to implement. (The goal is to avoid a situation where an operator seeking to use OSPFv3 authentication traile= r has two OSPFv3-speaking devices from different vendors, one which only supports HMAC-SHA-1 and the other only supports HMAC-SHA-256).= Note: Upon further reading of the document, it's not clear to me whether= this specification works with symmetric-key authentication algorithms ot= her than HMAC. If it is the case that the authentication trailer only wor= ks with HMAC, then the document should instead clearly state that authent= ication trailer makes use of HMAC and currently supports the four digest = algorithms. The Security Considerations for this document (Section 6) RECOMMEND that = the deployments use a pseudo-random key of at least 128-bits. This strike= s me as odd, because I believe that RFC 2104 which specifies HMAC recomme= nds that the key be at least as long as the output size of the hash funct= ion (160 bits in the case of SHA-1). E) This document creates a registry of Authentication Trailer types and p= opulates it with one value "Cryptographic Authentication". First, I believe that the Cryptographic Authentication that it is referring to is = the mechanism described in this document, but this is not stated clearly in Section 7. Also, having a specification pointer in the registr= y would be very helpful. Second, having the name "Cryptographic Authentication" for the first value in the registry seems to suggest that= there might be a future type of authentication which is "Not Cryptographic" (which seems like a bad idea to me). I would suggest that = the authors change the name of the first value in the registry to something a bit more specific. Finally, it is not clear to me that this r= egistry needs to exist. The existence of the type field in the authentication trailer is not justified within this document. My belief i= s that the only reason that a type field is included is for backwards compatibility with OSPFv2. From manav.bhatia@alcatel-lucent.com Sat Oct 29 02:25:05 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D2D21F877F; Sat, 29 Oct 2011 02:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.942 X-Spam-Level: X-Spam-Status: No, score=-6.942 tagged_above=-999 required=5 tests=[AWL=-0.343, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id poLbVcU9PKte; Sat, 29 Oct 2011 02:25:04 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id AD3ED21F867F; Sat, 29 Oct 2011 02:25:04 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p9T9OmNP022676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 29 Oct 2011 04:24:51 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p9T9OkCA026660 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 29 Oct 2011 14:54:47 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Sat, 29 Oct 2011 14:54:46 +0530 From: "Bhatia, Manav (Manav)" To: Matt Lepinski , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-ospf-auth-trailer-ospfv3.all@tools.ietf.org" Date: Sat, 29 Oct 2011 14:54:55 +0530 Thread-Topic: Secdir review of draft-ietf-ospf-auth-trailer-ospfv3-08 Thread-Index: AcyV9/CtXLzh8cclT5uVrkCpV5mv7QAFOaeg Message-ID: <7C362EEF9C7896468B36C9B79200D8350D00FD4E02@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <4EAB88B8.80800@bbn.com> In-Reply-To: <4EAB88B8.80800@bbn.com> 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-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Mailman-Approved-At: Sat, 29 Oct 2011 05:29:40 -0700 Cc: Sam Hartman Subject: Re: [secdir] Secdir review of draft-ietf-ospf-auth-trailer-ospfv3-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 09:25:05 -0000 Hi Matt, Really appreciate the detailed review. > A) Section 1.1 describes the work in the IPSECME working=20 > group to address the shortcomings of ESP-NULL as an=20 > authentication mechanism. However, it is not clear to me why=20 > this work in IPSECME (RFCs 5879 and 5840) is insufficient to=20 > resolve the issues (described in Section 1) that make=20 > ESP-NULL unsuitable for use as an authentication OSPFv3. That=20 > is, Section 1.1 describes what the IPSECME working group has=20 > done to solve the ESP-NULL issues in IPsec, but Section 1.1=20 > doesn't answer the question of why in light of the recent=20 > IPSECME work that this specification is still needed? I am the co-author of RFC 5840 (WESP) and while it can be used to solve som= e issues that exist when using vanilla Ipsec, there will still be some issu= es that it will not address. IPsec works best in the point-to-point topolog= ies and becomes increasingly complex to provision and unscalable when there= are multiple routers in a broadcast domain and you need a full mesh of con= nectivity among all the routers. Providers will tell you that it is a night= mare managing and maintaining a full mesh of Ipsec tunnels and it just does= n't work. Then there are licensing issues with Ipsec (which will exist with= WESP as well) and its not available on all platforms - the operators were = thus not able to secure OSPFv3. We had included this point in this draft bu= t had removed it since an IETF document shouldn't be discussing licensing a= nd financial issues. So there is enough support for adding an in-band security mechanism within = OSPFv3. >=20 > Note: I assume the answer to the question in the previous=20 > paragraph is that the authors of this specification feel that=20 > RFC 5879 is insufficient and that RFC 5840 will take too long=20 > to get deployed, and this might be a good justification for=20 > the current specification. > Additionally, since this document, is a new standards track=20 > extension to OSPFv3, I would like to see an explicit=20 > justification for why the protocol described in this document=20 > will see deployment sooner than RFC 5840 (which solves the=20 > same problem that is solved by the OSPFv3 authentication=20 > trailer). There is also a statement in Section 1 that IPsec=20 > is not available on some platforms or environments, but the=20 > authors to do go into enough detail (or provide suitable=20 > references) for me to evaluate whether this claim justifies=20 > creating another standards track mechanism for solving=20 > authentication in OSPFv3. You can google for product specs from the vendors and verify that not all p= latforms support Ipsec. We cant add references to their websites in an IETF= doc.=20 Moreover, even if you disregard the financial and political aspects of usin= g Ipsec, there are technical reasons as explained above which require an al= ternate mechanism to be explored. >=20 > This document should site RFC 5879 (Heuristics for detecting=20 > ESP-NULL) in Section 1.1 of the Introduction. I could be missing something, but I really find no references to work done = in IPSECME and WESP (rfc 5840). Are you sure you're looking at the -08 vers= ion? >=20 > B) In order to prevent cross-protocol replay attacks, this=20 > document creates a general IANA registry for cryptographic=20 > protocols (both native IPv4/IPv6 protocols and UDP/TCP=20 > protocols). The registry is created with only a single entry,=20 > but the text describing the registry is sufficiently broad as=20 > to suggest that all protocols that use cryptographic keys=20 > should be registered. (My apologies if I am misinterpreting=20 > the IANA considerations text in Section 7 ... it is also=20 > possible that only a subset of cryptographic protocols need=20 > to be registered, but it is not clear to me from the text=20 > what subset this would be.) My understanding is that=20 > cross-protocol replay attacks are prevented by appending the=20 > registered protocol ID to the private key to obtain a=20 > subordinate key for use in the Message Authentication Code.=20 > However, I am not convinced that this is a good=20 > general-purpose approach for preventing cross-protocol replay=20 > attacks. (Perhaps the document could instead contain language=20 > that the private key for OSPFv3 authentication trailers MUST=20 > NOT be used in other protocol.) If creating such a general=20 > registry is a good approach to dealing with cross-protocol=20 > replay attacks, then I question whether this document is the=20 > right place to define such a registry. Such a registry seems=20 > much more likely to be successful if the community in the=20 > Security Area is involved in specifying the registry and=20 > populating it with an appropriate set of initial values. The original draft did not consider cross-protocol replay attacks and this = section was only added after a long, protracted discussion with Sam Hartman= and Stephen Farell. It was only after they were satisfied with the provisi= ons for cross protocol replay attacks that we progressed this draft.=20 Ccing Sam, though he should be in the secdir list. >=20 > C) The first paragraph of the Security Considerations for=20 > this document claim that the authentication trailer=20 > represents an increase in the security of OSPFv3. In the=20 > introduction of the document the authors cite RFC 6039 which=20 > identifies security issues with OSPFv3 (and other routing=20 > protocols). It would be helpful if the authors could indicate=20 > in the security considerations section to what extend (if=20 > any) the authentication trailer addresses the issues raised=20 > in RFC 6039 (and, similarly, to what extend the=20 > authentication trailer is providing increased security for OSPFv3). RFC 6039 cities the lack of replay protection in OSPFv3 as the reason for m= ost attacks on OSPFv3. This draft adds support for replay protection and th= us addresses all the issues raised in 6039. >=20 > The introduction cites RFC4552 for an explanation of why=20 > manual keying is used. This reference should be repeated in=20 > the Security considerations section. (I would even advocate=20 > copying the text from the Security Considerations of RFC 4552=20 > that deals with the limitations of manual keying.)=20 > Additionally, RFC 4552 explicitly states that replay=20 > protection is not provided in OSPFv3. Text from RFC 4552 is=20 > included in the Introduction, which states that the use of=20 > manual keying limits the extent to which replay protection=20 > can be achieved. This authentication header specification=20 > attempts to provide a degree of replay protection. It would=20 > be nice if the security considerations section described in=20 > some detail the extent to which this specification prevents replays. Text from 4522 is not relevant here in this document. 4552 describes how Ip= sec can be used to protect OSPFv3. This document describes a mechanism to p= rotect OSPFv3 without Ipsec. >=20 > D) This document states (in Section 4.3) that the OSPFv3=20 > authentication trailer supports the following four=20 > authentication algorithms: HMAC-SHA-1, HMAC-SHA-256,=20 > HMAC-SHA-384, and HMAC-SHA-512. However, in Section 3, it=20 > does not include references to a document where these=20 > authentication algorithms are defined. (I believe the right=20 > documents to reference are RFC 2104 and RFC 4868.)=20 We have provided references to the following documents: [FIPS-180-3] US National Institute of Standards & Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-3 , October 2008. [FIPS-198] US National Institute of Standards & Technology, "The Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 198 , March 2002. Isnt this enough? > Additionally, for interoperability I would suggest that the=20 > authors specify at least one of these algorithms are=20 > mandatory to implement. (The goal is to avoid a situation=20 > where an operator seeking to use OSPFv3 authentication=20 > trailer has two OSPFv3-speaking devices from different=20 > vendors, one which only supports HMAC-SHA-1 and the other=20 > only supports HMAC-SHA-256). Note: Upon further reading of=20 > the document, it's not clear to me whether this specification=20 > works with symmetric-key authentication algorithms other than=20 > HMAC. If it is the case that the authentication trailer only=20 > works with HMAC, then the document should instead clearly=20 > state that authentication trailer makes use of HMAC and=20 > currently supports the four digest algorithms. I agree.=20 >=20 > The Security Considerations for this document (Section 6)=20 > RECOMMEND that the deployments use a pseudo-random key of at=20 > least 128-bits. This strikes me as odd, because I believe=20 > that RFC 2104 which specifies HMAC recommends that the key be=20 > at least as long as the output size of the hash function (160=20 > bits in the case of SHA-1). The input key does not necessarily need to be that long. Please look at Sec= 4.5 for more details. The key that's fed to HMAC can be 160 bits even if t= he input key is of a smaller size. We are recommending that the input key s= hould be at least 128 bits long.=20 HMAC requires a 160 bit key as the seed. However, for convenience to the ad= ministrators, a specification may not want to require the entry of a PSK of= exactly 20 bytes. Instead, a specification may call for a key preparation = routine that could handle a variable length PSK, one that might be less or = more than 20 bytes (see [RFC4615], section 3, as an example). That key prep= routine would derive a key of exactly the required length and thus suitabl= e as a seed to the PRF. This does NOT mean that administrators are safe to = use weak keys. Administrators are encouraged to follow [RFC4086] [NIST-800-= 118]. We are simply trying to play it safe by recommending that administrat= ors should put a password that is at least 16 bytes in length.=20 Actually, now that I think about this, specifying a key size of 16 bytes is= also not practical. We could either delete that sentence or reduce the len= gth of the recommended key size. I cant image all admins typing in a 16 byt= e password! > E) This document creates a registry of Authentication Trailer=20 > types and populates it with one value "Cryptographic=20 > Authentication". First, I believe that the Cryptographic=20 > Authentication that it is referring to is the mechanism=20 > described in this document, but this is not stated clearly in=20 > Section 7. Also, having a specification pointer in the=20 Agree. This should be done. > registry would be very helpful. Second, having the name=20 > "Cryptographic Authentication" for the first value in the=20 > registry seems to suggest that there might be a future type=20 > of authentication which is "Not Cryptographic" (which seems=20 > like a bad idea to me). I would suggest that the authors=20 > change the name of the first value in the registry to=20 > something a bit more specific. Finally, it is not clear to me=20 Any suggestions here? > that this registry needs to exist. The existence of the type=20 > field in the authentication trailer is not justified within=20 > this document. My belief is that the only reason that a type=20 > field is included is for backwards compatibility with OSPFv2. Yes, this is correct. Cheers, Manav= From hartmans@mit.edu Sat Oct 29 12:42:17 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B0E21F869E; Sat, 29 Oct 2011 12:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.972 X-Spam-Level: X-Spam-Status: No, score=-102.972 tagged_above=-999 required=5 tests=[AWL=-0.707, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jclCansO5+Sm; Sat, 29 Oct 2011 12:42:16 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id B2CB521F8696; Sat, 29 Oct 2011 12:42:16 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id E660020177; Sat, 29 Oct 2011 15:43:14 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F3092435A; Sat, 29 Oct 2011 15:42:11 -0400 (EDT) From: Sam Hartman To: "Bhatia\, Manav \(Manav\)" References: <4EAB88B8.80800@bbn.com> <7C362EEF9C7896468B36C9B79200D8350D00FD4E02@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Sat, 29 Oct 2011 15:42:11 -0400 In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D00FD4E02@INBANSXCHMBSA1.in.alcatel-lucent.com> (Manav Bhatia's message of "Sat, 29 Oct 2011 14:54:55 +0530") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "draft-ietf-ospf-auth-trailer-ospfv3.all@tools.ietf.org" , Sam Hartman , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ospf-auth-trailer-ospfv3-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 19:42:17 -0000 Hi. The rationale behind the IANA registry is to avoid related protocol attacks. The intent is to have a registry for protocols (there are a number in the routing area) that use similar layouts for authentication information to avoid related protocol attacks when the same key is used cross-protocol.el :So, anything sufficiently similar to this needs to be registered. I think the registry is the result of a fairly tight compromise already and I would not recommend re-opening that discussion. I'd be delighted if you want to propose better names for the registry or the initial registration; I suspect we're not tied to those. I do not support removing the key-strength indication. Realistically I think this application probably does require at least 64-bits of security (assuming there are no hash collision issues, which would double the security requirement). I don't actively support reducing the key strength requirement below 128-bits, but I'm not opposed if someone really wants to do that. Note that a 16-character password does not meet the current requirement: passwords are typically not random drown from the set of all binary values of a given size. From stephen.farrell@cs.tcd.ie Sat Oct 29 14:48:28 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F2921F862F; Sat, 29 Oct 2011 14:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0zHpeE7q8pI; Sat, 29 Oct 2011 14:48:27 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id A950F21F85FF; Sat, 29 Oct 2011 14:48:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 1FE4915358F; Sat, 29 Oct 2011 22:48:26 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h=date :subject:from:x-mailer:message-id:content-type :content-transfer-encoding:mime-version:in-reply-to:references :received:received:x-virus-scanned; s=cs; t=1319924905; bh=uzWFR cHyYYzjqeF9x8ire98uQEecipF9YS11NlhINZE=; b=ofvVJ4oxznuVJvWd1Us7v meoH6XPMhdKfpXuFCnGgtRhTMPWdCT5XnzMUh/BEPATEbp0u2r2L0bJt8frPk+yN qXKbnycXI8zXOeIFB6z3Hb4o0KhU6ellO8aFMwj46ET7ovx55KHN9DEF20trBvxY rrB03JNxUVYMcH44ohEDkw6LdnyuwgUBQ3P1wbmEqHLxy3Q8gJovUyne6x7iiqtg 9ViaT7oXmHu9cx5E/W2FNTCK4iuDdSouytU4q0pdJJ80t3oFurGq3O0y9kjyN2Lf k9JYhc0rev9jJcdsLZltBqyYwSTwxEFdPxeqfH9EJUW7+2zmawyStYoRFpSyDVWx A== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id yD1R9re4NfTQ; Sat, 29 Oct 2011 22:48:25 +0100 (IST) Received: from [10.87.48.5] (unknown [86.41.5.169]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 2115015358E; Sat, 29 Oct 2011 22:48:19 +0100 (IST) References: <4EAB88B8.80800@bbn.com> <7C362EEF9C7896468B36C9B79200D8350D00FD4E02@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: <68A26CD8-134D-4B39-B812-2D286582F35F@cs.tcd.ie> X-Mailer: iPhone Mail (9A334) From: Stephen Farrell Date: Sat, 29 Oct 2011 22:48:17 +0100 To: Sam Hartman Cc: "Bhatia, Manav \(Manav\)" , "secdir@ietf.org" , "iesg@ietf.org" , Sam Hartman , "draft-ietf-ospf-auth-trailer-ospfv3.all@tools.ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ospf-auth-trailer-ospfv3-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 21:48:28 -0000 +1 to what Sam said, S On 29 Oct 2011, at 20:42, Sam Hartman wrote: > Hi. The rationale behind the IANA registry is to avoid related protocol > attacks. The intent is to have a registry for protocols (there are a > number in the routing area) that use similar layouts for authentication > information to avoid related protocol attacks when the same key is used > cross-protocol.el :So, anything sufficiently similar to this needs to be > registered. I think the registry is the result of a fairly tight > compromise already and I would not recommend re-opening that discussion. > I'd be delighted if you want to propose better names for the registry or > the initial registration; I suspect we're not tied to those. > > I do not support removing the key-strength indication. Realistically I > think this application probably does require at least 64-bits of > security (assuming there are no hash collision issues, which would > double the security requirement). I don't actively support reducing the > key strength requirement below 128-bits, but I'm not opposed if someone > really wants to do that. Note that a 16-character password does not meet > the current requirement: passwords are typically not random drown from > the set of all binary values of a given size. From mlepinski@bbn.com Sat Oct 29 16:50:01 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB5321F8481; Sat, 29 Oct 2011 16:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 721KWY9Ag9+4; Sat, 29 Oct 2011 16:50:00 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id CC9FD21F8480; Sat, 29 Oct 2011 16:49:59 -0700 (PDT) Received: from [128.89.255.9] (port=1273) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RKIez-0004hB-7N; Sat, 29 Oct 2011 19:49:57 -0400 Message-ID: <4EAC912F.5050509@bbn.com> Date: Sat, 29 Oct 2011 19:50:07 -0400 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" References: <4EAB88B8.80800@bbn.com> <7C362EEF9C7896468B36C9B79200D8350D00FD4E02@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D00FD4E02@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sam Hartman , "iesg@ietf.org" , "draft-ietf-ospf-auth-trailer-ospfv3.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ospf-auth-trailer-ospfv3-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 23:50:01 -0000 Manav, I apologize for the confusion regarding the WESP (IPSECME) work, I had printed out two versions of your document (one somewhat old) and I got confused with regards to the relationship with the IPSECME ESP-NULL work. Further comments in-line: On 10/29/2011 5:24 AM, Bhatia, Manav (Manav) wrote: > Hi Matt, > > Really appreciate the detailed review. > >> A) Section 1.1 describes the work in the IPSECME working >> group to address the shortcomings of ESP-NULL as an >> authentication mechanism. However, it is not clear to me why >> this work in IPSECME (RFCs 5879 and 5840) is insufficient to >> resolve the issues (described in Section 1) that make >> ESP-NULL unsuitable for use as an authentication OSPFv3. That >> is, Section 1.1 describes what the IPSECME working group has >> done to solve the ESP-NULL issues in IPsec, but Section 1.1 >> doesn't answer the question of why in light of the recent >> IPSECME work that this specification is still needed? > I am the co-author of RFC 5840 (WESP) and while it can be used to solve some issues that exist when using vanilla Ipsec, there will still be some issues that it will not address. IPsec works best in the point-to-point topologies and becomes increasingly complex to provision and unscalable when there are multiple routers in a broadcast domain and you need a full mesh of connectivity among all the routers. Providers will tell you that it is a nightmare managing and maintaining a full mesh of Ipsec tunnels and it just doesn't work. Then there are licensing issues with Ipsec (which will exist with WESP as well) and its not available on all platforms - the operators were thus not able to secure OSPFv3. We had included this point in this draft but had removed it since an IETF document shouldn't be discussing licensing and financial issues. > > So there is enough support for adding an in-band security mechanism within OSPFv3. Okay, that makes sense. >> B) In order to prevent cross-protocol replay attacks, this >> document creates a general IANA registry for cryptographic >> protocols (both native IPv4/IPv6 protocols and UDP/TCP >> protocols). The registry is created with only a single entry, >> but the text describing the registry is sufficiently broad as >> to suggest that all protocols that use cryptographic keys >> should be registered. (My apologies if I am misinterpreting >> the IANA considerations text in Section 7 ... it is also >> possible that only a subset of cryptographic protocols need >> to be registered, but it is not clear to me from the text >> what subset this would be.) My understanding is that >> cross-protocol replay attacks are prevented by appending the >> registered protocol ID to the private key to obtain a >> subordinate key for use in the Message Authentication Code. >> However, I am not convinced that this is a good >> general-purpose approach for preventing cross-protocol replay >> attacks. (Perhaps the document could instead contain language >> that the private key for OSPFv3 authentication trailers MUST >> NOT be used in other protocol.) If creating such a general >> registry is a good approach to dealing with cross-protocol >> replay attacks, then I question whether this document is the >> right place to define such a registry. Such a registry seems >> much more likely to be successful if the community in the >> Security Area is involved in specifying the registry and >> populating it with an appropriate set of initial values. > The original draft did not consider cross-protocol replay attacks and this section was only added after a long, protracted discussion with Sam Hartman and Stephen Farell. It was only after they were satisfied with the provisions for cross protocol replay attacks that we progressed this draft. > > Ccing Sam, though he should be in the secdir list. I have trouble seeing how the cryptographic protocol ID registry is going to work going forward (in particular, what type of protocols should be placed in this registry). However, if Stephen Farell and Sam Hartman are satisfied with the text describing the cryptographic protocol ID registry, then I defer to them in this matter. >> C) The first paragraph of the Security Considerations for >> this document claim that the authentication trailer >> represents an increase in the security of OSPFv3. In the >> introduction of the document the authors cite RFC 6039 which >> identifies security issues with OSPFv3 (and other routing >> protocols). It would be helpful if the authors could indicate >> in the security considerations section to what extend (if >> any) the authentication trailer addresses the issues raised >> in RFC 6039 (and, similarly, to what extend the >> authentication trailer is providing increased security for OSPFv3). > RFC 6039 cities the lack of replay protection in OSPFv3 as the reason for most attacks on OSPFv3. This draft adds support for replay protection and thus addresses all the issues raised in 6039. I would very much like to see this statement appear in the Security Considerations section. >> The introduction cites RFC4552 for an explanation of why >> manual keying is used. This reference should be repeated in >> the Security considerations section. (I would even advocate >> copying the text from the Security Considerations of RFC 4552 >> that deals with the limitations of manual keying.) >> Additionally, RFC 4552 explicitly states that replay >> protection is not provided in OSPFv3. Text from RFC 4552 is >> included in the Introduction, which states that the use of >> manual keying limits the extent to which replay protection >> can be achieved. This authentication header specification >> attempts to provide a degree of replay protection. It would >> be nice if the security considerations section described in >> some detail the extent to which this specification prevents replays. > Text from 4522 is not relevant here in this document. 4552 describes how Ipsec can be used to protect OSPFv3. This document describes a mechanism to protect OSPFv3 without Ipsec. > Okay, what I found confusing is that you provide text from 4522 verbatim in the Introduction, but it is not clear to me how this text relates to the authentication trailer defined in the current document. It would make things more clear to me if you were to either remove the text from 4522 or else provide a bit more context. (For example, you might say, that explicitly that a goal of the authentication trailer document is to provide replay protection which is not possible to provide with IPsec when manual keying is used.) >> D) This document states (in Section 4.3) that the OSPFv3 >> authentication trailer supports the following four >> authentication algorithms: HMAC-SHA-1, HMAC-SHA-256, >> HMAC-SHA-384, and HMAC-SHA-512. However, in Section 3, it >> does not include references to a document where these >> authentication algorithms are defined. (I believe the right >> documents to reference are RFC 2104 and RFC 4868.) > We have provided references to the following documents: > > [FIPS-180-3] > US National Institute of Standards& Technology, "Secure > Hash Standard (SHS)", FIPS PUB 180-3 , October 2008. > > [FIPS-198] > US National Institute of Standards& Technology, "The > Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB > 198 , March 2002. > > Isnt this enough? I would find it very helpful if you put references to these citations in Section 4.3 where you list the cryptographic authentication algorithms supported by the OSPFv3 authentication trailer. >> Additionally, for interoperability I would suggest that the >> authors specify at least one of these algorithms are >> mandatory to implement. (The goal is to avoid a situation >> where an operator seeking to use OSPFv3 authentication >> trailer has two OSPFv3-speaking devices from different >> vendors, one which only supports HMAC-SHA-1 and the other >> only supports HMAC-SHA-256). Note: Upon further reading of >> the document, it's not clear to me whether this specification >> works with symmetric-key authentication algorithms other than >> HMAC. If it is the case that the authentication trailer only >> works with HMAC, then the document should instead clearly >> state that authentication trailer makes use of HMAC and >> currently supports the four digest algorithms. > I agree. > >> The Security Considerations for this document (Section 6) >> RECOMMEND that the deployments use a pseudo-random key of at >> least 128-bits. This strikes me as odd, because I believe >> that RFC 2104 which specifies HMAC recommends that the key be >> at least as long as the output size of the hash function (160 >> bits in the case of SHA-1). > The input key does not necessarily need to be that long. Please look at Sec 4.5 for more details. The key that's fed to HMAC can be 160 bits even if the input key is of a smaller size. We are recommending that the input key should be at least 128 bits long. > > HMAC requires a 160 bit key as the seed. However, for convenience to the administrators, a specification may not want to require the entry of a PSK of exactly 20 bytes. Instead, a specification may call for a key preparation routine that could handle a variable length PSK, one that might be less or more than 20 bytes (see [RFC4615], section 3, as an example). That key prep routine would derive a key of exactly the required length and thus suitable as a seed to the PRF. This does NOT mean that administrators are safe to use weak keys. Administrators are encouraged to follow [RFC4086] [NIST-800-118]. We are simply trying to play it safe by recommending that administrators should put a password that is at least 16 bytes in length. > > Actually, now that I think about this, specifying a key size of 16 bytes is also not practical. We could either delete that sentence or reduce the length of the recommended key size. I cant image all admins typing in a 16 byte password! Okay, what you just said makes more sense to me than what is currently in the Security Considerations section. Personally (and this is just me) I would recommend not having an explicit key size recommendation in the security considerations and instead just keep the sentence "Deployments SHOULD use sufficiently long and random values for the authentication key so that guessing and other cryptographic attacks on the key are not feasible in their environments." and reference RFC 4086. >> E) This document creates a registry of Authentication Trailer >> types and populates it with one value "Cryptographic >> Authentication". First, I believe that the Cryptographic >> Authentication that it is referring to is the mechanism >> described in this document, but this is not stated clearly in >> Section 7. Also, having a specification pointer in the > Agree. This should be done. > >> registry would be very helpful. Second, having the name >> "Cryptographic Authentication" for the first value in the >> registry seems to suggest that there might be a future type >> of authentication which is "Not Cryptographic" (which seems >> like a bad idea to me). I would suggest that the authors >> change the name of the first value in the registry to >> something a bit more specific. Finally, it is not clear to me > Any suggestions here? Hmm ... I'm not sure ... If you insert a specification pointer into the registry so that an implementer looking at the registry can clearly see that "cryptographic registration" is the mechanism in RFC XYZ (whatever number this draft becomes). >> that this registry needs to exist. The existence of the type >> field in the authentication trailer is not justified within >> this document. My belief is that the only reason that a type >> field is included is for backwards compatibility with OSPFv2. > Yes, this is correct. > From charliek@microsoft.com Sat Oct 29 20:44:39 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC5F21F848F; Sat, 29 Oct 2011 20:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pLbVAk5P62Q; Sat, 29 Oct 2011 20:44:39 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 0347F21F8468; Sat, 29 Oct 2011 20:44:39 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sat, 29 Oct 2011 20:44:38 -0700 Received: from TK5EX14MBXC110.redmond.corp.microsoft.com ([169.254.1.89]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.01.0339.002; Sat, 29 Oct 2011 20:44:38 -0700 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-geopriv-deref-protocol.all@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-geopriv-deref-protocol-03 Thread-Index: AcyWtH7xvsetFgKuTCGqY+7jCENKOw== Date: Sun, 30 Oct 2011 03:44:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] Secdir review of draft-ietf-geopriv-deref-protocol-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 03:44:39 -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.=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. This document specifies a protocol over http (and optionally over TLS) for = dereferencing a Presence Information Data Format Location Object. This data= is sensitive and there is likely to be an authorization policy saying who = can get it. This spec is careful to enumerate the various ways that authori= zation decision might be made without specifying how one would specify any = particular policy. I believe it therefore manages to evade any security scr= utiny. (Use of TLS is recommended and is an appropriate way to secure the p= rotocol itself). I found one typo: page 11: specfies -> specifies --Charlie From scott@hyperthought.com Sun Oct 30 06:41:05 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F44D21F8B1C for ; Sun, 30 Oct 2011 06:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gXrvw09Ytl0 for ; Sun, 30 Oct 2011 06:41:04 -0700 (PDT) Received: from smtp202.dfw.emailsrvr.com (smtp202.dfw.emailsrvr.com [67.192.241.202]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8DD21F8B18 for ; Sun, 30 Oct 2011 06:41:04 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp10.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 684E11B823A; Sun, 30 Oct 2011 09:41:03 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp10.relay.dfw1a.emailsrvr.com (Authenticated sender: scott-AT-hyperthought.com) with ESMTPSA id E0E031B8211; Sun, 30 Oct 2011 09:41:02 -0400 (EDT) Message-ID: <4EAD53ED.60802@hyperthought.com> Date: Sun, 30 Oct 2011 06:41:01 -0700 From: "Scott G. Kelly" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-geopriv-policy-uri.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] draft-ietf-geopriv-policy-uri-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 13:41:05 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This review is a little late -- sorry for the delay. From the abstract, "This document extends the current location configuration protocols to provide hosts with a reference to the rules that are applied to a URI, so that the host can view or set these rules." Specifically, it allows the host to view, set, or change privacy rules associated with its location URIs. The document is well-written, and contains a security considerations section that addresses associated protocol threats. That section references two "classes of risks": risk of unauthorized disclosure of the protected resource, and risk of disclosure of the policy information itself. Why isn't unauthorized manipulation of the policy information also listed as a risk? Actually, the second paragraph of the security considerations addresses this, ("The mechanism also needs to ensure that only authorized entities are able to acquire or alter policy."), but subsequent text seems to indicate that if the policy URI is not kept secret, there are no further protections. Am I missing something here, or is secrecy of the URI really the only protection against unauthorized policy manipulation? I have to admit that I have no experience with these protocols, and it may be that this is addressed elsewhere (or truly doesn't matter), but it does feel a bit off. --Scott From rbarnes@bbn.com Sun Oct 30 13:19:44 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E694721F867F; Sun, 30 Oct 2011 13:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D21xJY-2Igxm; Sun, 30 Oct 2011 13:19:44 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 51B3221F85AE; Sun, 30 Oct 2011 13:19:44 -0700 (PDT) Received: from [128.89.254.112] (port=52600) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RKbr4-0007Om-SY; Sun, 30 Oct 2011 16:19:43 -0400 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Richard Barnes In-Reply-To: <4EAD53ED.60802@hyperthought.com> Date: Sun, 30 Oct 2011 21:19:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EAD53ED.60802@hyperthought.com> To: Scott G. Kelly X-Mailer: Apple Mail (2.1251.1) Cc: draft-ietf-geopriv-policy-uri.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] draft-ietf-geopriv-policy-uri-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 20:19:45 -0000 Hi Scott, Thanks for the review. Couple of comments inline. > 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 review is a little late -- sorry for the delay. =46rom the = abstract, "This document extends the current location configuration = protocols to provide hosts with a reference to the rules that are = applied to a URI, so that the host can view or set these rules." = Specifically, it allows the host to view, set, or change privacy rules = associated with its location URIs. >=20 > The document is well-written, and contains a security considerations = section that addresses associated protocol threats. That section = references two "classes of risks": risk of unauthorized disclosure of = the protected resource, and risk of disclosure of the policy information = itself. >=20 > Why isn't unauthorized manipulation of the policy information also = listed as a risk? Actually, the second paragraph of the security = considerations addresses this, ("The mechanism also needs to ensure that = only authorized entities are able to acquire or alter policy."), but = subsequent text seems to indicate that if the policy URI is not kept = secret, there are no further protections. Since we're talking about access control policy here, the effect of = "manipulation of the policy information" is precisely "unauthorized = disclosure of the protected resource". Does that clear thing sup? > Am I missing something here, or is secrecy of the URI really the only = protection against unauthorized policy manipulation? I have to admit = that I have no experience with these protocols, and it may be that this = is addressed elsewhere (or truly doesn't matter), but it does feel a bit = off. You're exactly right in that understanding. The idea is that a policy = URI is already controlling access control policy on something, so we = didn't want to have access control policies for who can access policy = URIs (turtles all the way down). That's the reason for all the text = about keeping the policy URI secret. Thanks for the review, --Richard From yaronf.ietf@gmail.com Mon Oct 31 04:46:31 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E94821F8BB9; Mon, 31 Oct 2011 04:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpP9nKju5wAq; Mon, 31 Oct 2011 04:46:31 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id A402921F8BA8; Mon, 31 Oct 2011 04:46:30 -0700 (PDT) Received: by faas12 with SMTP id s12so6409417faa.31 for ; Mon, 31 Oct 2011 04:46:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=wD6YK5UdzWqHgHc/RfPUn8dKIWT6fbNaBrRqu+wmHFA=; b=nC9zY5yl+8/DYP9O9s32182MSvisaGNPx0tUoETcHt37aPq1c4/WxQG0WSSODypaNu QPAuOQxyrDw469Gv3rxAjWghrTlleXmqIocg811fXGdYehMJqYH96v1njosGrG4F1xae KESjVEm8/ZbVBJ+GH/cZrr8rPp6T1Bq6y4G9I= Received: by 10.223.88.216 with SMTP id b24mr12584136fam.30.1320061589899; Mon, 31 Oct 2011 04:46:29 -0700 (PDT) Received: from [192.168.201.25] (192.117.8.42.static.012.net.il. [192.117.8.42]) by mx.google.com with ESMTPS id k16sm37535857fab.8.2011.10.31.04.46.28 (version=SSLv3 cipher=OTHER); Mon, 31 Oct 2011 04:46:29 -0700 (PDT) Message-ID: <4EAE8A92.2080401@gmail.com> Date: Mon, 31 Oct 2011 13:46:26 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1 MIME-Version: 1.0 To: Security Area Directorate , draft-ietf-vcarddav-birth-death-extensions.all@tools.ietf.org, The IESG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] SecDir review of draft-ietf-vcarddav-birth-death-extensions-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 11:46:31 -0000 This document, unlike most IETF documents, deals with matters of life and death. However, again unlike most IETF documents, it involves no security considerations beyond its predecessor. Thanks, Yaron From scott@hyperthought.com Mon Oct 31 05:17:45 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870C421F8DB0 for ; Mon, 31 Oct 2011 05:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKijRWahjNvt for ; Mon, 31 Oct 2011 05:17:45 -0700 (PDT) Received: from smtp122.dfw.emailsrvr.com (smtp122.dfw.emailsrvr.com [67.192.241.122]) by ietfa.amsl.com (Postfix) with ESMTP id 017DB21F8D9E for ; Mon, 31 Oct 2011 05:17:44 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp12.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id F03F93C12D2; Mon, 31 Oct 2011 08:17:42 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp12.relay.dfw1a.emailsrvr.com (Authenticated sender: scott-AT-hyperthought.com) with ESMTPSA id 4C5303C12D1; Mon, 31 Oct 2011 08:17:42 -0400 (EDT) Message-ID: <4EAE91E5.8090908@hyperthought.com> Date: Mon, 31 Oct 2011 05:17:41 -0700 From: "Scott G. Kelly" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Richard Barnes References: <4EAD53ED.60802@hyperthought.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-geopriv-policy-uri.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] draft-ietf-geopriv-policy-uri-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 12:17:45 -0000 Hi Richard, On 10/30/11 1:19 PM, Richard Barnes wrote: > > Why isn't unauthorized manipulation of the policy information also listed as a risk? Actually, the second paragraph of the security considerations addresses this, ("The mechanism also needs to ensure that only authorized entities are able to acquire or alter policy."), but subsequent text seems to indicate that if the policy URI is not kept secret, there are no further protections. > Since we're talking about access control policy here, the effect of "manipulation of the policy information" is precisely "unauthorized disclosure of the protected resource". Does that clear thing sup? I see your point, but manipulation of policy information could also be used to prevent/deny disclosure too. As I noted below, I have no experience with these protocols, and this may not matter, but as a reviewer, I think I should mention it. >> Am I missing something here, or is secrecy of the URI really the only protection against unauthorized policy manipulation? I have to admit that I have no experience with these protocols, and it may be that this is addressed elsewhere (or truly doesn't matter), but it does feel a bit off. > > You're exactly right in that understanding. The idea is that a policy URI is already controlling access control policy on something, so we didn't want to have access control policies for who can access policy URIs (turtles all the way down). That's the reason for all the text about keeping the policy URI secret. I didn't see any language suggesting that if one wishes to mitigate the resulting exposure, these URIs should probably be short-lived. Is that covered in one of the related docs? Again, not sure if this matters, but as the boilerplate suggests, the purpose of these secdir reviews is to let the security ADs (who presumably have much more context) know if there's anything they should be aware of, so I pointed it out. Lacking background and protocol expertise, I don't have any strong position of my own on this. --Scott From rbarnes@bbn.com Mon Oct 31 07:03:09 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E4421F8D77; Mon, 31 Oct 2011 07:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICWiGimng7WJ; Mon, 31 Oct 2011 07:03:08 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id D8F1D21F8D75; Mon, 31 Oct 2011 07:03:08 -0700 (PDT) Received: from [128.89.254.110] (port=60432) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RKsS5-000Ioy-3t; Mon, 31 Oct 2011 10:03:01 -0400 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Richard Barnes In-Reply-To: <4EAE91E5.8090908@hyperthought.com> Date: Mon, 31 Oct 2011 15:02:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <398CF9D4-9B2E-4237-A658-809E73CCD435@bbn.com> References: <4EAD53ED.60802@hyperthought.com> <4EAE91E5.8090908@hyperthought.com> To: "Scott G. Kelly" X-Mailer: Apple Mail (2.1251.1) Cc: draft-ietf-geopriv-policy-uri.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] draft-ietf-geopriv-policy-uri-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 14:03:09 -0000 >> >> Why isn't unauthorized manipulation of the policy information also = listed as a risk? Actually, the second paragraph of the security = considerations addresses this, ("The mechanism also needs to ensure that = only authorized entities are able to acquire or alter policy."), but = subsequent text seems to indicate that if the policy URI is not kept = secret, there are no further protections. >> Since we're talking about access control policy here, the effect of = "manipulation of the policy information" is precisely "unauthorized = disclosure of the protected resource". Does that clear thing sup? >=20 > I see your point, but manipulation of policy information could also be = used to prevent/deny disclosure too. As I noted below, I have no = experience with these protocols, and this may not matter, but as a = reviewer, I think I should mention it. That's a fair point. How about this change to the text: OLD: "The risk of unauthorized disclosure of the protected resource"=20 NEW: "The risk of unauthorized grants or denial of access to the = protected resource"=20 >>> Am I missing something here, or is secrecy of the URI really the = only protection against unauthorized policy manipulation? I have to = admit that I have no experience with these protocols, and it may be that = this is addressed elsewhere (or truly doesn't matter), but it does feel = a bit off. >>=20 >> You're exactly right in that understanding. The idea is that a = policy URI is already controlling access control policy on something, so = we didn't want to have access control policies for who can access policy = URIs (turtles all the way down). That's the reason for all the text = about keeping the policy URI secret. >=20 > I didn't see any language suggesting that if one wishes to mitigate = the resulting exposure, these URIs should probably be short-lived. Is = that covered in one of the related docs? Again, not sure if this = matters, but as the boilerplate suggests, the purpose of these secdir = reviews is to let the security ADs (who presumably have much more = context) know if there's anything they should be aware of, so I pointed = it out. Lacking background and protocol expertise, I don't have any = strong position of my own on this. It's sort of covered in that policy URIs have the same lifetime as the = underlying location URI, but there's not anything like a "key roll-over" = mechanism. It seems to me like the current limitations are sufficient, = but if the ADs feel differently, we can make changes.= From acee.lindem@ericsson.com Mon Oct 31 07:15:15 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB5A21F8B7A; Mon, 31 Oct 2011 07:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.493 X-Spam-Level: X-Spam-Status: No, score=-6.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwYmgVGqn9vH; Mon, 31 Oct 2011 07:15:14 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7811021F8B36; Mon, 31 Oct 2011 07:15:14 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p9VEF2xm020748; Mon, 31 Oct 2011 09:15:04 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.105]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 31 Oct 2011 10:15:02 -0400 From: Acee Lindem To: "Bhatia, Manav (Manav)" Date: Mon, 31 Oct 2011 10:15:00 -0400 Thread-Topic: Secdir review of draft-ietf-ospf-auth-trailer-ospfv3-08 Thread-Index: AcyX13q7N8mb7S8rQmCyvL7Ieaw57g== Message-ID: References: <4EAB88B8.80800@bbn.com> <7C362EEF9C7896468B36C9B79200D8350D00FD4E02@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D00FD4E02@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-ospf-auth-trailer-ospfv3.all@tools.ietf.org" , Sam Hartman , The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ospf-auth-trailer-ospfv3-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 14:15:15 -0000 See inline.=20 On Oct 29, 2011, at 5:24 AM, Bhatia, Manav (Manav) wrote: > Hi Matt, >=20 > Really appreciate the detailed review. >=20 >> A) Section 1.1 describes the work in the IPSECME working >> group to address the shortcomings of ESP-NULL as an >> authentication mechanism. However, it is not clear to me why >> this work in IPSECME (RFCs 5879 and 5840) is insufficient to >> resolve the issues (described in Section 1) that make >> ESP-NULL unsuitable for use as an authentication OSPFv3. That >> is, Section 1.1 describes what the IPSECME working group has >> done to solve the ESP-NULL issues in IPsec, but Section 1.1 >> doesn't answer the question of why in light of the recent >> IPSECME work that this specification is still needed? >=20 > I am the co-author of RFC 5840 (WESP) and while it can be used to solve s= ome issues that exist when using vanilla Ipsec, there will still be some is= sues that it will not address. IPsec works best in the point-to-point topol= ogies and becomes increasingly complex to provision and unscalable when the= re are multiple routers in a broadcast domain and you need a full mesh of c= onnectivity among all the routers. Providers will tell you that it is a nig= htmare managing and maintaining a full mesh of Ipsec tunnels and it just do= esn't work. Then there are licensing issues with Ipsec (which will exist wi= th WESP as well) and its not available on all platforms - the operators wer= e thus not able to secure OSPFv3. We had included this point in this draft = but had removed it since an IETF document shouldn't be discussing licensing= and financial issues. >=20 > So there is enough support for adding an in-band security mechanism withi= n OSPFv3. >=20 >>=20 >> Note: I assume the answer to the question in the previous >> paragraph is that the authors of this specification feel that >> RFC 5879 is insufficient and that RFC 5840 will take too long >> to get deployed, and this might be a good justification for >> the current specification. >> Additionally, since this document, is a new standards track >> extension to OSPFv3, I would like to see an explicit >> justification for why the protocol described in this document >> will see deployment sooner than RFC 5840 (which solves the >> same problem that is solved by the OSPFv3 authentication >> trailer). There is also a statement in Section 1 that IPsec >> is not available on some platforms or environments, but the >> authors to do go into enough detail (or provide suitable >> references) for me to evaluate whether this claim justifies >> creating another standards track mechanism for solving >> authentication in OSPFv3. >=20 > You can google for product specs from the vendors and verify that not all= platforms support Ipsec. We cant add references to their websites in an IE= TF doc. >=20 > Moreover, even if you disregard the financial and political aspects of us= ing Ipsec, there are technical reasons as explained above which require an = alternate mechanism to be explored. >=20 >>=20 >> This document should site RFC 5879 (Heuristics for detecting >> ESP-NULL) in Section 1.1 of the Introduction. >=20 > I could be missing something, but I really find no references to work don= e in IPSECME and WESP (rfc 5840). Are you sure you're looking at the -08 ve= rsion? >=20 >>=20 >> B) In order to prevent cross-protocol replay attacks, this >> document creates a general IANA registry for cryptographic >> protocols (both native IPv4/IPv6 protocols and UDP/TCP >> protocols). The registry is created with only a single entry, >> but the text describing the registry is sufficiently broad as >> to suggest that all protocols that use cryptographic keys >> should be registered. (My apologies if I am misinterpreting >> the IANA considerations text in Section 7 ... it is also >> possible that only a subset of cryptographic protocols need >> to be registered, but it is not clear to me from the text >> what subset this would be.) My understanding is that >> cross-protocol replay attacks are prevented by appending the >> registered protocol ID to the private key to obtain a >> subordinate key for use in the Message Authentication Code. >> However, I am not convinced that this is a good >> general-purpose approach for preventing cross-protocol replay >> attacks. (Perhaps the document could instead contain language >> that the private key for OSPFv3 authentication trailers MUST >> NOT be used in other protocol.) If creating such a general >> registry is a good approach to dealing with cross-protocol >> replay attacks, then I question whether this document is the >> right place to define such a registry. Such a registry seems >> much more likely to be successful if the community in the >> Security Area is involved in specifying the registry and >> populating it with an appropriate set of initial values. >=20 > The original draft did not consider cross-protocol replay attacks and thi= s section was only added after a long, protracted discussion with Sam Hartm= an and Stephen Farell. It was only after they were satisfied with the provi= sions for cross protocol replay attacks that we progressed this draft. >=20 > Ccing Sam, though he should be in the secdir list. >=20 >>=20 >> C) The first paragraph of the Security Considerations for >> this document claim that the authentication trailer >> represents an increase in the security of OSPFv3. In the >> introduction of the document the authors cite RFC 6039 which >> identifies security issues with OSPFv3 (and other routing >> protocols). It would be helpful if the authors could indicate >> in the security considerations section to what extend (if >> any) the authentication trailer addresses the issues raised >> in RFC 6039 (and, similarly, to what extend the >> authentication trailer is providing increased security for OSPFv3). >=20 > RFC 6039 cities the lack of replay protection in OSPFv3 as the reason for= most attacks on OSPFv3. This draft adds support for replay protection and = thus addresses all the issues raised in 6039. >=20 >>=20 >> The introduction cites RFC4552 for an explanation of why >> manual keying is used. This reference should be repeated in >> the Security considerations section. (I would even advocate >> copying the text from the Security Considerations of RFC 4552 >> that deals with the limitations of manual keying.) >> Additionally, RFC 4552 explicitly states that replay >> protection is not provided in OSPFv3. Text from RFC 4552 is >> included in the Introduction, which states that the use of >> manual keying limits the extent to which replay protection >> can be achieved. This authentication header specification >> attempts to provide a degree of replay protection. It would >> be nice if the security considerations section described in >> some detail the extent to which this specification prevents replays. >=20 > Text from 4522 is not relevant here in this document. 4552 describes how = Ipsec can be used to protect OSPFv3. This document describes a mechanism to= protect OSPFv3 without Ipsec. >=20 >=20 >>=20 >> D) This document states (in Section 4.3) that the OSPFv3 >> authentication trailer supports the following four >> authentication algorithms: HMAC-SHA-1, HMAC-SHA-256, >> HMAC-SHA-384, and HMAC-SHA-512. However, in Section 3, it >> does not include references to a document where these >> authentication algorithms are defined. (I believe the right >> documents to reference are RFC 2104 and RFC 4868.) >=20 > We have provided references to the following documents: >=20 > [FIPS-180-3] > US National Institute of Standards & Technology, "Secure > Hash Standard (SHS)", FIPS PUB 180-3 , October 2008. >=20 > [FIPS-198] > US National Institute of Standards & Technology, "The > Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB > 198 , March 2002. >=20 > Isnt this enough? >=20 >> Additionally, for interoperability I would suggest that the >> authors specify at least one of these algorithms are >> mandatory to implement. (The goal is to avoid a situation >> where an operator seeking to use OSPFv3 authentication >> trailer has two OSPFv3-speaking devices from different >> vendors, one which only supports HMAC-SHA-1 and the other >> only supports HMAC-SHA-256). Note: Upon further reading of >> the document, it's not clear to me whether this specification >> works with symmetric-key authentication algorithms other than >> HMAC. If it is the case that the authentication trailer only >> works with HMAC, then the document should instead clearly >> state that authentication trailer makes use of HMAC and >> currently supports the four digest algorithms. >=20 > I agree. >=20 >>=20 >> The Security Considerations for this document (Section 6) >> RECOMMEND that the deployments use a pseudo-random key of at >> least 128-bits. This strikes me as odd, because I believe >> that RFC 2104 which specifies HMAC recommends that the key be >> at least as long as the output size of the hash function (160 >> bits in the case of SHA-1). >=20 > The input key does not necessarily need to be that long. Please look at S= ec 4.5 for more details. The key that's fed to HMAC can be 160 bits even if= the input key is of a smaller size. We are recommending that the input key= should be at least 128 bits long. >=20 > HMAC requires a 160 bit key as the seed. However, for convenience to the = administrators, a specification may not want to require the entry of a PSK = of exactly 20 bytes. Instead, a specification may call for a key preparatio= n routine that could handle a variable length PSK, one that might be less o= r more than 20 bytes (see [RFC4615], section 3, as an example). That key pr= ep routine would derive a key of exactly the required length and thus suita= ble as a seed to the PRF. This does NOT mean that administrators are safe t= o use weak keys. Administrators are encouraged to follow [RFC4086] [NIST-80= 0-118]. We are simply trying to play it safe by recommending that administr= ators should put a password that is at least 16 bytes in length. >=20 > Actually, now that I think about this, specifying a key size of 16 bytes = is also not practical. We could either delete that sentence or reduce the l= ength of the recommended key size. I cant image all admins typing in a 16 b= yte password! It is merely a recommendation (from Stephen Ferrell). Not everyone will fol= low it. At the next IETF, you'll notice at the afternoon break that many at= tendees do not follow the US FDA's or WHO's dietary recommendations.=20 Thanks, Acee=20 >=20 >> E) This document creates a registry of Authentication Trailer >> types and populates it with one value "Cryptographic >> Authentication". First, I believe that the Cryptographic >> Authentication that it is referring to is the mechanism >> described in this document, but this is not stated clearly in >> Section 7. Also, having a specification pointer in the >=20 > Agree. This should be done. >=20 >> registry would be very helpful. Second, having the name >> "Cryptographic Authentication" for the first value in the >> registry seems to suggest that there might be a future type >> of authentication which is "Not Cryptographic" (which seems >> like a bad idea to me). I would suggest that the authors >> change the name of the first value in the registry to >> something a bit more specific. Finally, it is not clear to me >=20 > Any suggestions here? >=20 >> that this registry needs to exist. The existence of the type >> field in the authentication trailer is not justified within >> this document. My belief is that the only reason that a type >> field is included is for backwards compatibility with OSPFv2. >=20 > Yes, this is correct. >=20 > Cheers, Manav From scott@hyperthought.com Mon Oct 31 10:39:53 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4596921F8B4A for ; Mon, 31 Oct 2011 10:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lepYFxgotgex for ; Mon, 31 Oct 2011 10:39:52 -0700 (PDT) Received: from smtp132.iad.emailsrvr.com (smtp132.iad.emailsrvr.com [207.97.245.132]) by ietfa.amsl.com (Postfix) with ESMTP id 8E32921F8BCD for ; Mon, 31 Oct 2011 10:39:52 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp43.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 4AB702D0483; Mon, 31 Oct 2011 13:39:51 -0400 (EDT) X-Virus-Scanned: OK Received: from dynamic3.wm-web.iad.mlsrvr.com (dynamic3.wm-web.iad1a.rsapps.net [192.168.2.152]) by smtp43.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id F37BB2D047A; Mon, 31 Oct 2011 13:39:50 -0400 (EDT) Received: from hyperthought.com (localhost [127.0.0.1]) by dynamic3.wm-web.iad.mlsrvr.com (Postfix) with ESMTP id D2B243320078; Mon, 31 Oct 2011 13:39:50 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Mon, 31 Oct 2011 10:39:50 -0700 (PDT) Date: Mon, 31 Oct 2011 10:39:50 -0700 (PDT) From: "Scott G. Kelly" To: "Richard Barnes" MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain In-Reply-To: <398CF9D4-9B2E-4237-A658-809E73CCD435@bbn.com> References: <4EAD53ED.60802@hyperthought.com> <4EAE91E5.8090908@hyperthought.com> <398CF9D4-9B2E-4237-A658-809E73CCD435@bbn.com> Message-ID: <1320082790.856226845@apps.rackspace.com> X-Mailer: webmail7.0 Cc: draft-ietf-geopriv-policy-uri.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] draft-ietf-geopriv-policy-uri-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 17:39:53 -0000 Hi Richard,=0A=0AI think your proposed change is fine.=0A=0A--Scott=0A=0AOn= Monday, October 31, 2011 7:02am, "Richard Barnes" said:= =0A=0A>>> =0A>>> Why isn't unauthorized manipulation of the pol= icy information also listed as a=0A>>> risk? Actually, the second paragraph= of the security considerations addresses=0A>>> this, ("The mechanism also = needs to ensure that only authorized entities are=0A>>> able to acquire or = alter policy."), but subsequent text seems to indicate that=0A>>> if the po= licy URI is not kept secret, there are no further protections.=0A>>> Since = we're talking about access control policy here, the effect of=0A>>> "manipu= lation of the policy information" is precisely "unauthorized disclosure=0A>= >> of the protected resource". Does that clear thing sup?=0A>>=0A>> I see = your point, but manipulation of policy information could also be used to=0A= >> prevent/deny disclosure too. As I noted below, I have no experience with= these=0A>> protocols, and this may not matter, but as a reviewer, I think = I should mention=0A>> it.=0A> =0A> That's a fair point. How about this cha= nge to the text:=0A> =0A> OLD: "The risk of unauthorized disclosure of the = protected resource"=0A> NEW: "The risk of unauthorized grants or denial of = access to the protected=0A> resource"=0A> =0A> =0A>>>> Am I missing somethi= ng here, or is secrecy of the URI really the only=0A>>>> protection against= unauthorized policy manipulation? I have to admit that I=0A>>>> have no ex= perience with these protocols, and it may be that this is addressed=0A>>>> = elsewhere (or truly doesn't matter), but it does feel a bit off.=0A>>>=0A>>= > You're exactly right in that understanding. The idea is that a policy UR= I is=0A>>> already controlling access control policy on something, so we di= dn't want to=0A>>> have access control policies for who can access policy U= RIs (turtles all the way=0A>>> down). That's the reason for all the text a= bout keeping the policy URI secret.=0A>>=0A>> I didn't see any language sug= gesting that if one wishes to mitigate the resulting=0A>> exposure, these U= RIs should probably be short-lived. Is that covered in one of=0A>> the rela= ted docs? Again, not sure if this matters, but as the boilerplate=0A>> sug= gests, the purpose of these secdir reviews is to let the security ADs (who= =0A>> presumably have much more context) know if there's anything they shou= ld be aware=0A>> of, so I pointed it out. Lacking background and protocol e= xpertise, I don't have=0A>> any strong position of my own on this.=0A> =0A>= It's sort of covered in that policy URIs have the same lifetime as the und= erlying=0A> location URI, but there's not anything like a "key roll-over" m= echanism. It seems=0A> to me like the current limitations are sufficient, = but if the ADs feel=0A> differently, we can make changes.=0A From jsalowey@cisco.com Mon Oct 31 22:45:00 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9325B11E8098; Mon, 31 Oct 2011 22:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.349 X-Spam-Level: X-Spam-Status: No, score=-106.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyGQCtPcD9TM; Mon, 31 Oct 2011 22:45:00 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 24F3721F8DFC; Mon, 31 Oct 2011 22:45:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=719; q=dns/txt; s=iport; t=1320126300; x=1321335900; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=sZp9vSghWfN2lSqQkH0Mm/oQykOEun4zv2iYPNWthos=; b=bulkuNy8xZD0UBM3m4winSg6zF2UTNxvRTaMvgtdCllU4WdmspCQ6UKw F8CYiQWn2YzdbTaX8VHFlPrG+x+505+ctZWecA1Oa80eJXb2knZoQ2Fiz r5dZ7mmzq3CYJ1qiE3PahmTW7bfDmnSgQXIeIIuZL8zUuc/LLSGBaP63M Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAE2Gr06rRDoJ/2dsb2JhbABDqTeBBYILASeBfQE0nV0BnkSIIWEEiAaMCYUtjFI X-IronPort-AV: E=Sophos;i="4.69,436,1315180800"; d="scan'208";a="10318547" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 01 Nov 2011 05:44:59 +0000 Received: from [10.33.251.254] ([10.33.251.254]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pA15iw8d010154; Tue, 1 Nov 2011 05:44:59 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 31 Oct 2011 22:45:20 -0700 Message-Id: To: secdir@ietf.org, The IESG , draft-ietf-tcpm-rfc1948bis.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [secdir] secdir review of draft-ietf-tcpm-rfc1948bis-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 05:45:00 -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.=20 This document is meant to put the ISN generation algorithm from RFC 1948 = on standards track. I did not find any major issues with the document. = In section 3 there is a repeated "the" in the first sentence of the = second paragraph. I like that the document provides rationale why MD5 = is okay to use as a function for the generation. =20 Cheers, Joe =20=