Dear All,

The chairs in conj= unction with our AD, Joel, recently worked on a draft revision to our chart= er text. The changes in this revision are mostly related to elaborating on = the type of documents this WG produces along with some minor wordsmithing h= ere and there.=A0

We would like to get you to review the text and provide= comments. Please have a read and voice an opinion one way or the other. If= we don't hear any objections by June 30th, we'll assume you love i= t and proceed.

Thanks,

KK, Gunter, Warren

P.S. The current version of the charter can be found at=A0http://da= tatracker.ietf.org/wg/opsec/charter/

**********

Proposed Revise= d OPSEC Charter:

"""

Go= als:

Th= e OPSEC WG will document operational issues and best current practices=20 with regard to network security. In particular, efforts will be made to=20 clarify the rationale supporting current operational practice, address=20 gaps in currently understood best practices for forwarding, control=20 plane, and management plane security and clarify liabilities inherent in security practices where they exist.

Scope:

The scope of the OPSEC WG is intended to include the protection and secure=20 operation of the forwarding, control and management planes.=20 Documentation of operational issues, revision of existing operational

security practices documents and proposals for new approaches to operational=20 challenges related to network security are in scope.

Method= :

It is expected that the product of the working group will result in the=20 publication of informational or BCP RFCs. Taxonomy or problem statement=20 documents may provide a basis for such documents.

Informati= onal or Best Current Practices Document

For each topic addressed, a document that attempts to capture common=20 practices related to secure network operation will be produced. This=20 will be primarily based on operational experience. A document might=20 convey:

* a threat or threats to be addressed

<= span style=3D"font-size:13px;font-family:Arial;vertical-align:baseline">* c= urrent practices for addressing the threat

* = protocols, tools and technologies extant at the time of writing that are us= ed to address the threat

* = the possibility that a solution does not exist within existing tools or tec= hnologies

Ta= xonomy and Problem Statement Documents

A document which attempts to describe the scope of particular operational security challenge or problem space without necessarily coming to a=20 conclusion or proposing a solution. Such a document might

be a prec= ursor to an informational or best current practices document.

While the principal input of the working group is operational experience and=20 needs, the output should be directed towards providing guidance to the=20 operators community, other working groups that develop

protocols or = the community of protocol developers at large and implementers of these pro= tocols.

Non-Goals:

The OPSEC WG is not the place to do new protocols. New protocol work should be addressed in a working group chartered in the appropriate area or as individual submissions. The OPSEC WG may take on documents related to=20 the practices of using such work.<= /p>

"""

--001a11c2ed4a033c0a04df0ce4ee-- From pkampana@cisco.com Fri Jun 14 10:58:52 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3883F21F9D18 for ; Fri, 14 Jun 2013 10:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 RcyMLA+MxIiD for ; Fri, 14 Jun 2013 10:58:47 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 64D8121F9D1D for ; Fri, 14 Jun 2013 10:58:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9919; q=dns/txt; s=iport; t=1371232706; x=1372442306; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=44RfKsq8KvQENZKORFEVzV8IfGyMPwU2wBvi39Ft4YA=; b=PLES+OJE3HJ7/kHRPlpaxYpiXfQ5geY1qTihFpR4c/ZpRr4E1FDpwS1D WDi0dtMLzyvenJq6eLC7fVl6PeSkrrllqKzlpyAmEgiZY6ZOlfCcF+0OX OTvdW2TASNRKT10s37y++xCvnLZky8i1ZF+5tDLpOf8ChYJujpZawL8Yv 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnQFAAdZu1GtJV2d/2dsb2JhbABbgkVEMEmrQpMZgQoWdIIjAQEBBC1MEAIBCA4DBAEBCx0HMhQJCAEBBAENBQgBiAUMuWiPFzEGAYJ/YQOpA4MPgig X-IronPort-AV: E=Sophos;i="4.87,867,1363132800"; d="scan'208,217";a="223047497" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 14 Jun 2013 17:58:25 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5EHwP7m016158 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Jun 2013 17:58:25 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Fri, 14 Jun 2013 12:58:24 -0500 From: "Panos Kampanakis (pkampana)" To: Hosnieh Rafiee , "Gunter Van de Velde (gvandeve)" , "opsec@ietf.org" Thread-Topic: [OPSEC] [Reminder] review of draft-gont-opsec-nd-security Thread-Index: Ac5oKXSZ81dhro3PSWWdQfNYDurbrgABKTXQAD5HG8A= Date: Fri, 14 Jun 2013 17:58:23 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A753D10A4@xmb-rcd-x10.cisco.com> References: <67832B1175062E48926BF3CB27C49B240CECD8A6@xmb-aln-x12.cisco.com> <003601ce6830$495c55b0$dc150110$@com> In-Reply-To: <003601ce6830$495c55b0$dc150110$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.89.113] Content-Type: multipart/alternative; boundary="_000_1C9F17D1873AFA47A969C4DD98F98A753D10A4xmbrcdx10ciscocom_" MIME-Version: 1.0 Cc: 'Tim Chown' , "kaeo@merike.com" , "jeanmichel.combes@orange.com" Subject: Re: [OPSEC] [Reminder] review of draft-gont-opsec-nd-security X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 17:58:52 -0000 --_000_1C9F17D1873AFA47A969C4DD98F98A753D10A4xmbrcdx10ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 It seems the document summarizes a lot of the ND operation that is defined = in other RFCs. I understand that the need to be summarized for the purpose = of the doc, but I think there is too much details for already defined conce= pts. It would be better to only go to the detailed needed for the purpose o= f the doc. Also, I too have a concern about the overlap between draft-gont-opsec-nd-se= curity and RFC3756. It seems draft-gont-opsec-nd-security adds scenarios o= f specific attacks that could be deployed using Threats that are also cover= ed in RFC3756. I am not sure if this justifies for a new draft, but if it d= oes it would be better to make clear the doc tries to explain possible outc= omes of exploiting certain protocol issues. Rgs, Panos From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of H= osnieh Rafiee Sent: Thursday, June 13, 2013 8:19 AM To: Gunter Van de Velde (gvandeve); opsec@ietf.org Cc: 'Tim Chown'; kaeo@merike.com; jeanmichel.combes@orange.com Subject: Re: [OPSEC] [Reminder] review of draft-gont-opsec-nd-security Just a general comment. I think there is no need to repeat the security vul= nerabilities that is explained in RFC 3756 and better that the document jus= t cover what is not mentioned in that document http://www.ietf.org/rfc/rfc3= 756.txt . Thanks, Hosnieh From: opsec-bounces@ietf.org [mailto:opsec-b= ounces@ietf.org] On Behalf Of Gunter Van de Velde (gvandeve) Sent: Donnerstag, 13. Juni 2013 13:38 To: opsec@ietf.org Cc: Tim Chown (tjc@ecs.soton.ac.uk); kaeo@merik= e.com; jeanmichel.combes@orange.com Subject: [OPSEC] [Reminder] review of draft-gont-opsec-nd-security Folks, Please send your reviews of draft-gont-opsec-nd-security to the OPSEC WG li= st. Kind Regards, G/ --_000_1C9F17D1873AFA47A969C4DD98F98A753D10A4xmbrcdx10ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It seems the document = summarizes a lot of the ND operation that is defined in other RFCs. I under= stand that the need to be summarized for the purpose of the doc, but I thin= k there is too much details for already defined concepts. It would be better to only go to the detailed needed for= the purpose of the doc.

Also, I too have a con= cern about the overlap between draft-gont-opsec-nd-security and RFC37= 56. It seems draft-gont-opsec-nd-security adds scenarios of specific attack= s that could be deployed using Threats that are also covered in RFC3756. I am not sure if this justifies for a new dra= ft, but if it does it would be better to make clear the doc tries to explai= n possible outcomes of exploiting certain protocol issues.

Rgs,=

Panos

From: opsec-bo= unces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of Hosnieh Rafiee
Sent: Thursday, June 13, 2013 8:19 AM
To: Gunter Van de Velde (gvandeve); opsec@ietf.org
Cc: 'Tim Chown'; kaeo@merike.com; jeanmichel.combes@orange.com
Subject: Re: [OPSEC] [Reminder] review of draft-gont-opsec-nd-securi= ty

Just a general comment= . I think there is no need to repeat the security vulnerabilities that is e= xplained in RFC 3756 and better that the document just cover what is not me= ntioned in that document http://www.ietf.org/rfc/rfc= 3756.txt .

Thanks,

Hosnieh

From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of Gunter Van de Velde (gvandeve)
Sent: Donnerstag, 13. Juni 2013 13:38
To: opsec@ietf.org
Cc: Tim Chown (tjc@ecs.soton.= ac.uk); kaeo@merike.com; jeanmichel.combes@orange.com
Subject: [OPSEC] [Reminder] review of draft-gont-opsec-nd-security

Folks,

Please send your reviews of dra= ft-gont-opsec-nd-security to the OPSEC WG list.

Kind Regards,=

--_000_1C9F17D1873AFA47A969C4DD98F98A753D10A4xmbrcdx10ciscocom_-- From arturo.servin@gmail.com Mon Jun 24 05:13:12 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817DC21E80E8 for ; Mon, 24 Jun 2013 05:13:12 -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=[AWL=-1.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l24occVkS5tX for ; Mon, 24 Jun 2013 05:13:12 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A1A5A11E8137 for ; Mon, 24 Jun 2013 05:13:11 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id v1so435202lbd.32 for ; Mon, 24 Jun 2013 05:13:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=q5k4aIYLlhrhTfCJNOdSgupHcTj2EGT5zXK/mmonUKs=; b=FxlNPyrPkbIkuPWHJoXbQrsmPQDhSj/Q4TpU/iyjvcxSScWISu+Xa9kXZDQBGaS6EK pUBqeHxlWhSYelretcavuTR++3V2KDGi0mpGWvSZHbydnztnQZPNSqBuCNyX/bw+9N9L CpEHPME72cNnfBxNOd51/qL1jsMBu0rjB5CrC9/2f8PPKNhNPlS9Mbmc/hw2+aa5k/3a KKwUwtL7ulFDHP77RJsaZdHbsXoFYv3s+zsa/FwAHCCJhXpIgPQnXZl5HGnCT9nJqVhT LaW86SVZXU+Mcb1vlF4lstXMPzlpj9oe0k5S7Pe54lgN56c7KKItLJBApExDh7ZpFQED euPQ== X-Received: by 10.112.4.164 with SMTP id l4mr4211252lbl.94.1372075989359; Mon, 24 Jun 2013 05:13:09 -0700 (PDT) Received: from [192.168.0.10] ([90.214.123.34]) by mx.google.com with ESMTPSA id am8sm6597482lac.1.2013.06.24.05.13.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Jun 2013 05:13:08 -0700 (PDT) Message-ID: <51C837D3.4010904@gmail.com> Date: Mon, 24 Jun 2013 13:13:07 +0100 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: opsec@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 24 Jun 2013 05:13:52 -0700 Subject: [OPSEC] Review of: draft-ietf-opsec-ip-options-filtering-02 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 12:13:12 -0000 I reviewed the document draft-ietf-opsec-ip-options-filtering-02. It is very well written and it explains very well the problems and threats of each IP option. The advices given through the document are clear, plausible and very logical to me. I have a few minor comments: Section 4.8.5 "Additionally, Routers, security gateways, and firewalls SHOULD have a configuration setting that indicates whether they should react react on the Router Alert option as indicated in the corresponding specification or ignore the option, or whether packets containing this option should be dropped (with the default configuration being to ignore the Router Alert option)." This paragraph is a bit confusing. It is not clear to me if the two options are to drop the packet and do nothing (ignore the option). I would suggest rephrasing it. Also it has a typo (they should react react) Section 4.12.2 I am not sure the goal of the paragraph about the Cisco routers. It looks to "Cisco centric" to me. I would just remove the whole paragraph as I do not see any value added by it. The same is for section 4.13.2 �. Section 4.12.5 I wonder that if this option is only used within very secure networks and it is not common or used in the Internet the advice is to forward it. I would assume that the advice should be to drop unless the network admin expects to see this option. This same applies to section 4.13.5 and 4.14.5 Section 4.22.5 The advice mentions "drop and log event" as the default. I wonder that if logging a large amount of packets with these options would create a DoS on the control plane. Perhaps the default should be just drop or to add an advice that excessive logging could also be an attack vector. Same for 4.23.4 about "Other IP options" and in general every time that the document recommends "drop and logging". Best regards. /Arturo Servin From cpignata@cisco.com Mon Jun 24 07:28:31 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A057A11E815C for ; Mon, 24 Jun 2013 07:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJ5-d8qS4hwh for ; Mon, 24 Jun 2013 07:28:26 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id AE77A21F9D91 for ; Mon, 24 Jun 2013 07:28:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2795; q=dns/txt; s=iport; t=1372084106; x=1373293706; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=9X4kemDaQuhD2ow1eUli2GDBx30+4Jqs8x7gUJbGeaw=; b=F8ihhAs9+tXw3vJTLOuuo0DqGzRGKmjNILFjHKMOh+4bQyyrqJooQM2g Kx2+vru0+T6SpfOwuAYjB/v7zTMm6gYaGcYcCH74lRCbgk8AfiPg2gTOh T90Rm0gHTuEf20aDaSRHEd2RTSkUwjoggHNZnYwyTH7nhgyCXh0qzg/h7 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FANRWyFGtJXG9/2dsb2JhbABbgwkxSb83gQQWdIIjAQEBAwEBAQFrCxACAQgiJCEGCyUCBA4FCId0AwkGDLETDYhOBIxogjQCMQeDAmEDlVyOB4UkgxCCKA X-IronPort-AV: E=Sophos;i="4.87,928,1363132800"; d="scan'208";a="226480927" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 24 Jun 2013 14:28:26 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5OESQSx010724 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Jun 2013 14:28:26 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.116]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Mon, 24 Jun 2013 09:28:25 -0500 From: "Carlos Pignataro (cpignata)" To: Arturo Servin Thread-Topic: [OPSEC] Review of: draft-ietf-opsec-ip-options-filtering-02 Thread-Index: AQHOcNRNu4UDPw83oEGNf2neu7CvGJlFQFWA Date: Mon, 24 Jun 2013 14:28:25 +0000 Message-ID: <95067C434CE250468B77282634C96ED322C81422@xmb-aln-x02.cisco.com> References: <51C837D3.4010904@gmail.com> In-Reply-To: <51C837D3.4010904@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.81.8.121] Content-Type: text/plain; charset="Windows-1252" Content-ID: <160DF18D9E6D4249B7342EA9CD7B76BD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [OPSEC] Review of: draft-ietf-opsec-ip-options-filtering-02 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 14:28:31 -0000 Thanks, Arturo, for this review! Much appreciated. While we review these comments, one questions for the chairs... There was a WGLC on this document started on Feb 18, 2013, and it appears i= t was never "formally closed". What is the status of that? I assume the WGL= C ended on "04-Mar-2013" as per the WGLC message -- could you please summar= ize the outcome and next steps (i.e., is the doc ready to be submitted to t= he IESG, after we submit a -03 incorporating comments?) Thanks, -- Carlos. On Jun 24, 2013, at 8:13 AM, Arturo Servin wrote: >=20 > I reviewed the document draft-ietf-opsec-ip-options-filtering-02. It is > very well written and it explains very well the problems and threats of > each IP option. The advices given through the document are clear, > plausible and very logical to me. >=20 > I have a few minor comments: >=20 > Section 4.8.5 >=20 > "Additionally, > Routers, security gateways, and firewalls SHOULD have a configuration > setting that indicates whether they should react react on the Router > Alert option as indicated in the corresponding specification or > ignore the option, or whether packets containing this option should > be dropped (with the default configuration being to ignore the Router > Alert option)." >=20 > This paragraph is a bit confusing. It is not clear to me if the two > options are to drop the packet and do nothing (ignore the option). I > would suggest rephrasing it. Also it has a typo (they should react react) >=20 > Section 4.12.2 >=20 > I am not sure the goal of the paragraph about the Cisco routers. It > looks to "Cisco centric" to me. I would just remove the whole paragraph > as I do not see any value added by it. >=20 > The same is for section 4.13.2 =85. >=20 > Section 4.12.5 >=20 > I wonder that if this option is only used within very secure networks > and it is not common or used in the Internet the advice is to forward > it. I would assume that the advice should be to drop unless the network > admin expects to see this option. >=20 > This same applies to section 4.13.5 and 4.14.5 >=20 > Section 4.22.5 >=20 > The advice mentions "drop and log event" as the default. I wonder that > if logging a large amount of packets with these options would create a > DoS on the control plane. Perhaps the default should be just drop or to > add an advice that excessive logging could also be an attack vector. >=20 > Same for 4.23.4 about "Other IP options" and in general every time that > the document recommends "drop and logging". >=20 > Best regards. > /Arturo Servin >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From warren@kumari.net Mon Jun 24 13:12:18 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB3021E8114 for ; Mon, 24 Jun 2013 13:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.356 X-Spam-Level: X-Spam-Status: No, score=-102.356 tagged_above=-999 required=5 tests=[AWL=0.243, 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 dUT0pZ0k5RG0 for ; Mon, 24 Jun 2013 13:12:13 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F30D21E810C for ; Mon, 24 Jun 2013 13:12:13 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.90]) by vimes.kumari.net (Postfix) with ESMTPSA id A12F51B407D8; Mon, 24 Jun 2013 16:12:12 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 $1508$) From: Warren Kumari In-Reply-To: <95067C434CE250468B77282634C96ED322C81422@xmb-aln-x02.cisco.com> Date: Mon, 24 Jun 2013 16:12:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <51A2A369-E6CF-49D9-8238-C063D6DDADDE@kumari.net> References: <51C837D3.4010904@gmail.com> <95067C434CE250468B77282634C96ED322C81422@xmb-aln-x02.cisco.com> To: Carlos Pignataro (cpignata) X-Mailer: Apple Mail (2.1508) Cc: Arturo Servin , "" , Warren Kumari Subject: Re: [OPSEC] Review of: draft-ietf-opsec-ip-options-filtering-02 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 20:12:18 -0000 On Jun 24, 2013, at 10:28 AM, Carlos Pignataro (cpignata) = wrote: > Thanks, Arturo, for this review! Much appreciated. >=20 > While we review these comments, one questions for the chairs... >=20 > There was a WGLC on this document started on Feb 18, 2013, and it = appears it was never "formally closed". Yup, you are right, it was not formally closed. We were attempting to = win the record for the longest WGLC, but seeing as you asked, we have = decided to abort this valiant effort :-P > What is the status of that? I assume the WGLC ended on "04-Mar-2013" = as per the WGLC message -- could you please summarize the outcome The status was (and I apologize, this was not well communicated[0]) that = we did not feel that we had gotten sufficient review. We asked for more volunteers, and Merike, Ron Bonica and Arturo stepped = up (thanks!).=20 They have now completed their reviews (thanks again!)[1]. > and next steps (i.e., is the doc ready to be submitted to the IESG, = after we submit a -03 incorporating comments?) Assuming the comments are integrated (and that Merike didn't stumble = across anything *too* scary) we think that the this should be ready for = the IESG. Apologies for the delay.=20 W [0]: IIRC we discussed this in the in person meeting, but then didn't = really followup on-list correctly.=20 [1]: Merike has reviewed the document, but is currently sitting on a = plane and so has not yet had a chance to send them in=85=20 >=20 > Thanks, >=20 > -- Carlos. >=20 > On Jun 24, 2013, at 8:13 AM, Arturo Servin = wrote: >=20 >>=20 >> I reviewed the document draft-ietf-opsec-ip-options-filtering-02. It = is >> very well written and it explains very well the problems and threats = of >> each IP option. The advices given through the document are clear, >> plausible and very logical to me. >>=20 >> I have a few minor comments: >>=20 >> Section 4.8.5 >>=20 >> "Additionally, >> Routers, security gateways, and firewalls SHOULD have a configuration >> setting that indicates whether they should react react on the Router >> Alert option as indicated in the corresponding specification or >> ignore the option, or whether packets containing this option should >> be dropped (with the default configuration being to ignore the Router >> Alert option)." >>=20 >> This paragraph is a bit confusing. It is not clear to me if the two >> options are to drop the packet and do nothing (ignore the option). I >> would suggest rephrasing it. Also it has a typo (they should react = react) >>=20 >> Section 4.12.2 >>=20 >> I am not sure the goal of the paragraph about the Cisco routers. It >> looks to "Cisco centric" to me. I would just remove the whole = paragraph >> as I do not see any value added by it. >>=20 >> The same is for section 4.13.2 =85. >>=20 >> Section 4.12.5 >>=20 >> I wonder that if this option is only used within very secure networks >> and it is not common or used in the Internet the advice is to forward >> it. I would assume that the advice should be to drop unless the = network >> admin expects to see this option. >>=20 >> This same applies to section 4.13.5 and 4.14.5 >>=20 >> Section 4.22.5 >>=20 >> The advice mentions "drop and log event" as the default. I wonder = that >> if logging a large amount of packets with these options would create = a >> DoS on the control plane. Perhaps the default should be just drop or = to >> add an advice that excessive logging could also be an attack vector. >>=20 >> Same for 4.23.4 about "Other IP options" and in general every time = that >> the document recommends "drop and logging". >>=20 >> Best regards. >> /Arturo Servin >>=20 >>=20 >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec >=20 --=20 With Feudalism, it's your Count that votes. From internet-drafts@ietf.org Mon Jun 24 21:36:37 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7AC621F9DED; Mon, 24 Jun 2013 21:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLmi8Wtc84SI; Mon, 24 Jun 2013 21:36:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5895421F9DCA; Mon, 24 Jun 2013 21:36:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130625043636.21395.65734.idtracker@ietfa.amsl.com> Date: Mon, 24 Jun 2013 21:36:36 -0700 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-vpn-leakages-01.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 04:36:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operational Security Capabilities for IP = Network Infrastructure Working Group of the IETF. Title : Virtual Private Network (VPN) traffic leakages in dual-s= tack hosts/ networks Author(s) : Fernando Gont Filename : draft-ietf-opsec-vpn-leakages-01.txt Pages : 15 Date : 2013-06-24 Abstract: The subtle way in which the IPv6 and IPv4 protocols co-exist in typical networks, together with the lack of proper IPv6 support in popular Virtual Private Network (VPN) products, may inadvertently result in VPN traffic leaks. That is, traffic meant to be transferred over a VPN connection may leak out of such connection and be transferred in the clear from the local network to the final destination. This document discusses some scenarios in which such VPN leakages may occur, either as a side effect of enabling IPv6 on a local network, or as a result of a deliberate attack from a local attacker. Additionally, it discusses possible mitigations for the aforementioned issue. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-vpn-leakages-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-vpn-leakages-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From kkumar@google.com Sun Jun 30 10:11:30 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C43721F9BAC for ; Sun, 30 Jun 2013 10:11: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, HTML_MESSAGE=0.001, NO_RELAYS=-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 opeekIkIHGCQ for ; Sun, 30 Jun 2013 10:11:29 -0700 (PDT) Received: from mail-qe0-x22d.google.com (mail-qe0-x22d.google.com [IPv6:2607:f8b0:400d:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B520621F9BAB for ; Sun, 30 Jun 2013 10:11:29 -0700 (PDT) Received: by mail-qe0-f45.google.com with SMTP id w7so1322360qeb.32 for ; Sun, 30 Jun 2013 10:11:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2yDolcJ2tHpDgM9YlsojrTPDkohO61qNYBsEwkphZ9g=; b=IMqdrh35u5p9zH8BUbYEh4cyCFqauHb3YP5n2ASu/njetHZWvnIFm8QP6Rqri/XTXL r7TbxVMfalTu3CYzC9nbmDaOeetwTU9RsAvWTxQitJOwu9oQLP0yo3KUA0TLnbF/kUXy xC4wSB2Y9Hng0peSe1jpN+zGj0iY7TRt7jDTgCvA5uUpW0AF1TAVDCeI86ZCvTMCA9K/ j8+07g0tE0ZXip+PZoOWLtRULsTU05iPdMdUch4EVcJgL7oJ1KY6PRbF0KofL2MlKn+9 W6cEw38r21PXVfrTOnQvPtcR77MYDoc69nKepuLZfQ3mk8Y+QJ00PTo3ChBYTvpANnwo kEow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=2yDolcJ2tHpDgM9YlsojrTPDkohO61qNYBsEwkphZ9g=; b=az1Bl8NmhXyZqYEpDwaR5vPiwzpcjCdHhKGmDUNUSo8+gOMMjTdk/RwqYX8Enqm39I LhD/n9EvIvicceSeYYOejRMOLQmhUDnZs3I8taP/ac7R8OryY44QLt7WpngQ5lp5/BU1 PeoRwh8w+h5qnhUQ3YxMeXHTG7ATTTDNlU53PE6Z46Kmu5X+PHkYYXsUHJh0MBB4ZoZf Yu81g3/4qj1RQzsCSeYdUMp4/gewWIFUo1ZMMWScVBZSztRraLQzkUOoiofwmtvhuaUe 2ZC0SozxSW9icJlcQh8aJLh1iloa4fEIAREmHccHYKPTjRdRO6njg+x4bFGdj+H//DMf qh9w== X-Received: by 10.229.158.206 with SMTP id g14mr3522005qcx.22.1372612289081; Sun, 30 Jun 2013 10:11:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.52.148 with HTTP; Sun, 30 Jun 2013 10:11:08 -0700 (PDT) In-Reply-To: References: From: KK Date: Sun, 30 Jun 2013 10:11:08 -0700 Message-ID: To: "opsec@ietf.org" Content-Type: multipart/alternative; boundary=f46d04446b43e7d3b604e06233a3 X-Gm-Message-State: ALoCoQm0XXrWxhy56ugC5ACBef2awj46Pnoin02OPHheu7nB67MmQssdEG2d6hR4u5UwvQ1z8iQdez68qteWFyOpFtiHea/reNXVBjW1InfBrWM0Gm5CSvHCR3n85K5tHANxheHgReg0eVB9rh7szRoDBjpVdXM09DdRccshto7XCAG5DVB789g+FwK5ToVKKbqj0rUjhBzp Cc: opsec chairs Subject: Re: [OPSEC] Revised Charter Text X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jun 2013 17:11:30 -0000 --f46d04446b43e7d3b604e06233a3 Content-Type: text/plain; charset=ISO-8859-1 Hey Folks, Just a reminder, we'll be wrapping this up today. Thanks, KK On Thu, Jun 13, 2013 at 10:59 AM, KK wrote: > Dear All, > > The chairs in conjunction with our AD, Joel, recently worked on a draft > revision to our charter text. The changes in this revision are mostly > related to elaborating on the type of documents this WG produces along with > some minor wordsmithing here and there. > > We would like to get you to review the text and provide comments. Please > have a read and voice an opinion one way or the other. If we don't hear any > objections by June 30th, we'll assume you love it and proceed. > > Thanks, > KK, Gunter, Warren > > P.S. The current version of the charter can be found at > http://datatracker.ietf.org/wg/opsec/charter/ > > > ********** > > Proposed Revised OPSEC Charter: > > """ > > Goals: > > The OPSEC WG will document operational issues and best current practices > with regard to network security. In particular, efforts will be made to > clarify the rationale supporting current operational practice, address gaps > in currently understood best practices for forwarding, control plane, and > management plane security and clarify liabilities inherent in security > practices where they exist. > > Scope: > > The scope of the OPSEC WG is intended to include the protection and secure > operation of the forwarding, control and management planes. Documentation > of operational issues, revision of existing operational > > security practices documents and proposals for new approaches to > operational challenges related to network security are in scope. > > Method: > > It is expected that the product of the working group will result in the > publication of informational or BCP RFCs. Taxonomy or problem statement > documents may provide a basis for such documents. > > Informational or Best Current Practices Document > > For each topic addressed, a document that attempts to capture common > practices related to secure network operation will be produced. This will > be primarily based on operational experience. A document might convey: > > * a threat or threats to be addressed > > * current practices for addressing the threat > > * protocols, tools and technologies extant at the time of writing that are > used to address the threat > > * the possibility that a solution does not exist within existing tools or > technologies > > Taxonomy and Problem Statement Documents > > A document which attempts to describe the scope of particular operational > security challenge or problem space without necessarily coming to a > conclusion or proposing a solution. Such a document might > > be a precursor to an informational or best current practices document. > > While the principal input of the working group is operational experience > and needs, the output should be directed towards providing guidance to the > operators community, other working groups that develop > > protocols or the community of protocol developers at large and > implementers of these protocols. > > Non-Goals: > > The OPSEC WG is not the place to do new protocols. New protocol work > should be addressed in a working group chartered in the appropriate area or > as individual submissions. The OPSEC WG may take on documents related to > the practices of using such work. > > > """ > --f46d04446b43e7d3b604e06233a3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hey Folks,

Just a reminder, we'll b= e wrapping this up today.

Thanks,

KK=

O= n Thu, Jun 13, 2013 at 10:59 AM, KK <kk@google.com> wrote:

Dear All,
The chairs in conjunction with our AD, Joel, recently worked o= n a draft revision to our charter text. The changes in this revision are mo= stly related to elaborating on the type of documents this WG produces along= with some minor wordsmithing here and there.=A0

We would like to get you to review the text and provide= comments. Please have a read and voice an opinion one way or the other. If= we don't hear any objections by June 30th, we'll assume you love i= t and proceed.

Thanks,
KK, Gunter, Warren

P.S. The current version of the charter can be found at=A0http://da= tatracker.ietf.org/wg/opsec/charter/

**********

Proposed Revise= d OPSEC Charter:

"""

=
Go= als:

Th= e OPSEC WG will document operational issues and best current practices=20 with regard to network security. In particular, efforts will be made to=20 clarify the rationale supporting current operational practice, address=20 gaps in currently understood best practices for forwarding, control=20 plane, and management plane security and clarify liabilities inherent in security practices where they exist.

Scope:

The scope of the OPSEC WG is intended to include the protection and secure=20 operation of the forwarding, control and management planes.=20 Documentation of operational issues, revision of existing operational
security practices documents and proposals for new approaches to operational=20 challenges related to network security are in scope.

Method= :

It is expected that the product of the working group will result in the=20 publication of informational or BCP RFCs. Taxonomy or problem statement=20 documents may provide a basis for such documents.

Informati= onal or Best Current Practices Document

For each topic addressed, a document that attempts to capture common=20 practices related to secure network operation will be produced. This=20 will be primarily based on operational experience. A document might=20 convey:

* a threat or threats to be addressed

<= span style=3D"font-size:13px;font-family:Arial;vertical-align:baseline">* c= urrent practices for addressing the threat
* = protocols, tools and technologies extant at the time of writing that are us= ed to address the threat
* = the possibility that a solution does not exist within existing tools or tec= hnologies

Ta= xonomy and Problem Statement Documents

A document which attempts to describe the scope of particular operational security challenge or problem space without necessarily coming to a=20 conclusion or proposing a solution. Such a document might
be a prec= ursor to an informational or best current practices document.

While the principal input of the working group is operational experience and=20 needs, the output should be directed towards providing guidance to the=20 operators community, other working groups that develop
protocols or = the community of protocol developers at large and implementers of these pro= tocols.

Non-Goals:

The OPSEC WG is not the place to do new protocols. New protocol work should be addressed in a working group chartered in the appropriate area or as individual submissions. The OPSEC WG may take on documents related to=20 the practices of using such work.<= /p>

"""

--f46d04446b43e7d3b604e06233a3-- From cpignata@cisco.com Sun Jun 30 11:37:51 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5501D21F9BD1 for ; Sun, 30 Jun 2013 11:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etKONOmUZdN7 for ; Sun, 30 Jun 2013 11:37:46 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBDE21F9BC2 for ; Sun, 30 Jun 2013 11:37:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17372; q=dns/txt; s=iport; t=1372617466; x=1373827066; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9BRZcIckQ1RupyPUKyndi5Qd9ePXdVGyP4Mf8P+u88M=; b=mMvFSuKvioEWMoDhzegyEHvA34uNnEL7nbSvnqnieoSnkI6UvA/9pA+/ SXgTxShD+X3RgxZJNfOoVqgBSk7ipJB6qODFmixiY6noRPwzbeQTO3hGg ZaIs627G8k5sWSY73fiADwr1KtCFiCbhV9vdN86mf+7evSfqn0ROjAFRT o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApgFAD150FGtJV2b/2dsb2JhbABagkVEMq1uiTaIOn4WdIIkAQEBAwEBAWsLEAIBCD8HJwsUEQIEDgUUB4d0DLpsj1oEB4MEYwOXSIEpkByDEQ X-IronPort-AV: E=Sophos;i="4.87,969,1363132800"; d="scan'208,217";a="229196093" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 30 Jun 2013 18:37:45 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5UIbjve011927 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 30 Jun 2013 18:37:45 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.116]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Sun, 30 Jun 2013 13:37:44 -0500 From: "Carlos Pignataro (cpignata)" To: KK Thread-Topic: [OPSEC] Revised Charter Text Thread-Index: AQHOdbTgJuGb2uIcIUKZf0sqKyfIZJlOlmeJ Date: Sun, 30 Jun 2013 18:37:44 +0000 Message-ID: <33A9837F-2C99-43CC-9F82-6D39AD61362D@cisco.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_33A9837F2C9943CC9F826D39AD61362Dciscocom_" MIME-Version: 1.0 Cc: "opsec@ietf.org" , opsec chairs Subject: Re: [OPSEC] Revised Charter Text X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jun 2013 18:37:51 -0000 --_000_33A9837F2C9943CC9F826D39AD61362Dciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable KK, chairs, Joel, The revised charter looks good to me. One small comment, the following sentence seems to be a bit of a runaway lo= ng one: "In particular, efforts will be made to clarify the rationale supporting cu= rrent operational practice, address gaps in currently understood best pract= ices for forwarding, control plane, and management plane security and clari= fy liabilities inherent in security practices where they exist." (Plus there's a preposition missing after "rationale") I wonder if it could= be fragmented or turned into a list. For example: "The working group documents security practices in the forwarding, control,= and management planes. In particular, efforts will be made to clarify the = rationale of supporting current operational practice, addressing gaps in cu= rrently understood best practices, and clarifying liabilities inherent in s= ecurity practices where they exist." Thanks, Thumb typed by Carlos Pignataro. Excuze typofraphicak errows On Jun 30, 2013, at 1:11 PM, "KK" > wro= te: Hey Folks, Just a reminder, we'll be wrapping this up today. Thanks, KK On Thu, Jun 13, 2013 at 10:59 AM, KK > = wrote: Dear All, The chairs in conjunction with our AD, Joel, recently worked on a draft rev= ision to our charter text. The changes in this revision are mostly related = to elaborating on the type of documents this WG produces along with some mi= nor wordsmithing here and there. We would like to get you to review the text and provide comments. Please ha= ve a read and voice an opinion one way or the other. If we don't hear any o= bjections by June 30th, we'll assume you love it and proceed. Thanks, KK, Gunter, Warren P.S. The current version of the charter can be found at http://datatracker.= ietf.org/wg/opsec/charter/ ********** Proposed Revised OPSEC Charter: """ Goals: The OPSEC WG will document operational issues and best current practices wi= th regard to network security. In particular, efforts will be made to clari= fy the rationale supporting current operational practice, address gaps in c= urrently understood best practices for forwarding, control plane, and manag= ement plane security and clarify liabilities inherent in security practices= where they exist. Scope: The scope of the OPSEC WG is intended to include the protection and secure = operation of the forwarding, control and management planes. Documentation o= f operational issues, revision of existing operational security practices documents and proposals for new approaches to operationa= l challenges related to network security are in scope. Method: It is expected that the product of the working group will result in the pub= lication of informational or BCP RFCs. Taxonomy or problem statement docume= nts may provide a basis for such documents. Informational or Best Current Practices Document For each topic addressed, a document that attempts to capture common practi= ces related to secure network operation will be produced. This will be prim= arily based on operational experience. A document might convey: * a threat or threats to be addressed * current practices for addressing the threat * protocols, tools and technologies extant at the time of writing that are = used to address the threat * the possibility that a solution does not exist within existing tools or t= echnologies Taxonomy and Problem Statement Documents A document which attempts to describe the scope of particular operational s= ecurity challenge or problem space without necessarily coming to a conclusi= on or proposing a solution. Such a document might be a precursor to an informational or best current practices document. While the principal input of the working group is operational experience an= d needs, the output should be directed towards providing guidance to the op= erators community, other working groups that develop protocols or the community of protocol developers at large and implementers= of these protocols. Non-Goals: The OPSEC WG is not the place to do new protocols. New protocol work should= be addressed in a working group chartered in the appropriate area or as in= dividual submissions. The OPSEC WG may take on documents related to the pra= ctices of using such work. """ _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec --_000_33A9837F2C9943CC9F826D39AD61362Dciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

KK, chairs, Joel,

The revised charter looks good to me.

One small comment, the following sentence seems to be a bit of a runaw= ay long one:

"In particular, efforts will be made to clarify the rationale supporting curre= nt operational practice, address gaps in currently understood best practice= s for forwarding, control plane, and management plane security and clarify = liabilities inherent in security practices where they exist."

(Plus there's a preposition missing after "rationale") I won= der if it could be fragmented or turned into a list. For example:

"The working group documents security practices in the forwarding, control, and management planes. In particular, efforts will be made to clarify the rationale of supporting cu= rrent operational practice, addressing gaps in currently understood best pr= actices, and clarifying liabilities inherent in security practices where th= ey exist."

Thanks,

Excuze typofraphicak errows