From kkumar@google.com Mon Jul 1 18:53:32 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 A709611E8362 for ; Mon, 1 Jul 2013 18:53:32 -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 Vth0Il7sGkjW for ; Mon, 1 Jul 2013 18:53:31 -0700 (PDT) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 68A1D11E834F for ; Mon, 1 Jul 2013 18:53:31 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id hu16so2492398qab.8 for ; Mon, 01 Jul 2013 18:53:30 -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=6XrCTYpJP14ldyBiphOVo6MciyYwcC23zcDEXww/gfc=; b=eL2BBBKW62yoez9MAiJIyKQpQJOEBbx3FJCREuojpCN/RT1VFVVkQV/ZHf1HO6SFs4 8trhNuTas9pwEMZIGb9/wyImg7GZ0lqAUCg+obevLqATw1qbgbfGFXwxnl9796PoQFq3 +nN+xC8WuMOGf/fcLxZKvcVhOkPgUEX9MeNfx1IMPyyzNGAxP9Dcj1MhsU8F9r62QaF8 QKiX8f0bkhXtcfZurW1YHTGmmgGCje2gt4uqBmsx3cTtN6jEpWOGRMM6zuWJFMByNDe3 VDn3LGl2i+bL08Z8PeR9l4+6q7yoVQL0YG91RAriwby+8ZkElXWVlyDrg4QPC1Z47lFq aHyA== 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=6XrCTYpJP14ldyBiphOVo6MciyYwcC23zcDEXww/gfc=; b=CZIaKmkASPLhHcs86Td9+r3LBjnIQdgOM93ovDNCnfsChXYEmS9fK1y6mrCKqP3Gva UYcP8ktKE2VvPjLT1ay3RxZLC2Nr9m4eLODvwGiyE4fr/1LZ7YjT8LSFUYXU+NQVWSrf DRsb5C09vRJ+MQTBLcDeT7RdiALPzldOGqw5CPI8ZaVUfbxkxlgWk6J0Juwtb0fsRm1X G5hUPbrbT2mNc9gM9WBaASUSHKGpVl2ytuVhutsHGAyIggaOMjfdR/TzpYPhqlRPcOeb AiQFrEounHSfjcmbf5m83rugHq5Y9Kq1aaXSweGLbTuCGdyScCrACvMleWaB4v7QQIyd JJiQ== X-Received: by 10.224.74.72 with SMTP id t8mr35574466qaj.74.1372730009220; Mon, 01 Jul 2013 18:53:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.52.148 with HTTP; Mon, 1 Jul 2013 18:53:09 -0700 (PDT) In-Reply-To: <33A9837F-2C99-43CC-9F82-6D39AD61362D@cisco.com> References: <33A9837F-2C99-43CC-9F82-6D39AD61362D@cisco.com> From: KK Date: Mon, 1 Jul 2013 18:53:09 -0700 Message-ID: To: "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=001a11c3bec0929ba304e07d9cea X-Gm-Message-State: ALoCoQn6xqaksjvmAvH/YkjYk0sT0GKnzto/Ric1hRRXRHqqA6lFEtGzL9xTDAikSILVXTPvc4V0AzIx5dRTWZUKnlm1V65jW+t8edZ6tPS11esHCChy0Ugs3TwdHKdwQguQEo0HuWo+5uOHxuhVMsgxDDv0WDAGn+0dZ4MbvxApPBhkpSLHgwWloPCPEGEcw+umxp5Kyuuz 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: Tue, 02 Jul 2013 01:53:32 -0000 --001a11c3bec0929ba304e07d9cea Content-Type: text/plain; charset=ISO-8859-1 Carlos, Thank you very much for the review and suggested text. I like your suggestion and will incorporate it. Regards, KK On Sun, Jun 30, 2013 at 11:37 AM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > KK, chairs, Joel, > > The revised charter looks good to me. > > One small comment, the following sentence seems to be a bit of a runaway > long one: > "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." > > (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 currently understood best practices, and clarifying > liabilities inherent in security practices where they exist." > > Thanks, > > Thumb typed by Carlos Pignataro. > Excuze typofraphicak errows > > On Jun 30, 2013, at 1:11 PM, "KK" wrote: > > 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. >> >> >> """ >> > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > > --001a11c3bec0929ba304e07d9cea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Carlos,

Thank you very much for the rev= iew and suggested text. I like your suggestion and will incorporate it.

Regards,
KK


On Sun, Jun 30, 2013 at 11:37 AM, Carlos= Pignataro (cpignata) <cpignata@cisco.com> wrote:
KK, chairs, Joel,

The revised charter looks good to me.=A0

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&qu= ot;) I wonder if it could be fragmented or turned into a list. For example:=
"The working group documents security practices in the=A0forwarding, 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,

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

On Jun 30, 2013, at 1:11 PM, "KK" <kk@google.com> wrote:

Hey Folks,

Just a reminder, we'll be wrapping this up today.

Thanks,
KK


On Thu, Jun 13, 2013 at 10:59 AM, KK <kk@google.c= om> wrote:
Dear All,

The chairs in conjunction with our AD, Joel, recently worked on a draf= t revision to our charter text. The changes in this revision are mostly rel= ated to elaborating on the type of documents this WG produces along with so= me minor wordsmithing here and there.=A0

We would like to get you to review the text and provide comments. Plea= se have a read and voice an opinion one way or the other. If we don't h= ear any objections by June 30th, we'll assume you love it and proceed.<= /div>

Thanks,
KK, Gunter, Warren

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


**********

Proposed Revised OPSEC Charter:

"""

<= span style=3D"font-size:13px;font-family:Arial;vertical-align:baseline">Goa= ls:


<= span style=3D"font-size:13px;font-family:Arial;vertical-align:baseline">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 operation= al practice, address gaps in currently understood best practices for forwar= ding, control plane, and management plane security and clarify liabilities = inherent in security practices where they exist.


<= span style=3D"font-size:13px;font-family:Arial;vertical-align:baseline">Sco= pe:


<= span style=3D"font-size:13px;font-family:Arial;vertical-align:baseline">The= scope of the OPSEC WG is intended to include the protection and secure ope= ration of the forwarding, control and management planes. Documentation of operational issues, revision of existi= ng operational

<= span style=3D"font-size:13px;font-family:Arial;vertical-align:baseline">sec= urity practices documents and proposals for new approaches to operational c= hallenges related to network security are in scope.


<= span style=3D"font-size:13px;font-family:Arial;vertical-align:baseline">Met= hod:


<= span style=3D"font-size:13px;font-family:Arial;vertical-align:baseline">It = is expected that the product of the working group will result in the public= ation of informational or BCP RFCs. Taxonomy or problem statement documents may provide a basis for such documents.


<= span style=3D"font-size:13px;font-family:Arial;vertical-align:baseline">Inf= ormational or Best Current Practices Document


<= span style=3D"font-size:13px;font-family:Arial;vertical-align:baseline">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 doc= ument might convey:


<= span style=3D"font-size:13px;font-family:Arial;vertical-align:baseline">* 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

<= span style=3D"font-size:13px;font-family:Arial;vertical-align:baseline">* p= rotocols, tools and technologies extant at the time of writing that are use= d to address the threat

<= span style=3D"font-size:13px;font-family:Arial;vertical-align:baseline">* t= he possibility that a solution does not exist within existing tools or tech= nologies


<= span style=3D"font-size:13px;font-family:Arial;vertical-align:baseline">Tax= onomy and Problem Statement Documents


<= span style=3D"font-size:13px;font-family:Arial;vertical-align:baseline">A d= ocument which attempts to describe the scope of particular operational secu= rity challenge or problem space without necessarily coming to a conclusion or proposing a solution. Such a documen= t might

<= span style=3D"font-size:13px;font-family:Arial;vertical-align:baseline">be = a precursor to an informational or best current practices document.<= /p>

<= span style=3D"font-size:13px;font-family:Arial;vertical-align:baseline">Whi= le the principal input of the working group is operational experience and n= eeds, the output should be directed towards providing guidance to the operators community, other working groups that d= evelop

<= span style=3D"font-size:13px;font-family:Arial;vertical-align:baseline">pro= tocols or the community of protocol developers at large and implementers of= these protocols.


<= span style=3D"font-size:13px;font-family:Arial;vertical-align:baseline">Non= -Goals:


<= span style=3D"font-size:13px;font-family:Arial;vertical-align:baseline">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 tak= e on documents related to the practices of using such work.

<= br>

<= font face=3D"Arial">"""


_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

--001a11c3bec0929ba304e07d9cea-- From kkumar@google.com Mon Jul 1 18:56:57 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 D576B11E8362 for ; Mon, 1 Jul 2013 18:56:57 -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 nw+sWBh4TiIW for ; Mon, 1 Jul 2013 18:56:57 -0700 (PDT) Received: from mail-qe0-x230.google.com (mail-qe0-x230.google.com [IPv6:2607:f8b0:400d:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id D565911E835D for ; Mon, 1 Jul 2013 18:56:56 -0700 (PDT) Received: by mail-qe0-f48.google.com with SMTP id 2so2085456qea.35 for ; Mon, 01 Jul 2013 18:56:56 -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=VYePZ4w2YJAWBDWGnCF4062u9vkC2uDLdZq4xTyaBvA=; b=n5hsJs7cxFWgXvQfFHoiB6DfDdo+9HWEqaX3sNu8ci4UDT1Pck4MsLrieaHOyA+nRs rzr7fkR2U05AYT2MTZcoPEMCAGtr7UK63HSOnArmROE4emuE6ugBOIu4I8JGDhPOlt1+ WbZ2eHSjBsAxBvx9C6eBEbv1rhdrLwpyhWmIyRcUQJo0FVo96ORn3H5fHIuBM4TwEISQ 9ktcDCW62FANpY9/MI3wuSVhciwe59qRfjanPLqVLJt44o9eRft3BiKPWVlcAW+P6r92 c2aXlhPYPbyKRHaTyIntkPaOZ4eyGZgDe9rZJvMrpYCzQkaNSiQ/f7J9b8eJPIf9dJE3 XxVw== 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=VYePZ4w2YJAWBDWGnCF4062u9vkC2uDLdZq4xTyaBvA=; b=F0DKXM+9TJn+s1Lg6xsImGMVGud8/h1j1R7BlNfNtLisdcMXua8an1EAXpwJ9mb9OR RgLi4Exm6ZNIvyOsyqMhrvcdj+59MIh+YAyje5CbX0FTLykDn7TorcNVp21ZZlsxNlRw +DxH3NYJq+Du89QR32TKVLFD1nuJ1IJbL3i2vrIJ+IaL5VDb1pMtKmgC0VXr9cXOmFx2 ou6dtXrX8k+pdxBGAlVx5a/iVqdLc/dPRh0am8fapcoEd69xmz+FSj+xDvgW1wPKp0A1 81MIIca+gDdi6as+7JH85X8f2VMJ4vm06efA8Op+vaEqxYcvohgpLVBmLf8N8IgX40NJ z3xA== X-Received: by 10.49.37.225 with SMTP id b1mr35966254qek.24.1372730216209; Mon, 01 Jul 2013 18:56:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.52.148 with HTTP; Mon, 1 Jul 2013 18:56:36 -0700 (PDT) In-Reply-To: <51D0A61A.3040901@bogus.com> References: <51D0A61A.3040901@bogus.com> From: KK Date: Mon, 1 Jul 2013 18:56:36 -0700 Message-ID: To: joel jaeggli Content-Type: multipart/alternative; boundary=047d7bb03fd6e90e2c04e07da8e4 X-Gm-Message-State: ALoCoQliiQCuB9DiieGwDUO1XDbgGtSkQ5jOyxnLeI/0jCBN94zL6ahuQlmYYIkjy5zupu8Xf5wxoVeW6HFP39PwkpPQI6zqGEpgzN5HjLcXiy2ByNWiH6ZnAT1vttP1cDcjoiF2OX0ayM8OhKpJA0QFZ7jB89ejJmDwSQN51ToYjXJTx1d0Bsay5fhg2Sj4DbaTk4VyEm8H 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: Tue, 02 Jul 2013 01:56:57 -0000 --047d7bb03fd6e90e2c04e07da8e4 Content-Type: text/plain; charset=ISO-8859-1 Yes indeed, I think an update of the milestones is a bit overdue. We did one late last year, will work on getting updates in. On Sun, Jun 30, 2013 at 2:41 PM, joel jaeggli wrote: > On 6/30/13 10:11 AM, KK wrote: > >> Hey Folks, >> >> Just a reminder, we'll be wrapping this up today. >> >> this is a perhaps related question that is NOT tied to the charter text > which is are there milestone(s) which we should be adding associated with > particular areas of work that are ongoing (the nd security draft). > > joel > >> 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. >> >> >> """ >> >> >> > --047d7bb03fd6e90e2c04e07da8e4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes indeed, I think an update of the milestones is a bit o= verdue. We did one late last year, will work on getting updates in.


On Sun, Jun 30,= 2013 at 2:41 PM, joel jaeggli <joelja@bogus.com> wrote:
On 6/30/13 10:11 AM, KK wr= ote:
Hey Folks,

Just a reminder, we'll be wrapping this up today.

this is a perhaps related question that is =A0NOT tied to the charter text = which is are there milestone(s) which we should be =A0adding associated wit= h particular areas of work that are ongoing (the nd security draft).

joel
Thanks,
KK



On Thu, Jun 13, 2013 at 10:59 AM, KK <kk@google.com <mailto:kk@google.com>> wrote:

=A0 =A0 Dear All,

=A0 =A0 The chairs in conjunction with our AD, Joel, recently worked on a =A0 =A0 draft revision to our charter text. The changes in this revision =A0 =A0 are mostly related to elaborating on the type of documents this WG<= br> =A0 =A0 produces along with some minor wordsmithing here and there.

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

=A0 =A0 Thanks,
=A0 =A0 KK, Gunter, Warren

=A0 =A0 P.S. The current version of the charter can be found at
=A0 =A0 http://datatracker.ietf.org/wg/opsec/charter/


=A0 =A0 **********

=A0 =A0 Proposed Revised OPSEC Charter:

=A0 =A0 """

=A0 =A0 Goals:


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


=A0 =A0 Scope:


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

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

=A0 =A0 Method:


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


=A0 =A0 Informational or Best Current Practices Document


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


=A0 =A0 * a threat or threats to be addressed

=A0 =A0 * current practices for addressing the threat

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

=A0 =A0 * the possibility that a solution does not exist within existing =A0 =A0 tools or technologies


=A0 =A0 Taxonomy and Problem Statement Documents


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

=A0 =A0 be a precursor to an informational or best current practices docume= nt.


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

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


=A0 =A0 Non-Goals:


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


=A0 =A0 """




--047d7bb03fd6e90e2c04e07da8e4-- From warren@kumari.net Wed Jul 3 07:27:02 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 791B611E8181 for ; Wed, 3 Jul 2013 07:27:02 -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=[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 adqbx+SlddQn for ; Wed, 3 Jul 2013 07:26:57 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id A513C11E80BA for ; Wed, 3 Jul 2013 07:26:57 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.89]) by vimes.kumari.net (Postfix) with ESMTPSA id 871C11B41028; Wed, 3 Jul 2013 10:26:56 -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: <51A2A369-E6CF-49D9-8238-C063D6DDADDE@kumari.net> Date: Wed, 3 Jul 2013 10:26:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51C837D3.4010904@gmail.com> <95067C434CE250468B77282634C96ED322C81422@xmb-aln-x02.cisco.com> <51A2A369-E6CF-49D9-8238-C063D6DDADDE@kumari.net> 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: Wed, 03 Jul 2013 14:27:02 -0000 On Jun 24, 2013, at 4:12 PM, Warren Kumari wrote: >=20 > On Jun 24, 2013, at 10:28 AM, Carlos Pignataro (cpignata) = wrote: >=20 >> 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". >=20 > 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 >=20 >> 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 >=20 > 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]. >=20 >> and next steps (i.e., is the doc ready to be submitted to the IESG, = after we submit a -03 incorporating comments?) >=20 > 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. >=20 > Apologies for the delay.=20 >=20 > W >=20 > [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 Due to travel, etc Merike has been really busy, and the 4th of July is a = large holiday in the USA and so we are going to wait till Monday for her = review.=20 If she doesn't get a chance to submit it by then, we'll call consensus = without it=85=20 Honestly, we see strong consensus for advancing this, we just went to be = able to say, in good faith, that sufficient folk have reviewed the = document. W >=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 > --=20 > With Feudalism, it's your Count that votes. >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec >=20 -- "When it comes to glittering objects, wizards have all the taste and = self-control of a deranged magpie." -- Terry Pratchett From internet-drafts@ietf.org Wed Jul 3 10:25:34 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 83EF211E80F1; Wed, 3 Jul 2013 10:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.109, 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 ugUPLcXWyd1W; Wed, 3 Jul 2013 10:25:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E578111E81E8; Wed, 3 Jul 2013 10:25:25 -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: <20130703172525.3191.49037.idtracker@ietfa.amsl.com> Date: Wed, 03 Jul 2013 10:25:25 -0700 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-icmp-filtering-04.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: Wed, 03 Jul 2013 17:25:34 -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 : Recommendations for filtering ICMP messages Author(s) : Fernando Gont Guillermo Gont Carlos Pignataro Filename : draft-ietf-opsec-icmp-filtering-04.txt Pages : 58 Date : 2013-07-03 Abstract: This document document provides advice on the filtering of ICMPv4 and ICMPv6 messages. Additionaly, it discusses the operational and interoperability implications of such filtering. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-icmp-filtering There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-icmp-filtering-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-icmp-filtering-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From kkumar@google.com Wed Jul 3 10:39:16 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 6E26221F955A for ; Wed, 3 Jul 2013 10:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.075, 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 wQj0L01BZCkw for ; Wed, 3 Jul 2013 10:39:15 -0700 (PDT) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 162A521F8423 for ; Wed, 3 Jul 2013 10:39:14 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id a1so263773qcx.39 for ; Wed, 03 Jul 2013 10:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=vgC8UxJveb0FwR5VvX2RDXzUiKmY0I0TnVriRM4vrLI=; b=Ty1w7oMGvYAplUAePvWg6yQ6VVU/sKKIOCQAkNXnn4qgVU+0wyej4TJqWuV8HNmGYD Cr5OtE6fKCALR4cxoMT8ix+LobLXZYyH/uOnpacMUufpTiNbokNV8qyUNdCpza7I8lKR QgM4val9QuvpAea+YnIYwco0lRpEiE/Jhy3smWEYzzb6ochRJKM2GDD5eJQBQm2zXdma qDWK3GITe1K7CKuTH32lc5iXG2N8V4kmPyjF0jyWhpfzKyaDqWXNqFR+AM0vE4s8Uq+A lOpWNWD5VaRmfdJz8VcbHTBdIBirmQaPSeENgHmiuLI7C5FJSdfmUHaUHLg9GrXuuyCG ssig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=vgC8UxJveb0FwR5VvX2RDXzUiKmY0I0TnVriRM4vrLI=; b=W0nJaH7nrGGFdXvR6S8H78XiYWKUo6IdtEEiF8y79GIIriziUDAuErfaloJnsQPWuW TUIW+jKaVCW3ysI9y0FOWf5EQurgm3czEB1pHqmYHDJrZsJxAe5oB1X8VTA6b/fzKQ4G 1oJ1K4QNn/OY02bxOXEIv0GYRNnzPVmMAkvcRfduxfaDWP1YYTmuLZ090eUBv6PlW7T/ Y6BHpQOqHTlIX4Dpyg7MeorYp+lvkQ5ONNwVo0S9JcA2BgTFQ6QV8KFkNQcv+nGDZIJW Nz9Ys3Zoi7zD6OUGFoppZlq43xrp32AHzJqdEyslnKSGGyQjL4tmKhdKMrC3Xtb10JzJ i2lA== X-Received: by 10.229.198.2 with SMTP id em2mr632015qcb.96.1372873153482; Wed, 03 Jul 2013 10:39:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.41.238 with HTTP; Wed, 3 Jul 2013 10:38:51 -0700 (PDT) From: KK Date: Wed, 3 Jul 2013 10:38:51 -0700 Message-ID: To: "opsec@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2ee64a2af4504e09ef0b2 X-Gm-Message-State: ALoCoQlwWkr1rjAvyYqNGVGjEREkDXes6qjy7SZfM/cCm2W742S+Xaqu0jzN2+AwRqwosy5RpbyfGcdRZZb7unVPn5lIwWE+w5w/gukePmFb8gocrvR9NkVpxQn0xKjHo5gDhdOOm/+6+/6G6EBsesSO1E8gjYb38jRtuACIrvCCDb4FqnUbHoR7pRW/IFlfVp9PxY8nd+13 Subject: [OPSEC] OPSEC IETF 87 - Call for Agenda Items 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: Wed, 03 Jul 2013 17:39:16 -0000 --001a11c2ee64a2af4504e09ef0b2 Content-Type: text/plain; charset=ISO-8859-1 Dear All, If you have a draft you would like to discuss during IETF 87, please send your request for agenda time to the opsec chairs. Please include in the request, the title and file name of the draft, the speaker's name, and how much time you would need. We have one hour allocated to our session. We will prioritize drafts that are WG items, drafts that have been actively discussed on the list, and other individual submissions in that order. Please send in your agenda items to us by 16th July, 2013. An important date to note for document submission: 2013-07-15 (Monday): Internet Draft submission cut-off (for all drafts, including -00) by UTC 24:00 Regards, KK, Gunter, Warren --001a11c2ee64a2af4504e09ef0b2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Dear All,


If you have a draft you would like to discuss during IETF 87, please= send your request for agenda time to the opsec chairs. Please include in t= he request, the title and file name of the draft, the speaker's name, a= nd how much time you would need. We have one hour allocated to our session.=


We will prioritize drafts that are WG items, drafts that have been a= ctively discussed on the list, and other individual submissions in that ord= er.


Please send in your agenda items to us by 16th July, 2013. An import= ant date to note for document submission:


=A02013-07-15 (Monday): Internet Draft submission cut-off (for all = drafts, including -00) by UTC 24:00


Regards,

KK= , Gunter, Warren
--001a11c2ee64a2af4504e09ef0b2-- From warren@kumari.net Wed Jul 3 13:58:34 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 7F30E11E8245 for ; Wed, 3 Jul 2013 13:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 dF-4IDHOVrMz for ; Wed, 3 Jul 2013 13:58:29 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF11D11E8239 for ; Wed, 3 Jul 2013 13:58:26 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.89]) by vimes.kumari.net (Postfix) with ESMTPSA id E216D1B407D8; Wed, 3 Jul 2013 16:58:25 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Jul 2013 16:58:25 -0400 Message-Id: To: OpSec@ietf.org, draft-ietf-opsec-vpn-leakages@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: Warren Kumari Subject: [OPSEC] Start of WGLC for draft-ietf-opsec-vpn-leakages 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: Wed, 03 Jul 2013 20:58:34 -0000 Dear OpSec WG, This starts a Working Group Last Call for draft-ietf-opsec-vpn-leakages. The draft is available here: = https://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages/ The authors of draft-ietf-opsec-vpn-leakages have indicated that they = have incorporated feedback and believe that the document is ready for = WGLC.=20 It is the authors responsibility to drum up additional feedback and = review. Please review this draft to see if you think it is ready for publication and comments to the list, clearly stating your view. This WGLC ends Wed 17-Jul-2013. Helpful Notes:=20 draft-ietf-opsec-vpn-leakages was originally = draft-gont-opsec-vpn-leakages. There was some discussion in the thread: IPv6 implications on IPv4 nets: = IPv6 RAs, IPv4's VPN "leakage" and "New IETF I-D about VPN traffic leakages (Fwd: New Version = Notification for draft-gont-opsec-vpn-leakages-00.txt)" Thanks, Warren Kumari (as OpSec WG co-chair) --=20 Outside of a dog, a book is your best friend, and inside of a dog, it's = too dark to read=20 From warren@kumari.net Wed Jul 3 13:59:29 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 DE21321F995E for ; Wed, 3 Jul 2013 13:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 YUsmHyg9+uNL for ; Wed, 3 Jul 2013 13:59:25 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B3221F9962 for ; Wed, 3 Jul 2013 13:59:25 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.89]) by vimes.kumari.net (Postfix) with ESMTPSA id DC1A51B403E8; Wed, 3 Jul 2013 16:59:24 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Jul 2013 16:59:24 -0400 Message-Id: <39428D0A-18B6-4F94-B8E5-98A104C5F621@kumari.net> To: "OpSec@ietf.org" , "draft-ietf-opsec-vpn-leakages@tools.ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: Warren Kumari Subject: [OPSEC] Reminder about IPR relating to draft-ietf-opsec-vpn-leakages 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: Wed, 03 Jul 2013 20:59:30 -0000 Dear OpSec WG, Be not alarmed. This email was created to satisfy RFC 6702 "Promoting Compliance with = Intellectual Property Rights (IPR)" = (http://tools.ietf.org/rfc/rfc6702.txt). The authors of draft-ietf-opsec-vpn-leakages have asked for a Working = Group Last Call. Before issuing the Working Group Last Call, we would = like to check whether any claims of Intellectual Property Rights (IPR) = on the document have not yet been disclosed. Are you personally aware of any IPR that applies to = draft-ietf-opsec-vpn-leakages? If so, has this IPR been disclosed in = compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) If you are a document author or listed contributor on this document, = please reply to this email regardless of whether or not you are = personally aware of any relevant IPR. We might not be able to advance = this document to the next stage until we have received a reply from each = author and listed contributor. If you are on the OpSec WG email list but are not an author or listed = contributor for this document, you are reminded of your opportunity for = a voluntary IPR disclosure under BCP 79. Please do not reply unless you = want to make such a voluntary disclosure. Online tools for filing IPR disclosures can be found at = . Thanks, Warren Kumari (as OpSec WG co-chair) -- Curse the dark, or light a match. You decide, it's your dark. -- Valdis Kletnieks From ietf-secretariat-reply@ietf.org Wed Jul 3 14:08:05 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 E784D21F9C85 for ; Wed, 3 Jul 2013 14:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.063, 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 dE0bOS31W2GC for ; Wed, 3 Jul 2013 14:08:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D2C21F9CDC for ; Wed, 3 Jul 2013 14:08:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: opsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130703210805.8783.27780.idtracker@ietfa.amsl.com> Date: Wed, 03 Jul 2013 14:08:05 -0700 From: IETF Secretariat X-Mailman-Approved-At: Wed, 03 Jul 2013 14:11:22 -0700 Subject: [OPSEC] Milestones changed for opsec WG 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: Wed, 03 Jul 2013 21:08:06 -0000 Changed milestone "Complete Charter", set due date to September 2004 from September 2004. Changed milestone "First draft of Framework Document as Internet Draft", set due date to September 2004 from September 2004. Changed milestone "First draft of Standards Survey Document as Internet Draft", set due date to September 2004 from September 2004. Changed milestone "First draft of Packet Filtering Capabilities", set due date to October 2004 from October 2004. Changed milestone "First draft of Event Logging Capabilities", set due date to October 2004 from October 2004. Changed milestone "First draft of Network Operator Current Security Practices", set due date to November 2004 from November 2004. Changed milestone "First draft of In-Band management capabilities", set due date to January 2005 from January 2005. Changed milestone "First draft of Out-of-Band management capabilities", set due date to January 2005 from January 2005. Changed milestone "First draft of Configuration and Management Interface Capabilities", set due date to January 2005 from January 2005. Changed milestone "Submit Network Operator Current Security Practices to IESG", set due date to May 2005 from May 2005. Changed milestone "WG Adoption of 'BGP operations and security' document", set due date to December 2012 from December 2012. Changed milestone "WG Adoption of 'Network Reconnaissance in IPv6 Networks' document", set due date to December 2012 from December 2012. Changed milestone "WG Adoption of 'DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers' document", set due date to December 2012 from December 2012. Changed milestone "WG Adoption of 'Virtual Private Network (VPN) traffic leakages in dual-stack hosts/networks' document", set due date to December 2012 from December 2012. Changed milestone "WG Last Call for 'Operational Security Considerations for IPv6 Networks' document", set due date to January 2013 from January 2013. Changed milestone "WG Last Call for 'Recommendations for filtering ICMP messages' document", set due date to January 2013 from January 2013. Changed milestone "WG Last Call for 'Recommendations on filtering of IPv4 packets containing IPv4 options' document", set due date to January 2013 from January 2013. Changed milestone "WG Last Call for 'Security Implications of IPv6 on IPv4 networks' document", set due date to January 2013 from January 2013. Changed milestone "WG Last Call for 'Using Only Link-Local Addressing Inside an IPv6 Network' document", set due date to March 2013 from March 2013. Changed milestone "Submit 'Recommendations for filtering ICMP messages' document to IESG", set due date to March 2013 from March 2013. Changed milestone "Submit 'Recommendations on filtering of IPv4 packets containing IPv4 options' document to IESG", set due date to March 2013 from March 2013. Changed milestone "Submit 'Operational Security Considerations for IPv6 Networks' document to IESG", set due date to March 2013 from March 2013. Changed milestone "Submit 'Recommendations for filtering ICMP messages' document to IESG", set due date to March 2013 from March 2013. Changed milestone "Submit 'Using Only Link-Local Addressing Inside an IPv6 Network' document to IESG", set due date to May 2013 from May 2013. Changed milestone "WG Last Call for 'BGP operations and security' document", set due date to July 2013 from July 2013. Changed milestone "WG Last Call for 'Network Reconnaissance in IPv6 Networks' document", set due date to July 2013 from July 2013. Changed milestone "WG Last Call for 'DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers' document", set due date to July 2013 from July 2013. Changed milestone "WG Last Call for 'Virtual Private Network (VPN) traffic leakages in dual-stack hosts/networks' document", set due date to July 2013 from July 2013, added draft-ietf-opsec-vpn-leakages to milestone. Changed milestone "Submit 'Network Reconnaissance in IPv6 Networks' document to IESG", set due date to September 2013 from September 2013. Changed milestone "Submit 'DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers' document to IESG", set due date to September 2013 from September 2013. Changed milestone "Submit 'BGP operations and security' document to IESG", set due date to September 2013 from September 2013. URL: http://datatracker.ietf.org/wg/opsec/charter/ From warren@kumari.net Wed Jul 3 14:13:50 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 7E98211E825C for ; Wed, 3 Jul 2013 14:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.81 X-Spam-Level: X-Spam-Status: No, score=-101.81 tagged_above=-999 required=5 tests=[AWL=-0.746, BAYES_00=-2.599, FRT_STRONG2=1.535, 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 Pzle1d-QStgA for ; Wed, 3 Jul 2013 14:13:45 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEA211E8233 for ; Wed, 3 Jul 2013 14:13:45 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.89]) by vimes.kumari.net (Postfix) with ESMTPSA id B1D7E1B403E8; Wed, 3 Jul 2013 17:13:44 -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: <20130703210805.8783.27780.idtracker@ietfa.amsl.com> Date: Wed, 3 Jul 2013 17:13:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0CBD0459-3091-456C-82CF-3BD454F941C4@kumari.net> References: <20130703210805.8783.27780.idtracker@ietfa.amsl.com> To: "OpSec@ietf.org" X-Mailer: Apple Mail (2.1508) Cc: Warren Kumari Subject: Re: [OPSEC] Milestones changed for opsec WG 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: Wed, 03 Jul 2013 21:13:50 -0000 Sorry for the noise -- all I did was associate = 'draft-ietf-opsec-vpn-leakages' with milestone "WG Last Call for = 'Virtual Private Network (VPN) traffic leakages in dual-stack = hosts/networks' document" Don't know if this was because this was the first time we touched the = new Milestone thingie in the data tracker, or if it is a bug=85 W On Jul 3, 2013, at 5:08 PM, IETF Secretariat = wrote: > Changed milestone "Complete Charter", set due date to September 2004 > from September 2004. >=20 > Changed milestone "First draft of Framework Document as Internet > Draft", set due date to September 2004 from September 2004. >=20 > Changed milestone "First draft of Standards Survey Document as > Internet Draft", set due date to September 2004 from September 2004. >=20 > Changed milestone "First draft of Packet Filtering Capabilities", set > due date to October 2004 from October 2004. >=20 > Changed milestone "First draft of Event Logging Capabilities", set due > date to October 2004 from October 2004. >=20 > Changed milestone "First draft of Network Operator Current Security > Practices", set due date to November 2004 from November 2004. >=20 > Changed milestone "First draft of In-Band management capabilities", > set due date to January 2005 from January 2005. >=20 > Changed milestone "First draft of Out-of-Band management > capabilities", set due date to January 2005 from January 2005. >=20 > Changed milestone "First draft of Configuration and Management > Interface Capabilities", set due date to January 2005 from January > 2005. >=20 > Changed milestone "Submit Network Operator Current Security Practices > to IESG", set due date to May 2005 from May 2005. >=20 > Changed milestone "WG Adoption of 'BGP operations and security' > document", set due date to December 2012 from December 2012. >=20 > Changed milestone "WG Adoption of 'Network Reconnaissance in IPv6 > Networks' document", set due date to December 2012 from December 2012. >=20 > Changed milestone "WG Adoption of 'DHCPv6-Shield: Protecting Against > Rogue DHCPv6 Servers' document", set due date to December 2012 from > December 2012. >=20 > Changed milestone "WG Adoption of 'Virtual Private Network (VPN) > traffic leakages in dual-stack hosts/networks' document", set due date > to December 2012 from December 2012. >=20 > Changed milestone "WG Last Call for 'Operational Security > Considerations for IPv6 Networks' document", set due date to January > 2013 from January 2013. >=20 > Changed milestone "WG Last Call for 'Recommendations for filtering > ICMP messages' document", set due date to January 2013 from January > 2013. >=20 > Changed milestone "WG Last Call for 'Recommendations on filtering of > IPv4 packets containing IPv4 options' document", set due date to > January 2013 from January 2013. >=20 > Changed milestone "WG Last Call for 'Security Implications of IPv6 on > IPv4 networks' document", set due date to January 2013 from January > 2013. >=20 > Changed milestone "WG Last Call for 'Using Only Link-Local Addressing > Inside an IPv6 Network' document", set due date to March 2013 from > March 2013. >=20 > Changed milestone "Submit 'Recommendations for filtering ICMP > messages' document to IESG", set due date to March 2013 from March > 2013. >=20 > Changed milestone "Submit 'Recommendations on filtering of IPv4 > packets containing IPv4 options' document to IESG", set due date to > March 2013 from March 2013. >=20 > Changed milestone "Submit 'Operational Security Considerations for > IPv6 Networks' document to IESG", set due date to March 2013 from > March 2013. >=20 > Changed milestone "Submit 'Recommendations for filtering ICMP > messages' document to IESG", set due date to March 2013 from March > 2013. >=20 > Changed milestone "Submit 'Using Only Link-Local Addressing Inside an > IPv6 Network' document to IESG", set due date to May 2013 from May > 2013. >=20 > Changed milestone "WG Last Call for 'BGP operations and security' > document", set due date to July 2013 from July 2013. >=20 > Changed milestone "WG Last Call for 'Network Reconnaissance in IPv6 > Networks' document", set due date to July 2013 from July 2013. >=20 > Changed milestone "WG Last Call for 'DHCPv6-Shield: Protecting Against > Rogue DHCPv6 Servers' document", set due date to July 2013 from July > 2013. >=20 > Changed milestone "WG Last Call for 'Virtual Private Network (VPN) > traffic leakages in dual-stack hosts/networks' document", set due date > to July 2013 from July 2013, added draft-ietf-opsec-vpn-leakages to > milestone. >=20 > Changed milestone "Submit 'Network Reconnaissance in IPv6 Networks' > document to IESG", set due date to September 2013 from September 2013. >=20 > Changed milestone "Submit 'DHCPv6-Shield: Protecting Against Rogue > DHCPv6 Servers' document to IESG", set due date to September 2013 from > September 2013. >=20 > Changed milestone "Submit 'BGP operations and security' document to > IESG", set due date to September 2013 from September 2013. >=20 > URL: http://datatracker.ietf.org/wg/opsec/charter/ > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec >=20 -- There were such things as dwarf gods. Dwarfs were not a naturally = religious species, but in a world where pit props could crack without = warning and pockets of fire damp could suddenly explode they'd seen the = need for gods as the sort of supernatural equivalent of a hard hat. = Besides, when you hit your thumb with an eight-pound hammer it's nice to = be able to blaspheme. It takes a very special and straong-minded kind of = atheist to jump up and down with their hand clasped under their other = armpit and shout, "Oh, random-fluctuations-in-the-space-time-continuum!" = or "Aaargh, primitive-and-outmoded-concept on a crutch!" -- Terry Pratchett From fgont@si6networks.com Wed Jul 3 17:42:49 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 5660A11E80E6 for ; Wed, 3 Jul 2013 17:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 frHf+HeT-7Be for ; Wed, 3 Jul 2013 17:42:48 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id BA33611E80F3 for ; Wed, 3 Jul 2013 17:42:48 -0700 (PDT) Received: from [2001:5c0:1400:a::349] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UuXdE-0002xg-QQ; Thu, 04 Jul 2013 02:42:44 +0200 Message-ID: <51D4C503.4000309@si6networks.com> Date: Thu, 04 Jul 2013 02:42:43 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Warren Kumari References: <39428D0A-18B6-4F94-B8E5-98A104C5F621@kumari.net> In-Reply-To: <39428D0A-18B6-4F94-B8E5-98A104C5F621@kumari.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "OpSec@ietf.org" , "draft-ietf-opsec-vpn-leakages@tools.ietf.org" Subject: Re: [OPSEC] Reminder about IPR relating to draft-ietf-opsec-vpn-leakages 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: Thu, 04 Jul 2013 00:42:49 -0000 On 07/03/2013 10:59 PM, Warren Kumari wrote: > > Be not alarmed. :-) > Are you personally aware of any IPR that applies to > draft-ietf-opsec-vpn-leakages? No. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From internet-drafts@ietf.org Fri Jul 5 08:15:45 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 B697411E82BC; Fri, 5 Jul 2013 08:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.088, 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 03NrIS85kqX9; Fri, 5 Jul 2013 08:15:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 38CE921F9F89; Fri, 5 Jul 2013 08:15:42 -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: <20130705151542.16507.43536.idtracker@ietfa.amsl.com> Date: Fri, 05 Jul 2013 08:15:42 -0700 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-ipv6-implications-on-ipv4-nets-05.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: Fri, 05 Jul 2013 15:15:45 -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 : Security Implications of IPv6 on IPv4 Networks Author(s) : Fernando Gont Will (Shucheng) Liu Filename : draft-ietf-opsec-ipv6-implications-on-ipv4-nets-05.txt Pages : 23 Date : 2013-07-05 Abstract: This document discusses the security implications of native IPv6 support and IPv6 transition/co-existence technologies on "IPv4-only" networks, and describes possible mitigations for the aforementioned issues. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-implications-on-ipv4= -nets There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-ipv6-implications-on-ipv4-nets-= 05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-ipv6-implications-on-ip= v4-nets-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From merike@doubleshotsecurity.com Sat Jul 6 08:53:35 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 74C3821F9C0E for ; Sat, 6 Jul 2013 08:53:35 -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 KFpvJv7POA5F for ; Sat, 6 Jul 2013 08:53:29 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE6A21F9B60 for ; Sat, 6 Jul 2013 08:53:28 -0700 (PDT) Received: from webmail.sonic.net (a.webmail.sonic.net [69.12.221.241]) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id r66FrPU9024376; Sat, 6 Jul 2013 08:53:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Priority: Normal X-Mailer: AtMail PHP 5.62 Message-ID: <64347.1373126005@sonic.net> To: "Warren Kumari" , "Carlos Pignataro (cpignata)" X-Origin: 187.185.71.86 X-Atmail-Account: doubless@sonic.net Date: Sat, 06 Jul 2013 08:53:25 -0700 From: Merike Kaeo Cc: Warren Kumari , , Arturo Servin 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 Reply-To: merike@doubleshotsecurity.com List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 15:53:35 -0000 Hi.. I will send my comments to list right after this reply but have a comment o= n one of Arturo's comments. For readability I have gotten rid of everything except the one point I want= to make: > >>> Section 4.22.5 > >>>=20 > >>> The advice mentions "drop and log event" as the default. I wonder tha= t > >>> 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= =2E > >>>=20 > >>> Same for 4.23.4 about "Other IP options" and in general every time > that > >>> the document recommends "drop and logging". I'm a firm believer of logging exceptions (i.e. packets you are dropping) s= o that you see where these packets that you shouldn't be seeing are coming = from and can mitigate issue as needed. It's probably not a bad idea to hav= e a statement to say that excessive logging can be a DoS although I do hope= people would be monitoring and setting thresholds for abnormally high coun= ts and acting on that. [one can hope] :) - merike From merike@doubleshotsecurity.com Sat Jul 6 09:26:49 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 1892721F9C64 for ; Sat, 6 Jul 2013 09:26:49 -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 dNGe0Fq7MzYU for ; Sat, 6 Jul 2013 09:26:43 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id 4E47121F9C5D for ; Sat, 6 Jul 2013 09:26:43 -0700 (PDT) Received: from webmail.sonic.net (a.webmail.sonic.net [69.12.221.241]) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id r66GQgvj012512; Sat, 6 Jul 2013 09:26:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Priority: Normal X-Mailer: AtMail PHP 5.62 Message-ID: <64399.1373128002@sonic.net> To: "Warren Kumari" , X-Origin: 187.185.71.86 X-Atmail-Account: doubless@sonic.net Date: Sat, 06 Jul 2013 09:26:42 -0700 From: Merike Kaeo 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 Reply-To: merike@doubleshotsecurity.com List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 16:26:49 -0000 Overall it's a good document to explain what should be done with packets th= at use IP options. Some detailed comments follow. Introduction "We note that data seems to indicate that there is a current widespread pra= ctice of blocking IPv4 optioned packets"=E2=80=A6.. The reference [MEDINA] = is from a 2004 publication, is there anything more recent? If not, at leas= t don't state it's a 'current' study and just refer to it as a study. Sin= ce the tests in MEDINA encompassed "IP Record Route Option", "IP Timestamp = Option" and "IP OptionX" I'm not sure it's accurate to say that data seems = to indicate there's widespread practice unless there's other data to back i= t up. [perhaps if default in devices is to block specific options that's a = factor to be considered] The last two paragraphs give no definitive recommendation. Are you simply = giving advice on dropping packets on a per IP options basis or is that the = recommendation as a BCP?=20 4.3. LSRR option In 4.3.1 it states that some ISPs peering agreements require support for LS= RR option - I am a bit surprised at this since most routers since mid-90's = have had source routing off by default. Was it just strict source routing = that's off by default or did that apply to both LSRR and SSRR?=20 Ping and trace route do NOT always break which is not clear in section 4.3= =2E4. If UDP/ICMP is used there is no problem right? Only with TCP and us= ing IP options. Might explicitly want to state that for clarity to reader(= s). I'd also explicitly state that most routers since late 1990's have had sour= ce routing off by default. [caveat - may differentiate between LSRR vs SSRR= if not same] 4.4 Most routers since late 1990's have had source routing off by default = so may want to state that [same caveat as above relating to LSRR vs SSRR] 4.12.2 If you are including vendor behavior, it would be useful to include= at least 2 vendors' behavior ( For example Juniper or Alcatel-Lucent route= rs or some "Layer 3 switch" device). If no other router or layer 3 switch = supports this option, state that. 4.13.2 Same comment as for 4.12. 6. Security Considerations At least half of the IP options discussed seem to be deprecated and do not = appear to have any operational impact if dropped. So rather than state tha= t "dropping packets containing IP options can cause real operational proble= ms in deployed networks" I'd restate to something like "Many of the IP opti= ons listed in this document are deprecated and cause no operational impact = if dropped. However, dropping packets containing IP options that are in us= e can cause real operational problems in deployed networks." And leave the last sentence as is. For all the IP options that have been formerly deprecated in RFC 6814, why = are they listed as SHOULD be dropped and not MUST? Especially if the opera= tional and interoperability impact if blocked is None?!? That about covers it from my review. - merike From cpignata@cisco.com Sat Jul 6 10:04:09 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 0F0D921F9C93 for ; Sat, 6 Jul 2013 10:04:09 -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 DCi1XSfDwKXy for ; Sat, 6 Jul 2013 10:04:03 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1E521F9C7C for ; Sat, 6 Jul 2013 10:04:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1527; q=dns/txt; s=iport; t=1373130243; x=1374339843; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=C1dpeFOOKj1cILpf3pxaLsA0QXRKSX9DVR/IhstxrRo=; b=VYodjMZC1nEw3umlpk+fqX33yINZuFZENtgHIXoXbnJzdKnbdhwPepM5 jLEBnyRQs4LWzJJXh+EsBesYfmIOv1r1OHmwK22JKHa2RgO8+xopfc36/ 3arLDUJGEwDvXcEP/rlgww3hcVmOiHVlhxzV5nQLDpbed9grirmtvLR30 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFACtN2FGtJXG//2dsb2JhbABagwnBWoEAFnSCIwEBAQMBOj8FCwIBCDYQMiUCBA4FiAkGuFyPODMHg28Dl1SRSIMR X-IronPort-AV: E=Sophos;i="4.87,1010,1363132800"; d="scan'208";a="228643798" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 06 Jul 2013 17:04:03 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r66H42uf020293 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 6 Jul 2013 17:04:02 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.116]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Sat, 6 Jul 2013 12:04:02 -0500 From: "Carlos Pignataro (cpignata)" To: "" Thread-Topic: [OPSEC] Review of: draft-ietf-opsec-ip-options-filtering-02 Thread-Index: AQHOemDyu4UDPw83oEGNf2neu7CvGJlX4N4C Date: Sat, 6 Jul 2013 17:04:01 +0000 Message-ID: References: <64347.1373126005@sonic.net> In-Reply-To: <64347.1373126005@sonic.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 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: Sat, 06 Jul 2013 17:04:09 -0000 Merike, Please see inline.=20 Thumb typed by Carlos Pignataro. Excuze typofraphicak errows On Jul 6, 2013, at 11:53 AM, "Merike Kaeo" = wrote: > Hi.. >=20 > I will send my comments to list right after this reply but have a comment= on one of Arturo's comments. > For readability I have gotten rid of everything except the one point I wa= nt to make: >=20 >=20 >>>>> Section 4.22.5 >>>>>=20 >>>>> The advice mentions "drop and log event" as the default. I wonder tha= t >>>>> 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 > I'm a firm believer of logging exceptions (i.e. packets you are dropping)= so that you see where these packets that you shouldn't be seeing are comin= g from and can mitigate issue as needed. It's probably not a bad idea to h= ave a statement to say that excessive logging can be a DoS although I do ho= pe people would be monitoring and setting thresholds for abnormally high co= unts and acting on that. [one can hope] :) >=20 Thanks. There is a difference between counting drops and logging drops. We = will take care of this in the next rev.=20 Thanks, > - merike >=20 Carlos. = From cpignata@cisco.com Sun Jul 7 13:02:36 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 7D13911E8100 for ; Sun, 7 Jul 2013 13:02:36 -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 SA8c3J68FAeY for ; Sun, 7 Jul 2013 13:02:32 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id E297E11E80F1 for ; Sun, 7 Jul 2013 13:02:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4899; q=dns/txt; s=iport; t=1373227352; x=1374436952; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ModDe8XBBMC6lS/3NetrZC69N8ujeK9/kaA4MzowdDA=; b=IKOWtv6xpNug4+akHNMTnPuIb728txOafyvQbAozlON0FvGrVUw2s6SH pxWLpVGj2qsvRmNzkJbYG2dEgGsNCGi3Es+srUImvBzx2Bv/R5j/x/hl0 Li3ioBB4EJf5MRf+ADNdumGiEZ5SGYwdwOapE7F03DVnKo0GOnKI42XO8 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFANzI2VGtJV2c/2dsb2JhbABagwkySsBggQgWdIIjAQEBAQIBAQEBawsFCwIBCCIkJwslAgQOBQgBiAAGDLdyjjl/AjECBYMGaQOpG4MRgXE3 X-IronPort-AV: E=Sophos;i="4.87,1015,1363132800"; d="scan'208";a="231838284" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 07 Jul 2013 20:02:31 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r67K2VHY025371 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 7 Jul 2013 20:02:31 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.116]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Sun, 7 Jul 2013 15:02:30 -0500 From: "Carlos Pignataro (cpignata)" To: "" Thread-Topic: [OPSEC] Review of: draft-ietf-opsec-ip-options-filtering-02 Thread-Index: AQHOemWZu4UDPw83oEGNf2neu7CvGJlZ+NeA Date: Sun, 7 Jul 2013 20:02:30 +0000 Message-ID: <95067C434CE250468B77282634C96ED322CC15C5@xmb-aln-x02.cisco.com> References: <64399.1373128002@sonic.net> In-Reply-To: <64399.1373128002@sonic.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.55] Content-Type: text/plain; charset="Windows-1252" Content-ID: <9A734ADF7E883240A9DBC25AC0435C20@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , 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: Sun, 07 Jul 2013 20:02:36 -0000 Merike, Thanks for the review, please see inline. On Jul 6, 2013, at 12:26 PM, Merike Kaeo wr= ote: >=20 > Overall it's a good document to explain what should be done with packets = that use IP options. Thanks. > Some detailed comments follow. >=20 >=20 > Introduction > "We note that data seems to indicate that there is a current widespread p= ractice of blocking IPv4 optioned packets"=85.. The reference [MEDINA] is f= rom a 2004 publication, is there anything more recent? If not, at least do= n't state it's a 'current' study and just refer to it as a study. Since t= he tests in MEDINA encompassed "IP Record Route Option", "IP Timestamp Opti= on" and "IP OptionX" I'm not sure it's accurate to say that data seems to i= ndicate there's widespread practice unless there's other data to back it up= . [perhaps if default in devices is to block specific options that's a fact= or to be considered] The fact that nobody "invested" the time in writing another paper on the st= udy of the practice of blocking IPv4 optioned packets is probably, more tha= n anything else, an indication that the situation has not changed... not to= o much value in re-writing the same conclusions every few years. There are = fairly common informal tests about it, that support the paper. If it helps I can also add a pointer to http://www.eecs.berkeley.edu/Pubs/T= echRpts/2005/EECS-2005-24.html, "IP Options are not an option", from Dec 20= 05, but again, informal tests show this has not changed. See for example Dan Wing's http://www.ietf.org/mail-archive/web/int-area/cu= rrent/msg02360.html. I also used Dan's scripts in a cron job testing top Al= exa sites for some time, same result. >=20 > The last two paragraphs give no definitive recommendation. Are you simpl= y giving advice on dropping packets on a per IP options basis or is that th= e recommendation as a BCP?=20 This is still the Introduction to the document. >=20 > 4.3. LSRR option > In 4.3.1 it states that some ISPs peering agreements require support for = LSRR option - I am a bit surprised at this since most routers since mid-90'= s have had source routing off by default. Was it just strict source routin= g that's off by default or did that apply to both LSRR and SSRR?=20 >=20 I am not sure, but having "support" for an option is orthogonal to its defa= ult setting. > Ping and trace route do NOT always break which is not clear in section 4.= 3.4. If UDP/ICMP is used there is no problem right? Only with TCP and usi= ng IP options. Might explicitly want to state that for clarity to reader(s= ). >=20 This is a good point and the text is not clear. I will fix this. > I'd also explicitly state that most routers since late 1990's have had so= urce routing off by default. [caveat - may differentiate between LSRR vs SS= RR if not same] >=20 Do you have citable source for this? I am not comfortable talking about "mo= st" without some solid reference. >=20 > 4.4 Most routers since late 1990's have had source routing off by defaul= t so may want to state that [same caveat as above relating to LSRR vs SSRR] >=20 > 4.12.2 If you are including vendor behavior, it would be useful to inclu= de at least 2 vendors' behavior ( For example Juniper or Alcatel-Lucent rou= ters or some "Layer 3 switch" device). If no other router or layer 3 switc= h supports this option, state that. >=20 Removed the Cisco references on 4.12.2 and 4.13.2 from a previous review. > 4.13.2 Same comment as for 4.12. Ditto. >=20 > 6. Security Considerations > At least half of the IP options discussed seem to be deprecated and do no= t appear to have any operational impact if dropped. So rather than state t= hat "dropping packets containing IP options can cause real operational prob= lems in deployed networks" I'd restate to something like "Many of the IP op= tions listed in this document are deprecated and cause no operational impac= t if dropped. However, dropping packets containing IP options that are in = use can cause real operational problems in deployed networks." >=20 > And leave the last sentence as is. >=20 OK, I'll rework this piece a bit. >=20 > For all the IP options that have been formerly deprecated in RFC 6814, wh= y are they listed as SHOULD be dropped and not MUST? Especially if the ope= rational and interoperability impact if blocked is None?!? >=20 >=20 I am very judicious with MUST statements and shy away a bit unless there is= harm. But certainly we can MUST this one if it is the WG's view. > That about covers it from my review. >=20 Thanks again. Carlos. > - merike >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From cb.list6@gmail.com Sun Jul 7 13:36:01 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 671ED21F9301 for ; Sun, 7 Jul 2013 13:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, 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 f6cynvHF2r4k for ; Sun, 7 Jul 2013 13:36:01 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id ACF5821F926E for ; Sun, 7 Jul 2013 13:36:00 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id n57so3178228wev.0 for ; Sun, 07 Jul 2013 13:35:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U5C+RCVtdQ4IZk5g2gVxJ2BMGeE1QjEsJ5Ev7xpPssM=; b=TTpD7D1YOGW1lTOSpBs0xXSQKOEacSr9usuPgZ2jY2Ua3hoMe7u4ke5F7Y/KdcOr4n Ssz+xK4ch5+lGcAOdoljSIrI0sPE7ibzUyEtADpRfNf9jiHLgQKb9/cWSaE80KGg+Q3P WBua9Gv0C77b7cupBbnWmTWTf559xhHw7z3gQIfvabwU+K429xksya9BRRQ6S7ClSAdO tsVIPACRsFevVMInQ4/DfxD3xaVaCDgLcOX6CEU3VkDIL/XZLQt0KBzssipnZbst38kv oNXyzVwUrfRTMue6UUSP5WYzDedavFwxMxZXlmiB3VGICZegEAvpV4YlztGrmwJDmxl3 joAA== MIME-Version: 1.0 X-Received: by 10.180.83.68 with SMTP id o4mr28046482wiy.5.1373229359774; Sun, 07 Jul 2013 13:35:59 -0700 (PDT) Received: by 10.194.139.208 with HTTP; Sun, 7 Jul 2013 13:35:59 -0700 (PDT) In-Reply-To: References: Date: Sun, 7 Jul 2013 13:35:59 -0700 Message-ID: From: "cb.list6" To: Warren Kumari Content-Type: text/plain; charset=ISO-8859-1 Cc: "opsec@ietf.org" , draft-ietf-opsec-vpn-leakages@tools.ietf.org Subject: Re: [OPSEC] Start of WGLC for draft-ietf-opsec-vpn-leakages 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, 07 Jul 2013 20:36:01 -0000 I support publication of this draft. I recently ran into this leaking issue on Android with OpenVPN. An open OpenVPN server used for security and anonymity only inserted routes for IPv4 on the client, with the result being all IPv6 does not go through the VPN. Many naive users will assume all traffic goes via the VPN, but in fact only a subset of IPv4-only traffic will go via the VPN while all ipv6 traffic travels outside the VPN CB On Wed, Jul 3, 2013 at 1:58 PM, Warren Kumari wrote: > Dear OpSec WG, > > This starts a Working Group Last Call for draft-ietf-opsec-vpn-leakages. > > The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages/ > > The authors of draft-ietf-opsec-vpn-leakages have indicated that they have incorporated feedback and believe that the document is ready for WGLC. > It is the authors responsibility to drum up additional feedback and review. > > Please review this draft to see if you think it is ready for publication > and comments to the list, clearly stating your view. > > This WGLC ends Wed 17-Jul-2013. > > > > Helpful Notes: > draft-ietf-opsec-vpn-leakages was originally draft-gont-opsec-vpn-leakages. > > There was some discussion in the thread: IPv6 implications on IPv4 nets: IPv6 RAs, IPv4's VPN "leakage" > and "New IETF I-D about VPN traffic leakages (Fwd: New Version Notification for draft-gont-opsec-vpn-leakages-00.txt)" > > > Thanks, > Warren Kumari > (as OpSec WG co-chair) > > > -- > Outside of a dog, a book is your best friend, and inside of a dog, it's too dark to read > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From merike@doubleshotsecurity.com Sun Jul 7 14:43:39 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 DEE6911E8139 for ; Sun, 7 Jul 2013 14:43:35 -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 QvQV-kd9LWMA for ; Sun, 7 Jul 2013 14:43:22 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id 80D0711E8132 for ; Sun, 7 Jul 2013 14:43:22 -0700 (PDT) Received: from webmail.sonic.net (c.webmail.sonic.net [69.12.221.242]) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id r67LhKC1016705; Sun, 7 Jul 2013 14:43:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Priority: Normal X-Mailer: AtMail PHP 5.62 Message-ID: <54988.1373233400@sonic.net> To: "Carlos Pignataro (cpignata)" , "" X-Origin: 187.185.71.86 X-Atmail-Account: doubless@sonic.net Date: Sun, 07 Jul 2013 14:43:20 -0700 From: Merike Kaeo Cc: opsec@ietf.org, 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 Reply-To: merike@doubleshotsecurity.com List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 21:43:39 -0000 Inline... On Sun 07/07/13 1:02 PM , "Carlos Pignataro (cpignata)" wrote: > Merike, >=20 > Thanks for the review, please see inline. >=20 > On Jul 6, 2013, at 12:26 PM, Merike Kaeo wrote: >=20 > >=20 > > Overall it's a good document to explain what should be done with packet= s > that use IP options. >=20 > Thanks. >=20 > > Some detailed comments follow. > >=20 > >=20 > > Introduction > > "We note that data seems to indicate that there is a current widespread > practice of blocking IPv4 optioned packets"=E2=80=A6.. The reference [MED= INA] is > from a 2004 publication, is there anything more recent? If not, at least > don't state it's a 'current' study and just refer to it as a study. Since > the tests in MEDINA encompassed "IP Record Route Option", "IP Timestamp > Option" and "IP OptionX" I'm not sure it's accurate to say that data seem= s > to indicate there's widespread practice unless there's other data to back > it up. [perhaps if default in devices is to block specific options that's= a > factor to be considered] >=20 > The fact that nobody "invested" the time in writing another paper on the > study of the practice of blocking IPv4 optioned packets is probably, more > than anything else, an indication that the situation has not changed... n= ot > too much value in re-writing the same conclusions every few years. There > are fairly common informal tests about it, that support the paper. If it's commonly known, OK. I wasn't aware. =20 =20 > If it helps I can also add a pointer to > http://www.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-2005-24.html, [1] "I= P > Options are not an option", from Dec 2005, but again, informal tests show > this has not changed. Just want to make sure reader knows that informal tests exist :) Else they= just take something at face value but I guess that's OK too as long as the documented is vetted and enough pe= ople know about the informal tests and agree with them. > See for example Dan Wing's > http://www.ietf.org/mail-archive/web/int-area/current/msg02360.html. [2] = I > also used Dan's scripts in a cron job testing top Alexa sites for some > time, same result. >=20 > >=20 > > The last two paragraphs give no definitive recommendation. Are you > simply giving advice on dropping packets on a per IP options basis or is > that the recommendation as a BCP?=20 >=20 > This is still the Introduction to the document. >=20 > >=20 > > 4.3. LSRR option > > In 4.3.1 it states that some ISPs peering agreements require support fo= r > LSRR option - I am a bit surprised at this since most routers since > mid-90's have had source routing off by default. Was it just strict sourc= e > routing that's off by default or did that apply to both LSRR and SSRR?=20 > >=20 >=20 > I am not sure, but having "support" for an option is orthogonal to its > default setting. Agreed. Was just wondering. =20 > > Ping and trace route do NOT always break which is not clear in section > 4.3.4. If UDP/ICMP is used there is no problem right? Only with TCP and > using IP options. Might explicitly want to state that for clarity to > reader(s). > >=20 >=20 > This is a good point and the text is not clear. I will fix this. >=20 > > I'd also explicitly state that most routers since late 1990's have had > source routing off by default. [caveat - may differentiate between LSRR v= s > SSRR if not same] > >=20 >=20 > Do you have citable source for this? I am not comfortable talking about > "most" without some solid reference. No, I'd have to hunt down the config guidelines. I do remember cisco chang= ing their defaults although don't know off-hand the IOS rev. And I am fairly certain Juniper also ship= ped with it not enabled. The problem was publicized widely around 1999...here's a reference that des= cribes it http://www.rapid7.com/vulndb/lookup/generic-ip-source-routing-enabled Maybe useful to say that "The security concerns with source routing have be= en known since 1999 and many recommendations have since then existed to disable source routing". But I'm not vetted to = this. Do what you think is best. >=20 > >=20 > > 4.4 Most routers since late 1990's have had source routing off by > default so may want to state that [same caveat as above relating to LSRR = vs > SSRR] > >=20 > > 4.12.2 If you are including vendor behavior, it would be useful to > include at least 2 vendors' behavior ( For example Juniper or > Alcatel-Lucent routers or some "Layer 3 switch" device). If no other rout= er > or layer 3 switch supports this option, state that. > >=20 >=20 > Removed the Cisco references on 4.12.2 and 4.13.2 from a previous review= =2E >=20 > > 4.13.2 Same comment as for 4.12. >=20 > Ditto. >=20 > >=20 > > 6. Security Considerations > > At least half of the IP options discussed seem to be deprecated and do > not appear to have any operational impact if dropped. So rather than stat= e > that "dropping packets containing IP options can cause real operational > problems in deployed networks" I'd restate to something like "Many of the > IP options listed in this document are deprecated and cause no operationa= l > impact if dropped. However, dropping packets containing IP options that a= re > in use can cause real operational problems in deployed networks." > >=20 > > And leave the last sentence as is. > >=20 >=20 > OK, I'll rework this piece a bit. >=20 > >=20 > > For all the IP options that have been formerly deprecated in RFC 6814, > why are they listed as SHOULD be dropped and not MUST? Especially if the > operational and interoperability impact if blocked is None?!? > >=20 > >=20 >=20 > I am very judicious with MUST statements and shy away a bit unless there > is harm. But certainly we can MUST this one if it is the WG's view. But that's the point isn't it, that these particular IP options DO cause ha= rm and are NOT needed? At=20 least the ones that are listed as SHOULD drop? From my read in the documen= t all of those are specifically listed as having NONE as operational and interoperability impa= ct. I defer to working group consensus here. =20 >=20 > > That about covers it from my review. > >=20 >=20 > Thanks again. Happy to review. Will read your updated doc next but wanted to at least co= mment to this email. You are expedient in your updates :) - merike >=20 > Carlos. >=20 > > - merike > >=20 > >=20 > > _______________________________________________ > > OPSEC mailing list > > OPSEC@ietf.org > > https://www.ietf.org/mailman/listinfo/opsec [3] >=20 >=20 >=20 > Links: > ------ > [1] > http://webmail.sonic.net/parse.php?redirect=3Dhttp://www.eecs.berkeley.ed= u/Pu > bs/TechRpts/2005/EECS-2005-24.html%2C[2] > http://webmail.sonic.net/parse.php?redirect=3Dhttp://www.ietf.org/mail-ar= chiv > e/web/int-area/current/msg02360.html.[3] > http://webmail.sonic.net/parse.php?redirect=3Dhttps://www.ietf.org/mailma= n/li > stinfo/opsec >=20 From rja.lists@gmail.com Mon Jul 8 06:04:24 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 E1C8821F9A87 for ; Mon, 8 Jul 2013 06:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MILLIONSOF=0.315] 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 Y3KIPTjFlDob for ; Mon, 8 Jul 2013 06:04:17 -0700 (PDT) Received: from mail-qe0-x235.google.com (mail-qe0-x235.google.com [IPv6:2607:f8b0:400d:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 04AFB21F9A83 for ; Mon, 8 Jul 2013 06:04:16 -0700 (PDT) Received: by mail-qe0-f53.google.com with SMTP id 1so2235243qee.26 for ; Mon, 08 Jul 2013 06:04:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=NCVFVEXjTEwyoWaz71EBWpbKHzWb5rX+p+wxdYXOxBw=; b=BmkXj1BRAldSijwpm6yYnJnfpU9qIggJXZCYfsibBFn9GUaaslBCswBm7YjoevJ/gE RUZ97pYZYNVcPQF/s2vzF4Jth8jIwIdDr4BlpWi3oW0H7v8LlEjhmPfd2G4k1zGUQLAE 69J85624aYZs0c9JGZOY1aoteNyX9Skl119gRCWjwPcjI2EltG2SvSz1sjG/MU32ahNi NxzmzOebwGVCfmrJRJwLVgvmuIqZRFVUe6cygYzvBoAngpgIERC+FZuY0JFzlj06nIE5 YL1u5AOZPB4WTeV2uTQRFJJvdJM2cjxquUR0EKhjyHLGifnPgek7ynXqISYcPmLHnjW3 Uemg== X-Received: by 10.49.130.8 with SMTP id oa8mr15935751qeb.87.1373288656472; Mon, 08 Jul 2013 06:04:16 -0700 (PDT) Received: from [10.30.20.12] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPSA id l4sm14016652qay.0.2013.07.08.06.04.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Jul 2013 06:04:15 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 8 Jul 2013 09:04:14 -0400 Message-Id: To: opsec@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) 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, 08 Jul 2013 13:04:24 -0000 All, * I object to the removal of the references to the Cisco support for IPSO processing. I observe that the comments made recently on the OPSEC list suggested edits, and also expressed confusion about the purpose of the existing text, but did not demand entire removal of that text. * I am VERY open to editing of text in some way, to clarify its purpose or such like, but the total removal of that text and reference is problematic because it creates confusion that is easily avoided by having such text. Those references were added in direct response to an earlier comment erroneously claiming those options never had been supported in routers. So there has been confusion in the modern world about whether those options are only supported in end systems or whether they also are supported in routers. One commenter refused to believe that cisco supported IPSO, which is why the specific reference to a (relatively) recent Cisco IOS web page was included in the draft. Removing that text or reference will create the incorrect impression that IPSO is an end-system-only option, when actually deployed networks using IPSO consider the router policing based on that option to be an important design feature. The recently deleted text (e.g. from 4.12.2) clarified that actually millions of deployed routers do support the IPSO and had the specific reference to the cisco website both to support the technical claim that the option is supported and also to satisfy the doubters. In fact, there are other IP routers that support that option, although they are part of MLS IP router implementations that are less commonly used in the public global Internet than either Cisco or Juniper. The products that I am thinking of don't seem to have a public URL describing their features, probably because they don't need one. The IPSO is probably more widely deployed today than it was in 2000 or 1990, but it is a specialised option that is rarely seen on the public global Internet. It also appears to have much broader geographic spread in its deployment today versus back in 2000. The lack of such an option was an issue for IPv6 deployment, leading fairly directly to the creation of RFC-5570 (CALIPSO). As the more recent RFC-5570 observes, however, those private IP networks commonly are built almost entirely using commercial (and open-source) products -- for hosts, firewalls, NATs, routers, and so on. As an example, Trusted Solaris and Trusted Linux might be present both as hosts and (in separate hardware instances) also as MLS IPSO-enforcing routers. To repeat my bottom line, I'm happy to discuss edits to those chunks of text, but deleting them entirely will create confusion about the implementation status and deployed uses of the IPSO option(s). Yours, Ran Atkinson From arturo.servin@gmail.com Mon Jul 8 06:41:36 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 2FB1121F9ACD for ; Mon, 8 Jul 2013 06:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] 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 rt15ySMrS8bb for ; Mon, 8 Jul 2013 06:41:34 -0700 (PDT) Received: from mail-ye0-x22c.google.com (mail-ye0-x22c.google.com [IPv6:2607:f8b0:4002:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAA321F9AC8 for ; Mon, 8 Jul 2013 06:41:33 -0700 (PDT) Received: by mail-ye0-f172.google.com with SMTP id l14so1640573yen.31 for ; Mon, 08 Jul 2013 06:41:32 -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:references :in-reply-to:content-type:content-transfer-encoding; bh=K1wIR2+pYXM3mVY0c20WzI/fUumFm6H3G9hxjGt8nng=; b=myb9joI8x1PP9mqTEwlS9YQPnePuoV6GEmECzXq02zgaRK2XDiAJnbp4T8SRs3vn4f zOxv9qndkclB1lQg7uuAQNhP4g4Xm30GYyZynMlpA+rWyV3qPX4M6Zopy+vO97bQvFEj 3+QWaVKRp3nvbm+G9t7KRtO3nCQfNuhRN/lDUzZfw6G0yhZXcVaGVTblzKukkXIG3g9G 7rexsUx3pB8xyVbvXmzV6C4nfx+UmUlknGfrxZw0uotxKROJebqAnQOxvRGjVRRL4M7s wz5gmUuX0MyW8SMRQylT376dCYW4PJKYbiRZI5AL7kyfEy/nwcYEnbOwaChmeE18JoPT K8mw== X-Received: by 10.236.91.68 with SMTP id g44mr12007704yhf.167.1373290892513; Mon, 08 Jul 2013 06:41:32 -0700 (PDT) Received: from Arturos-MacBook-Pro.local ([200.7.87.33]) by mx.google.com with ESMTPSA id l67sm37117927yhc.26.2013.07.08.06.41.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Jul 2013 06:41:31 -0700 (PDT) Message-ID: <51DAC18A.5030701@gmail.com> Date: Mon, 08 Jul 2013 10:41:30 -0300 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: opsec@ietf.org, rja.lists@gmail.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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, 08 Jul 2013 13:41:36 -0000 Ran, I think it was me that made the comment. To me the text didn't make to much sense when I read it. Now that you explained in more detail why it is included I understand the rationale. I do mind to put it back as it seems reasonable to do so. If there were a way to explain why the text is there in a few words it would be great. Cheers, as On 7/8/13 10:04 AM, RJ Atkinson wrote: > All, > > * I object to the removal of the references to the Cisco > support for IPSO processing. I observe that the comments > made recently on the OPSEC list suggested edits, and also > expressed confusion about the purpose of the existing text, > but did not demand entire removal of that text. > > * I am VERY open to editing of text in some way, to clarify > its purpose or such like, but the total removal of that > text and reference is problematic because it creates > confusion that is easily avoided by having such text. > > > Those references were added in direct response to an > earlier comment erroneously claiming those options never > had been supported in routers. So there has been confusion > in the modern world about whether those options are only > supported in end systems or whether they also are supported > in routers. One commenter refused to believe that cisco > supported IPSO, which is why the specific reference to > a (relatively) recent Cisco IOS web page was included > in the draft. > > > Removing that text or reference will create the incorrect > impression that IPSO is an end-system-only option, when > actually deployed networks using IPSO consider the router > policing based on that option to be an important design > feature. > > > The recently deleted text (e.g. from 4.12.2) clarified that > actually millions of deployed routers do support the IPSO and > had the specific reference to the cisco website both to support > the technical claim that the option is supported and also > to satisfy the doubters. > > > In fact, there are other IP routers that support that > option, although they are part of MLS IP router implementations > that are less commonly used in the public global Internet > than either Cisco or Juniper. The products that I am thinking > of don't seem to have a public URL describing their features, > probably because they don't need one. The IPSO is probably > more widely deployed today than it was in 2000 or 1990, > but it is a specialised option that is rarely seen on the > public global Internet. It also appears to have much broader > geographic spread in its deployment today versus back in 2000. > > The lack of such an option was an issue for IPv6 deployment, > leading fairly directly to the creation of RFC-5570 (CALIPSO). > > As the more recent RFC-5570 observes, however, those private > IP networks commonly are built almost entirely using commercial > (and open-source) products -- for hosts, firewalls, NATs, routers, > and so on. As an example, Trusted Solaris and Trusted Linux > might be present both as hosts and (in separate hardware instances) > also as MLS IPSO-enforcing routers. > > > To repeat my bottom line, I'm happy to discuss edits to those > chunks of text, but deleting them entirely will create confusion > about the implementation status and deployed uses of the IPSO > option(s). > > > Yours, > > Ran Atkinson > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From merike@doubleshotsecurity.com Mon Jul 8 07:49:41 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 56F1D21F9CE7 for ; Mon, 8 Jul 2013 07:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.442 X-Spam-Level: X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] 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 JGYjP3A1t4He for ; Mon, 8 Jul 2013 07:49:36 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id ED81121F9CE3 for ; Mon, 8 Jul 2013 07:49:35 -0700 (PDT) Received: from webmail.sonic.net (d.webmail.sonic.net [69.12.208.82]) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id r68EnVQe010500; Mon, 8 Jul 2013 07:49:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: AtMail PHP 5.62 Message-ID: <60119.1373294971@sonic.net> To: , , "Arturo Servin" X-Origin: 187.185.71.86 X-Atmail-Account: doubless@sonic.net Date: Mon, 08 Jul 2013 07:49:31 -0700 From: Merike Kaeo 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 Reply-To: merike@doubleshotsecurity.com List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 14:49:41 -0000 In looking at the diffs from rev 2 and the rev 3 yesterday I also agree wit= h Ran that the removal of the cisco related IPSO text is problematic. I remember the use of this option since = I was at cisco during the time this was created and why it was utilized and I guess for me the text wasn't confusin= g. I do see how it could be for others without further explanation. Perhaps adding some text along the lines of: "There are private networks that consider the router policing using IPSO to= be an important design feature. Those private IP networks are commonly built using commercial and open-source pro= ducts - for hosts, firewalls, routers, etc. Some routers support this option although they are part of MPLS IP router i= mplementations."...then follow with the Cisco part that was removed I am paraphrasing what Ran wrote and he will probably do a much better job = of adding the text that is needed. - merike =20 On Mon 08/07/13 6:41 AM , "Arturo Servin" arturo.servin@gmail.com sent: > Ran, >=20 > I think it was me that made the comment. >=20 > To me the text didn't make to much sense when I read it. Now that > you explained in more detail why it is included I understand the > rationale. > I do mind to put it back as it seems reasonable to do so. If there > were a way to explain why the text is there in a few words it would be > great. >=20 > Cheers, > as >=20 >=20 > On 7/8/13 10:04 AM, RJ Atkinson wrote: > > All, > > > > * I object to the removal of the references to > the Cisco> support for IPSO processing. I observe that > the comments > made recently on the OPSEC list suggested > edits, and also> expressed confusion about the purpose of the > existing text, > but did not demand entire removal of that > text.> > > * I am VERY open to editing of text in some way, > to clarify> its purpose or such like, but the total > removal of that > text and reference is problematic because it > creates> confusion that is easily avoided by having > such text.> > > > > Those references were added in direct response > to an> earlier comment erroneously claiming those > options never > had been supported in routers. So there has > been confusion > in the modern world about whether those options > are only> supported in end systems or whether they also > are supported > in routers. One commenter refused to believe > that cisco > supported IPSO, which is why the specific > reference to > a (relatively) recent Cisco IOS web page was > included > in the draft. =20 > > > > > > Removing that text or reference will create the > incorrect > impression that IPSO is an end-system-only > option, when > actually deployed networks using IPSO consider > the router > policing based on that option to be an important > design > feature. > > > > > > The recently deleted text (e.g. from 4.12.2) > clarified that > actually millions of deployed routers do support > the IPSO and > had the specific reference to the cisco website > both to support > the technical claim that the option is supported > and also > to satisfy the doubters. > > > > > > In fact, there are other IP routers that support > that> option, although they are part of MLS IP router > implementations > that are less commonly used in the public global > Internet> than either Cisco or Juniper. The products that > I am thinking> of don't seem to have a public URL describing > their features, > probably because they don't need one. The IPSO > is probably > more widely deployed today than it was in 2000 > or 1990, > but it is a specialised option that is rarely > seen on the> public global Internet. It also appears to have > much broader> geographic spread in its deployment today versus > back in 2000.> > > The lack of such an option was an issue for IPv6 > deployment,> leading fairly directly to the creation of > RFC-5570 (CALIPSO).> > > As the more recent RFC-5570 observes, however, > those private > IP networks commonly are built almost entirely > using commercial > (and open-source) products -- for hosts, > firewalls, NATs, routers, > and so on. As an example, Trusted Solaris an= d > Trusted Linux > might be present both as hosts and (in separate > hardware instances) > also as MLS IPSO-enforcing routers. > > > > > > To repeat my bottom line, I'm happy to discuss > edits to those> chunks of text, but deleting them entirely will > create confusion> about the implementation status and deployed > uses of the IPSO> option(s). > > > > > > Yours, > > > > Ran Atkinson > > > > > _______________________________________________> OPSEC mailing list > > OPSEC@ietf.org > > https://www.ietf.org/mailman/listinfo/opsec > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec >=20 >=20 >=20 From cpignata@cisco.com Mon Jul 8 10:51:20 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 7603B21F85BB for ; Mon, 8 Jul 2013 10:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.441 X-Spam-Level: X-Spam-Status: No, score=-110.441 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315, 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 By68uyeGq4aC for ; Mon, 8 Jul 2013 10:51:15 -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 F3BAA21F9CBC for ; Mon, 8 Jul 2013 10:51:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11987; q=dns/txt; s=iport; t=1373305875; x=1374515475; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=47XHToDwvJ/kEGk8NGoEaG85n6Wnq3o1NJecPCHc/o0=; b=iGswk5K5P9ArQt4+ziUezg8xPWQoSOgxCX1fpbLw4DPFmiQ2XS/4DWA3 jSsnLtPAJqCtGrUYoSUNSsJimZ+TvSNSMeZZGBbVeNItYeiodaYcPgkPl t4BJeHutRKQr3IkyWDF9jz2H/fuYIeJnbzzoDegEnj2+NS/oQZNDyFIB0 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcFAHL72lGtJXG9/2dsb2JhbABagwkyTbgziDqBFBZ0giQBAQQBAQFrCxACAQgiHQchBgsUEQIEDgUIh3UDDwywTw2IUY0AgjoxB4MHaQOVbIMQinqFJYMRgig X-IronPort-AV: E=Sophos;i="4.87,1021,1363132800"; d="scan'208,217";a="232235291" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 08 Jul 2013 17:51:14 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r68Hovra002102 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Jul 2013 17:51:10 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.116]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Mon, 8 Jul 2013 12:51:01 -0500 From: "Carlos Pignataro (cpignata)" To: Arturo Servin Thread-Topic: [OPSEC] Review of: draft-ietf-opsec-ip-options-filtering-02 Thread-Index: AQHOe9ulu4UDPw83oEGNf2neu7CvGJlbHc4AgABFt4A= Date: Mon, 8 Jul 2013 17:51:01 +0000 Message-ID: <95067C434CE250468B77282634C96ED322CCA5D8@xmb-aln-x02.cisco.com> References: <51DAC18A.5030701@gmail.com> In-Reply-To: <51DAC18A.5030701@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.55] Content-Type: multipart/alternative; boundary="_000_95067C434CE250468B77282634C96ED322CCA5D8xmbalnx02ciscoc_" 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, 08 Jul 2013 17:51:20 -0000 --_000_95067C434CE250468B77282634C96ED322CCA5D8xmbalnx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ran, Arturo, I understood the feedback on the list to refer to this text in Section 4.12= .2: Many Cisco routers that run Cisco IOS include support dropping packets that contain this option with per-interface granularity. This capability has been present in many Cisco routers since the early 1990s [Cisco-IPSO-Cmds]. But NOT to the following text in Section 4.12.1: The DoD Basic Security Option (BSO) is currently implemented in a number of operating systems (e.g., [IRIX2008], [SELinux2008], [Solaris2008], and [Cisco-IPSO]), and deployed in a n= umber of high- security networks. These networks are typically either in physically So support for IPSO by Cisco routers would remain without the specifics on = the config granularity. Ran, Could you please suggest some text that would satisfy your concern? Many thanks, -- Carlos. On Jul 8, 2013, at 9:41 AM, Arturo Servin > wrote: Ran, I think it was me that made the comment. To me the text didn't make to much sense when I read it. Now that you explained in more detail why it is included I understand the rationale. I do mind to put it back as it seems reasonable to do so. If there were a way to explain why the text is there in a few words it would be great. Cheers, as On 7/8/13 10:04 AM, RJ Atkinson wrote: All, * I object to the removal of the references to the Cisco support for IPSO processing. I observe that the comments made recently on the OPSEC list suggested edits, and also expressed confusion about the purpose of the existing text, but did not demand entire removal of that text. * I am VERY open to editing of text in some way, to clarify its purpose or such like, but the total removal of that text and reference is problematic because it creates confusion that is easily avoided by having such text. Those references were added in direct response to an earlier comment erroneously claiming those options never had been supported in routers. So there has been confusion in the modern world about whether those options are only supported in end systems or whether they also are supported in routers. One commenter refused to believe that cisco supported IPSO, which is why the specific reference to a (relatively) recent Cisco IOS web page was included in the draft. Removing that text or reference will create the incorrect impression that IPSO is an end-system-only option, when actually deployed networks using IPSO consider the router policing based on that option to be an important design feature. The recently deleted text (e.g. from 4.12.2) clarified that actually millions of deployed routers do support the IPSO and had the specific reference to the cisco website both to support the technical claim that the option is supported and also to satisfy the doubters. In fact, there are other IP routers that support that option, although they are part of MLS IP router implementations that are less commonly used in the public global Internet than either Cisco or Juniper. The products that I am thinking of don't seem to have a public URL describing their features, probably because they don't need one. The IPSO is probably more widely deployed today than it was in 2000 or 1990, but it is a specialised option that is rarely seen on the public global Internet. It also appears to have much broader geographic spread in its deployment today versus back in 2000. The lack of such an option was an issue for IPv6 deployment, leading fairly directly to the creation of RFC-5570 (CALIPSO). As the more recent RFC-5570 observes, however, those private IP networks commonly are built almost entirely using commercial (and open-source) products -- for hosts, firewalls, NATs, routers, and so on. As an example, Trusted Solaris and Trusted Linux might be present both as hosts and (in separate hardware instances) also as MLS IPSO-enforcing routers. To repeat my bottom line, I'm happy to discuss edits to those chunks of text, but deleting them entirely will create confusion about the implementation status and deployed uses of the IPSO option(s). Yours, Ran Atkinson _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec --_000_95067C434CE250468B77282634C96ED322CCA5D8xmbalnx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Ran, Arturo,

I understood the feedback on the list to refer to this text in Section= 4.12.2:

      Many Cisco routers that run Cisco IOS include =
support dropping
      packets that contain this option with per-interface granularity.
      This capability has been present in many Cisco routers since the
      early 1990s [Cisco-IPSO-Cmds].

But NOT to the following text in Section 4.12.1:

   The DoD Basic Security Option (BSO) is currently =
implemented in a
   number of operating systems (e.g., [IRIX2008], [SELinux2008],
   [Solaris2008], and [Cisco-I=
PSO]), and deployed in a number of high-
   security networks.  These networks are typically either in physically
So support for IPSO by Cisco routers would remain without the specific= s on the config granularity.

Ran,

Could you please suggest some text that would satisfy your concern?

Many thanks,

-- Carlos.

On Jul 8, 2013, at 9:41 AM, Arturo Servin <arturo.servin@gmail.com> wrote:

Ran,

   I think it was me that made the comment.

   To me the text didn't make to much sense when I read it. = Now that
you explained in more detail why it is included I understand the rationale.=

   I do mind to put it back as it seems reasonable to do so.= If there
were a way to explain why the text is there in a few words it would be
great.

Cheers,
as


On 7/8/13 10:04 AM, RJ Atkinson wrote:
All,

* I object to the removal of the references to the Cisco
 support for IPSO processing.  I observe that the comments
 made recently on the OPSEC list suggested edits, and also
 expressed confusion about the purpose of the existing text,
 but did not demand entire removal of that text.

* I am VERY open to editing of text in some way, to clarify
 its purpose or such like, but the total removal of that
 text and reference is problematic because it creates
 confusion that is easily avoided by having such text.


Those references were added in direct response to an
earlier comment erroneously claiming those options never
had been supported in routers.  So there has been confusion
in the modern world about whether those options are only
supported in end systems or whether they also are supported
in routers.  One commenter refused to believe that cisco
supported IPSO, which is why the specific reference to
a (relatively) recent Cisco IOS web page was included
in the draft.  


Removing that text or reference will create the incorrect
impression that IPSO is an end-system-only option, when
actually deployed networks using IPSO consider the router
policing based on that option to be an important design
feature.


The recently deleted text (e.g. from 4.12.2) clarified that
actually millions of deployed routers do support the IPSO and
had the specific reference to the cisco website both to support
the technical claim that the option is supported and also
to satisfy the doubters.


In fact, there are other IP routers that support that
option, although they are part of MLS IP router implementations
that are less commonly used in the public global Internet
than either Cisco or Juniper.  The products that I am thinking
of don't seem to have a public URL describing their features,
probably because they don't need one.  The IPSO is probably
more widely deployed today than it was in 2000 or 1990,
but it is a specialised option that is rarely seen on the
public global Internet.  It also appears to have much broader
geographic spread in its deployment today versus back in 2000.

The lack of such an option was an issue for IPv6 deployment,
leading fairly directly to the creation of RFC-5570 (CALIPSO).

As the more recent RFC-5570 observes, however, those private
IP networks commonly are built almost entirely using commercial
(and open-source) products -- for hosts, firewalls, NATs, routers,
and so on.  As an example, Trusted Solaris and Trusted Linux
might be present both as hosts and (in separate hardware instances)
also as MLS IPSO-enforcing routers.


To repeat my bottom line, I'm happy to discuss edits to those
chunks of text, but deleting them entirely will create confusion
about the implementation status and deployed uses of the IPSO
option(s).


Yours,

Ran Atkinson

_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

--_000_95067C434CE250468B77282634C96ED322CCA5D8xmbalnx02ciscoc_-- From cpignata@cisco.com Mon Jul 8 11:00:36 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 77AF721F9BF0 for ; Mon, 8 Jul 2013 11:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.683 X-Spam-Level: X-Spam-Status: No, score=-109.683 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315, 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 9TrT2BjsVlYF for ; Mon, 8 Jul 2013 11:00:31 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 608A621F8267 for ; Mon, 8 Jul 2013 11:00:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17590; q=dns/txt; s=iport; t=1373306431; x=1374516031; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=H8Ol76q33MwFKgsE6XqMJ+XUNIT6vIlO7qiiqf9gu3s=; b=HGc+Lw+Ye+713txtRxlegxoRgzUZwzVLp9k654ANifSHLb2ARcTuSDTo p5fwLfm9SQNPmqtxy1pnUXvhm4iyYEfZXSpOyyeEL47NXC6xxzvJ7i0J3 u54IguOiSMme5JimuHmdCKhVsbYWErwn4BJZlTy2PEaidPAuBvzPgiErq k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcFAEb92lGtJXHB/2dsb2JhbABagwkyTbgziDqBFBZ0giQBAQQBAQFrCxACAQgiHQchBgsUEQIEDgUIh3UDDwywSA2IUY0AgjoxB4MHaQOVbIMQinqFJYMRgig X-IronPort-AV: E=Sophos;i="4.87,1021,1363132800"; d="scan'208,217";a="232252912" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 08 Jul 2013 18:00:26 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r68I0D0T012454 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Jul 2013 18:00:26 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.116]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Mon, 8 Jul 2013 13:00:17 -0500 From: "Carlos Pignataro (cpignata)" To: "" Thread-Topic: [OPSEC] Review of: draft-ietf-opsec-ip-options-filtering-02 Thread-Index: AQHOe+pau4UDPw83oEGNf2neu7CvGJlbZf0A Date: Mon, 8 Jul 2013 18:00:17 +0000 Message-ID: <95067C434CE250468B77282634C96ED322CCA6D4@xmb-aln-x02.cisco.com> References: <60119.1373294971@sonic.net> In-Reply-To: <60119.1373294971@sonic.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.55] Content-Type: multipart/alternative; boundary="_000_95067C434CE250468B77282634C96ED322CCA6D4xmbalnx02ciscoc_" MIME-Version: 1.0 Cc: Arturo Servin , "" , "" 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, 08 Jul 2013 18:00:36 -0000 --_000_95067C434CE250468B77282634C96ED322CCA6D4xmbalnx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Merike, Ran, Equivalent text to the first part of what you propose is already in Section= 4.12.1, "Uses". Section 4.12.2 deals with the "Option Specification", so w= e need t=3Dnot repeat the use. The current text is as follows: Section 4.2.2.1 of RFC 1812 states that routers "SHOULD implement this option". Many Cisco routers that run Cisco IOS include support dropping packets that contain this option with per-interface granularity. This capability has been present in many Cisco routers since the early 1990s [Cisco-IPSO-Cmds]. Some governmental produ= cts reportedly support BSO, notably CANEWARE [RFC4949]. Support for BSO is included in the "IPsec Configuration Policy Information Model" [RFC3585] and in the "IPse= c Security Policy Database Configuration MIB" [RFC4807]. Perhaps something as simple as this? Section 4.2.2.1 of RFC 1812 states that routers "SHOULD implement this option". Many routers include support for IPSO. For example, Cisco routers that run Cisco IOS include support dropping packets that contain this option with per-interface granularity. This capability has been present in many Cisco routers since the early 1990s [Cisco-IPSO-Cmds]. Some governmental produ= cts reportedly support BSO, notably CANEWARE [RFC4949]. Support for BSO is included in the "IPsec Configuration Policy Information Model" [RFC3585] and in the "IPse= c Security Policy Database Configuration MIB" [RFC4807]. Thanks, -- Carlos. On Jul 8, 2013, at 10:49 AM, Merike Kaeo > wrote: In looking at the diffs from rev 2 and the rev 3 yesterday I also agree wit= h Ran that the removal of the cisco related IPSO text is problematic. I remember the use of this option since = I was at cisco during the time this was created and why it was utilized and I guess for me the text wasn't confusin= g. I do see how it could be for others without further explanation. Perhaps adding some text along the lines of: "There are private networks that consider the router policing using IPSO to= be an important design feature. Those private IP networks are commonly built using commercial and open-source pro= ducts - for hosts, firewalls, routers, etc. Some routers support this option although they are part of MPLS IP router i= mplementations."...then follow with the Cisco part that was removed I am paraphrasing what Ran wrote and he will probably do a much better job = of adding the text that is needed. - merike On Mon 08/07/13 6:41 AM , "Arturo Servin" arturo.servin@gmail.com sent: Ran, I think it was me that made the comment. To me the text didn't make to much sense when I read it. Now that you explained in more detail why it is included I understand the rationale. I do mind to put it back as it seems reasonable to do so. If there were a way to explain why the text is there in a few words it would be great. Cheers, as On 7/8/13 10:04 AM, RJ Atkinson wrote: All, * I object to the removal of the references to the Cisco> support for IPSO processing. I observe that the comments > made recently on the OPSEC list suggested edits, and also> expressed confusion about the purpose of the existing text, > but did not demand entire removal of that text.> * I am VERY open to editing of text in some way, to clarify> its purpose or such like, but the total removal of that > text and reference is problematic because it creates> confusion that is easily avoided by having such text.> Those references were added in direct response to an> earlier comment erroneously claiming those options never > had been supported in routers. So there has been confusion > in the modern world about whether those options are only> supported in end systems or whether they also are supported > in routers. One commenter refused to believe that cisco > supported IPSO, which is why the specific reference to > a (relatively) recent Cisco IOS web page was included > in the draft. Removing that text or reference will create the incorrect > impression that IPSO is an end-system-only option, when > actually deployed networks using IPSO consider the router > policing based on that option to be an important design > feature. The recently deleted text (e.g. from 4.12.2) clarified that > actually millions of deployed routers do support the IPSO and > had the specific reference to the cisco website both to support > the technical claim that the option is supported and also > to satisfy the doubters. In fact, there are other IP routers that support that> option, although they are part of MLS IP router implementations > that are less commonly used in the public global Internet> than either Cisco or Juniper. The products that I am thinking> of don't seem to have a public URL describing their features, > probably because they don't need one. The IPSO is probably > more widely deployed today than it was in 2000 or 1990, > but it is a specialised option that is rarely seen on the> public global Internet. It also appears to have much broader> geographic spread in its deployment today versus back in 2000.> The lack of such an option was an issue for IPv6 deployment,> leading fairly directly to the creation of RFC-5570 (CALIPSO).> As the more recent RFC-5570 observes, however, those private > IP networks commonly are built almost entirely using commercial > (and open-source) products -- for hosts, firewalls, NATs, routers, > and so on. As an example, Trusted Solaris and Trusted Linux > might be present both as hosts and (in separate hardware instances) > also as MLS IPSO-enforcing routers. To repeat my bottom line, I'm happy to discuss edits to those> chunks of text, but deleting them entirely will create confusion> about the implementation status and deployed uses of the IPSO> option(s). Yours, Ran Atkinson _______________________________________________> OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec --_000_95067C434CE250468B77282634C96ED322CCA6D4xmbalnx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <6AA47D9A5A4E0047AD11122A77AEAEA8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Merike, Ran,

Equivalent text to the first part of what you propose is already in Se= ction 4.12.1, "Uses". Section 4.12.2 deals with the "Option = Specification", so we need t=3Dnot repeat the use. 

The current text is as follows:

   Section 4.2.2.1 of RFC 1812 states that routers &quo=
t;SHOULD implement
   this option".
      Many Cisco routers that run Cisco IOS include =
support dropping
      packets that contain this option with per-interface granularity.
      This capability has been present in many Cisco routers since the
      early 1990s [Cisco-IPSO-Cmds].  Some gov=
ernmental products
      reportedly support BSO, notably CANEWARE [RFC4949].  Support for
      BSO is included in the "IPsec Configuration Policy Information
      Model" [RFC3585] and =
in the "IPsec Security Policy Database
      Configuration MIB" [R=
FC4807].

Perhaps something as simple as this?

   Section 4.2.2.1 of RFC 1812 states that routers &quo=
t;SHOULD implement
   this option".
      Many routers include support for IPSO. For exa=
mple, 
      Cisco routers that run Cisco IOS include suppo=
rt dropping
      packets that contain this option with per-inte=
rface granularity.
      This capability has been present in many Cisco routers since the
      early 1990s [Cisco-IPSO-Cmds].  Some gov=
ernmental products
      reportedly support BSO, notably CANEWARE [RFC4949].  Support for
      BSO is included in the "IPsec Configuration Policy Information
      Model" [RFC3585] and =
in the "IPsec Security Policy Database
      Configuration MIB" [R=
FC4807].
Thanks,

-- Carlos.


On Jul 8, 2013, at 10:49 AM, Merike Kaeo <merike@doubleshotsecurity.com> wrote:

In looking at the diffs from rev 2 and the rev 3 = yesterday I also agree with Ran that the removal of the cisco
related IPSO text is problematic.  I remember the use of this option s= ince I was at cisco during the time this was
created and why it was utilized and I guess for me the text wasn't confusin= g.  I do see how it could be for others without further
explanation.

Perhaps adding some text along the lines of:

"There are private networks that consider the router policing using IP= SO to be an important design feature.  Those
private IP networks are commonly built using commercial and open-source pro= ducts - for hosts, firewalls, routers, etc.
Some routers support this option although they are part of MPLS IP router i= mplementations."...then follow with the Cisco
part that was removed

I am paraphrasing what Ran wrote and he will probably do a much better job = of adding the text that is needed.

- merike





On Mon 08/07/13  6:41 AM , "Arturo Servin" arturo.servin@gmail.com sent:
Ran,

I think it was me that made the comment.

To me the text didn't make to much sense when I read it. Now that
you explained in more detail why it is included I understand the
rationale.
I do mind to put it back as it seems reasonable to do so. If there
were a way to explain why the text is there in a few words it would be
great.

Cheers,
as


On 7/8/13 10:04 AM, RJ Atkinson wrote:
All,

* I object to the removal of the references to
the Cisco>   support for IPSO processing.  I observe that=
the comments >   made recently on the OPSEC list suggested
edits, and also>   expressed confusion about the purpose of th= e
existing text, >   but did not demand entire removal of that text.>
* I am VERY open to editing of text in some way,<= br>
to clarify>   its purpose or such like, but the total
removal of that >   text and reference is problematic because = it
creates>   confusion that is easily avoided by having
such text.>

Those references were added in direct response
to an> earlier comment erroneously claiming those
options never > had been supported in routers.  So there has
been confusion > in the modern world about whether those options
are only> supported in end systems or whether they also
are supported > in routers.  One commenter refused to believe
that cisco > supported IPSO, which is why the specific
reference to > a (relatively) recent Cisco IOS web page was
included > in the draft.  


Removing that text or reference will create the
incorrect > impression that IPSO is an end-system-only
option, when > actually deployed networks using IPSO consider
the router > policing based on that option to be an important
design > feature.


The recently deleted text (e.g. from 4.12.2)
clarified that > actually millions of deployed routers do support
the IPSO and > had the specific reference to the cisco website
both to support > the technical claim that the option is supported
and also > to satisfy the doubters.


In fact, there are other IP routers that support
that> option, although they are part of MLS IP router
implementations > that are less commonly used in the public global
Internet> than either Cisco or Juniper.  The products that
I am thinking> of don't seem to have a public URL describing
their features, > probably because they don't need one.  The IPSO is probably > more widely deployed today than it was in 2000
or 1990, > but it is a specialised option that is rarely
seen on the> public global Internet.  It also appears to have
much broader> geographic spread in its deployment today versus
back in 2000.>
The lack of such an option was an issue for IPv6<= br>
deployment,> leading fairly directly to the creation of
RFC-5570 (CALIPSO).>
As the more recent RFC-5570 observes, however,
those private > IP networks commonly are built almost entirely
using commercial > (and open-source) products -- for hosts,
firewalls, NATs, routers, > and so on.  As an example, Trusted Sola= ris and
Trusted Linux > might be present both as hosts and (in separate
hardware instances) > also as MLS IPSO-enforcing routers.


To repeat my bottom line, I'm happy to discuss
edits to those> chunks of text, but deleting them entirely will
create confusion> about the implementation status and deployed
uses of the IPSO> option(s).


Yours,

Ran Atkinson


_______________________________________________> OPSEC mailing list
OPSEC@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/opsec
_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec



_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

--_000_95067C434CE250468B77282634C96ED322CCA6D4xmbalnx02ciscoc_-- From rja.lists@gmail.com Mon Jul 8 12:22:43 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 46EDA21F9C3A for ; Mon, 8 Jul 2013 12:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.158, 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 0FKgHnCv8nXw for ; Mon, 8 Jul 2013 12:22:42 -0700 (PDT) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C061821F9C38 for ; Mon, 8 Jul 2013 12:22:42 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id d13so5887131qak.2 for ; Mon, 08 Jul 2013 12:22:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=isjyRlg60F500dYfeW/RsTZRqj2pK67EuxNfBlzO6uA=; b=cG6kaAVoW4KQMMDytiddxeCsHYlaF1cGnJEbTN0oOB5NHRevS0zazCxM83vqsMXa6z abO2SIhzMv5MezdCs/gDxmnqjmSP/EbBNYunkdWhVMMduIa0iFmgA9zbxtqcJ3PcvSyE EAFLXsD9SLru1Z2PvzMtksaz/NjnOsIx7+rEYRqNY08A/W5ZzYmlKxFqSVye6vqBHS2d CbqD1ASinxo5WmrqqTKbS7BkTobcC/C9aBiVGo6VDaWUOk1590htzkVpOijqOGLDphdv Mn99LqR7q9DMsdE/I+1Zcds2UT+l3l74CWTXp+aLhhtbWAY8WsXhPcnDUwuy0xuUAk+f CpHA== X-Received: by 10.224.88.74 with SMTP id z10mr20132817qal.26.1373311360235; Mon, 08 Jul 2013 12:22:40 -0700 (PDT) Received: from [10.30.20.12] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPSA id t18sm15922448qam.12.2013.07.08.12.22.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Jul 2013 12:22:39 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: RJ Atkinson In-Reply-To: <95067C434CE250468B77282634C96ED322CCA5D8@xmb-aln-x02.cisco.com> Date: Mon, 8 Jul 2013 15:23:04 -0400 Content-Transfer-Encoding: 7bit Message-Id: <25778988-3203-4E2F-B47B-64CA21774745@gmail.com> References: <51DAC18A.5030701@gmail.com> <95067C434CE250468B77282634C96ED322CCA5D8@xmb-aln-x02.cisco.com> To: opsec@ietf.org X-Mailer: Apple Mail (2.1283) 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, 08 Jul 2013 19:22:43 -0000 On 08 Jul 2013, at 13:51 , Carlos Pignataro (cpignata) wrote: > So support for IPSO by Cisco routers would remain without the > specifics on the config granularity. Well, the ability to apply IPSO checks on a per-interface granularity is in fact the key point from a deployment perspective, which is why that was mentioned. > Ran, > > Could you please suggest some text that would satisfy your concern? I will do so to the list. Please give me a day or so. Thanks very much, Ran From rja.lists@gmail.com Tue Jul 9 07:27:41 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 EAA1A21F9E37 for ; Tue, 9 Jul 2013 07:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 ftaQZm0evwi2 for ; Tue, 9 Jul 2013 07:27:41 -0700 (PDT) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 5920221F9E31 for ; Tue, 9 Jul 2013 07:27:41 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id u12so2977558qcx.40 for ; Tue, 09 Jul 2013 07:27:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=5TQAtMF7351DzCidPi69BRrtTq8yZyzkEQDoKoaYZ2k=; b=kHtil8YaRkrWzocEHKPgseMDygmcBTkjlLAHuPRbFM9MKGu+Y2Slq/9xAqeYqdxENH a3mccR/3wh1fOu825gjvnKKw+2kXhd+3KFyyVkYNHuP3Ep+HrODSJZd3k+LzhiR5T3+g vARYUUa7eUNpRb/xcMM5RZL8MhjsSrz8cKJEsnWbWBrUZWWJfqW2Xr+y6aXvlgBtpHNW mty1hDI5mepQ2pbWioAgxWzBW/t6CzYBrKh0kZhyXexks1UEFGs5GhBoxpi+ZpD6Mq+D FaM/zS2gRD4U9TDHyEsYiMC2YX3eqxqAuCINk+90uCdxVXtVxekWw/HgH5Hkob1z74vM hrag== X-Received: by 10.224.80.6 with SMTP id r6mr23940740qak.40.1373380059806; Tue, 09 Jul 2013 07:27:39 -0700 (PDT) Received: from [10.30.20.12] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPSA id m2sm19585049qat.2.2013.07.09.07.27.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 07:27:38 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: RJ Atkinson In-Reply-To: <60119.1373294971@sonic.net> Date: Tue, 9 Jul 2013 10:27:37 -0400 Content-Transfer-Encoding: 7bit Message-Id: <1565B7C7-E70B-4645-971E-421CE90B27E4@gmail.com> References: <60119.1373294971@sonic.net> To: opsec@ietf.org X-Mailer: Apple Mail (2.1283) 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: Tue, 09 Jul 2013 14:27:42 -0000 All, Here is some candidate text to replace the indented text in Sections 4.12.2 & 4.13.2, leveraging Merike's suggested introduction, and restoring (with minor edits) the previous language: Some private IP networks consider IP router-based per-interface selective filtering of packets based on (a) the presence of an IPSO option (including BSO and ESO) and (b) based on the contents of that IPSO option to be important for operational security reasons. The recent IPv6 CALIPSO option specification discusses this in additional detail, albeit in an IPv6 context. [RFC5570] Such private IP networks commonly are built using both commercial and open-source products - for hosts, guards, firewalls, switches, routers, etc. Some commercial IP routers support this option, as do some IP routers which are built on top of Multi-Level Secure (MLS) operating systems (e.g. on top of Trusted Solaris [Solaris2008] or Security-Enhanced Linux [SELinux2008]). For example, many Cisco routers that run Cisco IOS include support for selectively filtering packets that contain the IP Security Options (IPSO) with per-interface granularity. This capability has been present in many Cisco routers since the early 1990s [Cisco-IPSO-Cmds]. Some government sector products reportedly also support the IP Security Options (IPSO), for example CANEWARE [RFC4949]. Support for the IPSO Basic Security Option also is included in the "IPsec Configuration Policy Information Model" [RFC3585] and in the "IPsec Security Policy Database Configuration MIB" [RFC4807]. Section 4.6.1 of the IP Security Domain of Interpretation [RFC2407] includes support for labeled IPsec security associations compatible with the IP Security Options. I'm greatly obliged to Merike for her suggested text, which is included in the proposed revised text above, and to Arturo for agreeing that an edited version of the original text could be retained in this document. Yours, Ran Atkinson From internet-drafts@ietf.org Tue Jul 9 08:53:53 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 B008311E8128; Tue, 9 Jul 2013 08:53:53 -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 nZE0uaTa0-PB; Tue, 9 Jul 2013 08:53:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E19021F9EFE; Tue, 9 Jul 2013 08:53:51 -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: <20130709155351.15694.8177.idtracker@ietfa.amsl.com> Date: Tue, 09 Jul 2013 08:53:51 -0700 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-ip-options-filtering-03.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, 09 Jul 2013 15:53:53 -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 : Recommendations on filtering of IPv4 packets containing = IPv4 options. Author(s) : Fernando Gont RJ Atkinson Carlos Pignataro Filename : draft-ietf-opsec-ip-options-filtering-03.txt Pages : 32 Date : 2013-07-09 Abstract: This document provides advice on the filtering of IPv4 packets based on the IPv4 options they contain. Additionally, it discusses the operational and interoperability implications of dropping packets based on the IP options they contain. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-ip-options-filtering There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-ip-options-filtering-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-ip-options-filtering-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From cpignata@cisco.com Tue Jul 9 08:58: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 81CC711E8151 for ; Tue, 9 Jul 2013 08:58:37 -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 eH8-WP+K234u for ; Tue, 9 Jul 2013 08:58: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 1C26611E8144 for ; Tue, 9 Jul 2013 08:58:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3046; q=dns/txt; s=iport; t=1373385504; x=1374595104; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=AUhDgZ9s7oRArY0Gi/QUAHryS7M8Zbp9EUqrFPp2nP0=; b=QrAuWwxbtC7D/stEt6gg4OzgeYZaSa+d+IlBh8WsXo+N4blncGWiDmOB vqiK4B0GnCgC7P4cKIxTbqWnUc7OZYAMKSYEXUBYArUKf2h3s7XKTmfIT phvcZaic8WgpwaN1KC9A8gBel7CRKx/QnszkoJsHwt7sBIFekwOQ4GMBz U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcFAC0y3FGtJXHB/2dsb2JhbABagwkyRwbBB4EYFnSCIwEBAQMBAQEBNzQLBQsCAQgiFBAhBgEKJQIEDgUIAYd0AwkGBwWxWg2IUY0AgjgCMQeDCWkDlQ5egxCKeoUlgxGCKA X-IronPort-AV: E=Sophos;i="4.87,1029,1363132800"; d="scan'208";a="232445639" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 09 Jul 2013 15:58:23 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r69FwNee011416 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Jul 2013 15:58:23 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.116]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Tue, 9 Jul 2013 10:58:22 -0500 From: "Carlos Pignataro (cpignata)" To: RJ Atkinson Thread-Topic: [OPSEC] Review of: draft-ietf-opsec-ip-options-filtering-02 Thread-Index: AQHOe+pau4UDPw83oEGNf2neu7CvGJlcvOiAgAAZWwA= Date: Tue, 9 Jul 2013 15:58:22 +0000 Message-ID: <95067C434CE250468B77282634C96ED322CD0A9C@xmb-aln-x02.cisco.com> References: <60119.1373294971@sonic.net> <1565B7C7-E70B-4645-971E-421CE90B27E4@gmail.com> In-Reply-To: <1565B7C7-E70B-4645-971E-421CE90B27E4@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.157.229] Content-Type: text/plain; charset="us-ascii" Content-ID: <9A97989049D2EA4FA3BF5B9C129D2695@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: Tue, 09 Jul 2013 15:58:37 -0000 WG, I just posted a new revision, intended to address all WGLC comments on this= document. You can find it at http://tools.ietf.org/html/draft-ietf-opsec-ip-options-f= iltering-03. You can also find diffs from the previous version at http://www.ietf.org/rf= cdiff?url2=3Ddraft-ietf-opsec-ip-options-filtering-03 This new revision incorporates resolution to all comments, especially from = Arturo and Merike, as well as the text below. It also incorporates a number= of editorial (typographical, grammar) fixes. Hopefully we have not missed = anything. Please review. Thanks! -- Carlos. On Jul 9, 2013, at 10:27 AM, RJ Atkinson wrote: > All, >=20 > Here is some candidate text to replace the indented text > in Sections 4.12.2 & 4.13.2, leveraging Merike's suggested=20 > introduction, and restoring (with minor edits) the previous=20 > language: >=20 > Some private IP networks consider IP router-based > per-interface selective filtering of packets based=20 > on (a) the presence of an IPSO option (including BSO=20 > and ESO) and (b) based on the contents of that IPSO=20 > option to be important for operational security reasons. > The recent IPv6 CALIPSO option specification discusses > this in additional detail, albeit in an IPv6 context.=20 > [RFC5570] >=20 > Such private IP networks commonly are built using both > commercial and open-source products - for hosts, guards, > firewalls, switches, routers, etc. Some commercial IP > routers support this option, as do some IP routers which=20 > are built on top of Multi-Level Secure (MLS) operating=20 > systems (e.g. on top of Trusted Solaris [Solaris2008] or=20 > Security-Enhanced Linux [SELinux2008]). >=20 > For example, many Cisco routers that run Cisco IOS include=20 > support for selectively filtering packets that contain the > IP Security Options (IPSO) with per-interface granularity. =20 > This capability has been present in many Cisco routers=20 > since the early 1990s [Cisco-IPSO-Cmds]. Some government=20 > sector products reportedly also support the IP Security=20 > Options (IPSO), for example CANEWARE [RFC4949]. =20 >=20 > Support for the IPSO Basic Security Option also is=20 > included in the "IPsec Configuration Policy Information=20 > Model" [RFC3585] and in the "IPsec Security Policy=20 > Database Configuration MIB" [RFC4807]. Section 4.6.1 > of the IP Security Domain of Interpretation [RFC2407] > includes support for labeled IPsec security associations > compatible with the IP Security Options. >=20 > I'm greatly obliged to Merike for her suggested text,=20 > which is included in the proposed revised text above, > and to Arturo for agreeing that an edited version of=20 > the original text could be retained in this document. >=20 >=20 > Yours, >=20 > Ran Atkinson >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From arturo.servin@gmail.com Tue Jul 9 10:05:57 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 7EF9121F9C46 for ; Tue, 9 Jul 2013 10:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 HA2y06P81Qr1 for ; Tue, 9 Jul 2013 10:05:56 -0700 (PDT) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB8221F9C22 for ; Tue, 9 Jul 2013 10:05:51 -0700 (PDT) Received: by mail-yh0-f49.google.com with SMTP id v1so2369098yhn.22 for ; Tue, 09 Jul 2013 10:05:51 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=xJWb36GskYPMTTKYZLdaLkfLLy/2fCe7VAl2zmpX7ps=; b=kWaAM/M+lLMiKz8wFhFgae7ttRWfDdXkE9RsXdO2uxV9aeR+U9iioyVani35l4hYMz Rg8wc+e+iPv1n2WvT17IjzfZQ//Eq5YleBfbT0AFGo8qWLpgExt+xiyAytzG13Q2+ioO /c7yySGhfHt+CWZPZvZIazBQdMp7U+n2SmE6Ks/REMdGiQy1Wlwkq+u30nYh1qI30T2N AWg/QO/Aznv1su1qz93zT+mOT4GUWd/0dd+ueGI42bxlNxNRaaksno3HuvlstQsO66XI 9k5D3xfjOQCQ2PB5OGNEHQg/CsPTnBIOauw6DAk9QuMgJqXMP8opTSAIA0lnv+lmCkua Rdjg== X-Received: by 10.236.134.17 with SMTP id r17mr15626222yhi.223.1373389551077; Tue, 09 Jul 2013 10:05:51 -0700 (PDT) Received: from Arturos-MacBook-Pro.local ([2001:13c7:7001:7000:719e:e9fc:9ec8:917d]) by mx.google.com with ESMTPSA id b50sm46085228yhl.1.2013.07.09.10.05.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 10:05:49 -0700 (PDT) Message-ID: <51DC42E8.3000802@gmail.com> Date: Tue, 09 Jul 2013 14:05:44 -0300 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Carlos Pignataro (cpignata)" References: <60119.1373294971@sonic.net> <1565B7C7-E70B-4645-971E-421CE90B27E4@gmail.com> <95067C434CE250468B77282634C96ED322CD0A9C@xmb-aln-x02.cisco.com> In-Reply-To: <95067C434CE250468B77282634C96ED322CD0A9C@xmb-aln-x02.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "" , RJ Atkinson 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: Tue, 09 Jul 2013 17:05:57 -0000 Looks good and clear to me. Thanks, as On 7/9/13 12:58 PM, Carlos Pignataro (cpignata) wrote: > WG, > > I just posted a new revision, intended to address all WGLC comments on this document. > > You can find it at http://tools.ietf.org/html/draft-ietf-opsec-ip-options-filtering-03. > You can also find diffs from the previous version at http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-ip-options-filtering-03 > > This new revision incorporates resolution to all comments, especially from Arturo and Merike, as well as the text below. It also incorporates a number of editorial (typographical, grammar) fixes. Hopefully we have not missed anything. > > Please review. > > Thanks! > > -- Carlos. > > On Jul 9, 2013, at 10:27 AM, RJ Atkinson wrote: > >> All, >> >> Here is some candidate text to replace the indented text >> in Sections 4.12.2 & 4.13.2, leveraging Merike's suggested >> introduction, and restoring (with minor edits) the previous >> language: >> >> Some private IP networks consider IP router-based >> per-interface selective filtering of packets based >> on (a) the presence of an IPSO option (including BSO >> and ESO) and (b) based on the contents of that IPSO >> option to be important for operational security reasons. >> The recent IPv6 CALIPSO option specification discusses >> this in additional detail, albeit in an IPv6 context. >> [RFC5570] >> >> Such private IP networks commonly are built using both >> commercial and open-source products - for hosts, guards, >> firewalls, switches, routers, etc. Some commercial IP >> routers support this option, as do some IP routers which >> are built on top of Multi-Level Secure (MLS) operating >> systems (e.g. on top of Trusted Solaris [Solaris2008] or >> Security-Enhanced Linux [SELinux2008]). >> >> For example, many Cisco routers that run Cisco IOS include >> support for selectively filtering packets that contain the >> IP Security Options (IPSO) with per-interface granularity. >> This capability has been present in many Cisco routers >> since the early 1990s [Cisco-IPSO-Cmds]. Some government >> sector products reportedly also support the IP Security >> Options (IPSO), for example CANEWARE [RFC4949]. >> >> Support for the IPSO Basic Security Option also is >> included in the "IPsec Configuration Policy Information >> Model" [RFC3585] and in the "IPsec Security Policy >> Database Configuration MIB" [RFC4807]. Section 4.6.1 >> of the IP Security Domain of Interpretation [RFC2407] >> includes support for labeled IPsec security associations >> compatible with the IP Security Options. >> >> I'm greatly obliged to Merike for her suggested text, >> which is included in the proposed revised text above, >> and to Arturo for agreeing that an edited version of >> the original text could be retained in this document. >> >> >> Yours, >> >> Ran Atkinson >> >> >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From warren@kumari.net Tue Jul 9 14:50:54 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 1B0B721F9B95 for ; Tue, 9 Jul 2013 14:50:54 -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=[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 f4g0oGYPqbf0 for ; Tue, 9 Jul 2013 14:50:43 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A31F21F9B7E for ; Tue, 9 Jul 2013 14:50:43 -0700 (PDT) Received: from [192.168.0.187] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 57DE71B405D8; Tue, 9 Jul 2013 17:50:42 -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: Date: Tue, 9 Jul 2013 17:50:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1AD19558-6E34-4DBA-8919-62E308A1436B@kumari.net> References: To: OpSec@ietf.org, draft-ietf-opsec-vpn-leakages@tools.ietf.org X-Mailer: Apple Mail (2.1508) Cc: Warren Kumari Subject: Re: [OPSEC] Start of WGLC for draft-ietf-opsec-vpn-leakages 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, 09 Jul 2013 21:50:54 -0000 Hi all, Just a reminder to please read and review this document=85 W On Jul 3, 2013, at 4:58 PM, Warren Kumari wrote: > Dear OpSec WG, >=20 > This starts a Working Group Last Call for = draft-ietf-opsec-vpn-leakages. >=20 > The draft is available here: = https://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages/ >=20 > The authors of draft-ietf-opsec-vpn-leakages have indicated that they = have incorporated feedback and believe that the document is ready for = WGLC.=20 > It is the authors responsibility to drum up additional feedback and = review. >=20 > Please review this draft to see if you think it is ready for = publication > and comments to the list, clearly stating your view. >=20 > This WGLC ends Wed 17-Jul-2013. >=20 >=20 >=20 > Helpful Notes:=20 > draft-ietf-opsec-vpn-leakages was originally = draft-gont-opsec-vpn-leakages. >=20 > There was some discussion in the thread: IPv6 implications on IPv4 = nets: IPv6 RAs, IPv4's VPN "leakage" > and "New IETF I-D about VPN traffic leakages (Fwd: New Version = Notification for draft-gont-opsec-vpn-leakages-00.txt)" >=20 >=20 > Thanks, > Warren Kumari > (as OpSec WG co-chair) >=20 >=20 > --=20 > Outside of a dog, a book is your best friend, and inside of a dog, = it's too dark to read=20 >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec >=20 -- "When it comes to glittering objects, wizards have all the taste and = self-control of a deranged magpie." -- Terry Pratchett From internet-drafts@ietf.org Thu Jul 11 05:13:09 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 5E78321F9FF3; Thu, 11 Jul 2013 05:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.061, 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 6U0vRxoDo8iD; Thu, 11 Jul 2013 05:13:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 637B521F9B90; Thu, 11 Jul 2013 05:13:04 -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: <20130711121304.2968.68637.idtracker@ietfa.amsl.com> Date: Thu, 11 Jul 2013 05:13:04 -0700 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-ip-options-filtering-04.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: Thu, 11 Jul 2013 12:13:09 -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 : Recommendations on filtering of IPv4 packets containing = IPv4 options. Author(s) : Fernando Gont RJ Atkinson Carlos Pignataro Filename : draft-ietf-opsec-ip-options-filtering-04.txt Pages : 33 Date : 2013-07-11 Abstract: This document provides advice on the filtering of IPv4 packets based on the IPv4 options they contain. Additionally, it discusses the operational and interoperability implications of dropping packets based on the IP options they contain. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-ip-options-filtering There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-ip-options-filtering-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-ip-options-filtering-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From merike@doubleshotsecurity.com Fri Jul 12 04:18:35 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 58D6A21F9DF2 for ; Fri, 12 Jul 2013 04:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.56 X-Spam-Level: X-Spam-Status: No, score=-3.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 NOghsn6ocpKj for ; Fri, 12 Jul 2013 04:18:29 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id 5B74711E80E2 for ; Fri, 12 Jul 2013 04:18:27 -0700 (PDT) Received: from webmail.sonic.net (a.webmail.sonic.net [69.12.221.241]) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id r6CBIQYH032097; Fri, 12 Jul 2013 04:18:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: AtMail PHP 5.62 Message-ID: <59125.1373627906@sonic.net> To: , X-Origin: 41.133.121.27 X-Atmail-Account: doubless@sonic.net Date: Fri, 12 Jul 2013 04:18:26 -0700 From: Merike Kaeo Cc: Warren Kumari Subject: Re: [OPSEC] Start of WGLC for draft-ietf-opsec-vpn-leakages X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: merike@doubleshotsecurity.com List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 11:18:35 -0000 Overall I support this document as it's an issue that is very real and the = VPN vendors need to fix their implementations to support IPv6. Some comments below which are mostly to clarify text with exception to very= last comment which may point to a correction needed in content. 1. Introduction Add 'integrity' to the security services a VPN provides (in my personal vie= w, this is more important than confidentiality=E2=80=A6to ensure that none = has altered the data in transit. I will note that=20 this is the *most* misunderstood part of IPsec, that a VPN always means enc= ryption. It does not - an IPsec VPN can simply perform data integrity chec= ks without encryption so that middle=20 boxes could (if policy dictated) see contents of data en route to destinati= on So change the third sentence to: "In some scenarios, it is even assumed that employing a VPN connection make= s the use of insecure protocols (e.g. that transfer sensitive information i= n the clear and/or offer no protection=20 from modification of traffic while in transit) acceptable, as the VPN provi= des security services (such as data confidentiality and/or integrity) for a= ll communications made over the VPN." 2. IPv4 and IPv6 co-existence For the sentence: "While IPv6 is not backwards-compatible with IPv4, the two protocols are "g= lued" together by the Domain Name System (DNS)." I would not use the term glue just to not confuse anyone who for whatever r= eason may be thinking 'glue record'. Perhaps another word such as tied tog= ether may be better? For the sentence: "Thus, when a dual-stacked client application means to communicate with the= aforementioned site, it can request both A and AAAA records, and use any o= f the available addresses." Change 'aforementioned site' to "www.example.com" which I think is easier o= n the eyes. 3. Virtual Private Networks in IPv4/IPv6 dual-stack hosts/networks Since you have already defined VPN in abstract, you don't need to use 'Virt= ual Private Network (VPN)' but can just use the acronym. It is common to d= efine an acronym at first use and then=20 just use acronym in subsequent text. Same comment as previously to replace 'the two protocols are glued together= by the Domain Name System' with 'the two protocols are tied together by t= he Domain Name System'. 4. VPN traffic-leakage in legitimate scenarios When looking at title I had read it as 'it's OK to have VPN leakage' althou= gh of course the text describes VPN leakage in a non-attack scenario. Mayb= e change title to 'Inadvertent VPN=20 traffic-leakage in legitimate scenarios' or 'VPN traffic-leakage in non-att= ack scenarios' ? I am wondering whether it wouldn't be useful to describe a real-world scena= rio such as Cameron wrote about. Mostly since I expect a cellular environm= ent that also uses wi-fi capabilities=20 will be subject to this issue. change 'with the aforementioned system' to 'with the intended destination'= =2E So sentence would be: "Since the host will have both IPv4 and IPv6 connectivity, and the intended= destination will have both A and AAAA DNS resource records, one of the pos= sible outcomes is that the host will=20 employ IPv6 to communicate with the intended destination." also, next sentence I would like to again stress that VPNs are not only use= d for confidentiality but also for integrity so change sentence to: "Since the VPN software does not support IPv6, the IPv6 traffic will not ut= ilize the VPN connection, and will be have no integrity nor confidentiality= protection from the source host to the=20 final destination." (I also changed 'not employ' to 'not utilize' but use what term you think = best) Add the word VPN to the last sentence so that it is explicit that it is a s= ide effect of employing IPv6-unaware VPN software (just for clarity). 6. Mitigations to VPN traffic-leakage vulnerabilities For the first (1) and (2) I wasn't sure right away if it meant IPv6 is not = supported or supported in the network but then realized it meant for the VP= N client. I would explicitly add 'If IPv6 is=20 not supported in the VPN client', and 'If IPv6 is supported in the VPN clie= nt'. Just for clarity. In the sentence: "If the VPN client is configured to only send a subset of IPv4 networks to = the VPN tunnel (split-tunnel mode), then:" would it be better to change the word 'networks' to 'traffic'? =20 Also, from the (1) and (2) that follow it looks like the intent is that a s= ubset of either IPv4 or IPv6 is meant to be sent over the VPN but if the VP= N client does not support IPv6 then the=20 traffic that requires VPN protection should all go via the IPv4 VPN. So I = am not sure that (1) is correct in disabling IPv6 support in all network in= terfaces. I expect you can prefer the traffic=20 to be VPN protected to utilize IPv4 while the traffic that can be non-secur= ed and supports IPv6 can utilize the IPv6 connection. [obviously a complex = configuration and I'd probably put in a=20 statement somewhere that monitoring to ensure that traffic that is to be se= cured does indeed follow the VPN path is recommended]. OK, that's it from me :) - merike From gert@space.net Fri Jul 12 11:38:59 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 1F47B11E815E for ; Fri, 12 Jul 2013 11:38:59 -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 Pb2cyzc-0sj2 for ; Fri, 12 Jul 2013 11:38:58 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id E6BD711E811F for ; Fri, 12 Jul 2013 11:38:56 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id D23AA6084D for ; Fri, 12 Jul 2013 20:38:54 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id B23FC604BD for ; Fri, 12 Jul 2013 20:38:54 +0200 (CEST) Received: (qmail 90934 invoked by uid 1007); 12 Jul 2013 20:38:54 +0200 Date: Fri, 12 Jul 2013 20:38:54 +0200 From: Gert Doering To: "cb.list6" Message-ID: <20130712183854.GQ57623@Space.Net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "opsec@ietf.org" , Warren Kumari , draft-ietf-opsec-vpn-leakages@tools.ietf.org Subject: Re: [OPSEC] Start of WGLC for draft-ietf-opsec-vpn-leakages 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, 12 Jul 2013 18:38:59 -0000 Hi, On Sun, Jul 07, 2013 at 01:35:59PM -0700, cb.list6 wrote: > I support publication of this draft. > > I recently ran into this leaking issue on Android with OpenVPN. An > open OpenVPN server used for security and anonymity only inserted > routes for IPv4 on the client, with the result being all IPv6 does not > go through the VPN. It pains me to see such issues with OpenVPN, as OpenVPN service providers should be able to redirect IPv6 as well now, or at least set up IPv6 in a way that directs traffic into the tunnel and "ICMP unreachable!"'s it on the server side... So yes, I also support publication of that draft. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From pkampana@cisco.com Fri Jul 12 12:03:07 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 94B8F21F9F27 for ; Fri, 12 Jul 2013 12:03:07 -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=[AWL=0.000, 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 Kmp9TGoGjjjM for ; Fri, 12 Jul 2013 12:03:02 -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 6CCFB21F949F for ; Fri, 12 Jul 2013 12:02:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1798; q=dns/txt; s=iport; t=1373655745; x=1374865345; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=iasd1yuya9uToJcnET5g6hDbeUFeDMogaybBbAMvXi8=; b=TmrTgZNSioOB5ayjPU6xU4rRzRPwuwlswvduulcjbuFb04mDngX17BRJ RCqIp2iV5T2ZKUgsxqEzVQu/B+NhpskMiDhMX0fS2BEd7VqAKIgryMTmK 1S14tSVgClgFY+Dzb8Jvh2k9NOo3A+pQlbjjSQ/O7vGxAIgonxMGKwt3Q Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAIxR4FGtJV2Y/2dsb2JhbABagwY0T8FUgQwWdIIjAQEBBAEBATc0CwwEAgEIEQQBAQEKFAkHJwsUCQgCBAENBQiIBwy3UASPMDEHBoMFbAOpKYMSgig X-IronPort-AV: E=Sophos;i="4.89,654,1367971200"; d="scan'208";a="234283862" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 12 Jul 2013 19:02:25 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6CJ2OFM006280 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Jul 2013 19:02:24 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Fri, 12 Jul 2013 14:02:24 -0500 From: "Panos Kampanakis (pkampana)" To: Gert Doering , "cb.list6" Thread-Topic: [OPSEC] Start of WGLC for draft-ietf-opsec-vpn-leakages Thread-Index: AQHOfy8WEITKJRALe0uBcijWzL9OSZlhZSyA Date: Fri, 12 Jul 2013 19:02:24 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A753E498E@xmb-rcd-x10.cisco.com> References: <20130712183854.GQ57623@Space.Net> In-Reply-To: <20130712183854.GQ57623@Space.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.89.102] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsec@ietf.org" , Warren Kumari , "draft-ietf-opsec-vpn-leakages@tools.ietf.org" Subject: Re: [OPSEC] Start of WGLC for draft-ietf-opsec-vpn-leakages 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, 12 Jul 2013 19:03:07 -0000 +1 For completeness, I would like to request the authors to add a sentence in = Section 5, to say that the recommendations in case of IPv6-only VPN (IPv4-o= nly is discussed) are equivalent. In other words, if only IPv6 traffic goes= through the VPN (split tunnel or not) then IPv4 should be dropped. Panos -----Original Message----- From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of G= ert Doering Sent: Friday, July 12, 2013 2:39 PM To: cb.list6 Cc: opsec@ietf.org; Warren Kumari; draft-ietf-opsec-vpn-leakages@tools.ietf= .org Subject: Re: [OPSEC] Start of WGLC for draft-ietf-opsec-vpn-leakages Hi, On Sun, Jul 07, 2013 at 01:35:59PM -0700, cb.list6 wrote: > I support publication of this draft. >=20 > I recently ran into this leaking issue on Android with OpenVPN. An=20 > open OpenVPN server used for security and anonymity only inserted=20 > routes for IPv4 on the client, with the result being all IPv6 does not=20 > go through the VPN. It pains me to see such issues with OpenVPN, as OpenVPN service providers s= hould be able to redirect IPv6 as well now, or at least set up IPv6 in a wa= y that directs traffic into the tunnel and "ICMP unreachable!"'s it on the = server side... So yes, I also support publication of that draft. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From paul.hoffman@gmail.com Sat Jul 13 18:03:44 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 8F2F721F9ECF for ; Sat, 13 Jul 2013 18:03:44 -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, 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 WXCOhAAKaXN8 for ; Sat, 13 Jul 2013 18:03:43 -0700 (PDT) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 79BCB21F9EE1 for ; Sat, 13 Jul 2013 18:03:42 -0700 (PDT) Received: by mail-ve0-f169.google.com with SMTP id m1so9107148ves.14 for ; Sat, 13 Jul 2013 18:03:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fZbBJAknrqrJGh7cpP6c2neJ4Bl+7TZyL+jWSeJE0Jc=; b=rJevsUqcXJk+pudXiH+LdA8drDmijNvJCgBhnvb754IuppoWTg56rC5MlBTh/sfK/l gsg8K9j082QR64Qix4WuamuyJC3iv68PoQhkrFLx9t0r3KZLjxR+C9GsGfPPBT9AI7Wv NqQLvTvWQGDiA1u0b9F2MWqFbX/h1D0nvxmPAVZqvMxmuK3JJ/L+28PqMocWHtuJcFRY JOxSCULqBad7VkZ6heCqUUi4aiGidIE7/8hFpu/X3iAkq+J7VKgUWlC8QmvXxZ4Wk2pa lH4PUQK+6/aDGtb96tFFUEzInuevSfBvA2WSVB4eIdheMn00k3mXnFa/yCtjKD9QYVS0 XzZA== MIME-Version: 1.0 X-Received: by 10.52.166.2 with SMTP id zc2mr22532102vdb.89.1373763821972; Sat, 13 Jul 2013 18:03:41 -0700 (PDT) Received: by 10.220.205.200 with HTTP; Sat, 13 Jul 2013 18:03:41 -0700 (PDT) In-Reply-To: <1C9F17D1873AFA47A969C4DD98F98A753E498E@xmb-rcd-x10.cisco.com> References: <20130712183854.GQ57623@Space.Net> <1C9F17D1873AFA47A969C4DD98F98A753E498E@xmb-rcd-x10.cisco.com> Date: Sat, 13 Jul 2013 18:03:41 -0700 Message-ID: From: Paul Hoffman To: "opsec@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2bfbe9d323f04e16e501d Cc: "draft-ietf-opsec-vpn-leakages@tools.ietf.org" Subject: Re: [OPSEC] Start of WGLC for draft-ietf-opsec-vpn-leakages 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, 14 Jul 2013 01:03:44 -0000 --001a11c2bfbe9d323f04e16e501d Content-Type: text/plain; charset=UTF-8 I have read this draft and think it is fine. Merike's list of proposed changes are also all very good. --Paul Hoffman On Fri, Jul 12, 2013 at 12:02 PM, Panos Kampanakis (pkampana) < pkampana@cisco.com> wrote: > +1 > > For completeness, I would like to request the authors to add a sentence in > Section 5, to say that the recommendations in case of IPv6-only VPN > (IPv4-only is discussed) are equivalent. In other words, if only IPv6 > traffic goes through the VPN (split tunnel or not) then IPv4 should be > dropped. > > Panos > > > > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of > Gert Doering > Sent: Friday, July 12, 2013 2:39 PM > To: cb.list6 > Cc: opsec@ietf.org; Warren Kumari; > draft-ietf-opsec-vpn-leakages@tools.ietf.org > Subject: Re: [OPSEC] Start of WGLC for draft-ietf-opsec-vpn-leakages > > Hi, > > On Sun, Jul 07, 2013 at 01:35:59PM -0700, cb.list6 wrote: > > I support publication of this draft. > > > > I recently ran into this leaking issue on Android with OpenVPN. An > > open OpenVPN server used for security and anonymity only inserted > > routes for IPv4 on the client, with the result being all IPv6 does not > > go through the VPN. > > It pains me to see such issues with OpenVPN, as OpenVPN service providers > should be able to redirect IPv6 as well now, or at least set up IPv6 in a > way that directs traffic into the tunnel and "ICMP unreachable!"'s it on > the server side... > > So yes, I also support publication of that draft. > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > --001a11c2bfbe9d323f04e16e501d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have read this draft and think it is fine. Merike&#= 39;s list of proposed changes are also all very good.

--Paul H= offman


On Fri, Jul 12, 2013 at 12:02 PM, Panos Kampanakis (pkampana) <pkampana@c= isco.com> wrote:
+1

For completeness, I would like to request the authors to add a sentence in = Section 5, to say that the recommendations in case of IPv6-only VPN (IPv4-o= nly is discussed) are equivalent. In other words, if only IPv6 traffic goes= through the VPN (split tunnel or not) then IPv4 should be dropped.

Panos



-----Original Message-----
From: opsec-bounces@ietf.org = [mailto:opsec-bounces@ietf.org] On Behalf Of Gert Doering
Sent: Friday, July 12, 2013 2:39 PM
To: cb.list6
Cc: opsec@ietf.org; Warren Kumari; draft-ietf-op= sec-vpn-leakages@tools.ietf.org
Subject: Re: [OPSEC] Start of WGLC for draft-ietf-opsec-vpn-leakages

Hi,

On Sun, Jul 07, 2013 at 01:35:59PM -0700, cb.list6 wrote:
> I support publication of this draft.
>
> I recently ran into this leaking issue on Android with OpenVPN. =C2=A0= An
> open OpenVPN server used for security and anonymity only inserted
> routes for IPv4 on the client, with the result being all IPv6 does not=
> go through the VPN.

It pains me to see such issues with OpenVPN, as OpenVPN service providers s= hould be able to redirect IPv6 as well now, or at least set up IPv6 in a wa= y that directs traffic into the tunnel and "ICMP unreachable!"= 9;s it on the server side...

So yes, I also support publication of that draft.

Gert Doering
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Aufsichtsratsvo= rs.: A. Grundner-Culemann
D-80807 Muenchen =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USt-IdNr.:= DE813185279
_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/opsec
_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/opsec

--001a11c2bfbe9d323f04e16e501d-- From warren@kumari.net Sun Jul 14 00:34: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 7EAD111E80A2 for ; Sun, 14 Jul 2013 00:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 gCKOSjgCKNBA for ; Sun, 14 Jul 2013 00:34:32 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF37D11E80E0 for ; Sun, 14 Jul 2013 00:34:32 -0700 (PDT) Received: from [10.21.12.128] (unknown [196.38.31.134]) by vimes.kumari.net (Postfix) with ESMTPSA id 813141B407D8; Sun, 14 Jul 2013 03:34:27 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Warren Kumari In-Reply-To: <95067C434CE250468B77282634C96ED322CD0A9C@xmb-aln-x02.cisco.com> Date: Sun, 14 Jul 2013 03:34:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4DAFAE6C-C7A1-4BB2-B70A-F727DCE6F847@kumari.net> References: <60119.1373294971@sonic.net> <1565B7C7-E70B-4645-971E-421CE90B27E4@gmail.com> <95067C434CE250468B77282634C96ED322CD0A9C@xmb-aln-x02.cisco.com> To: Carlos Pignataro (cpignata) X-Mailer: Apple Mail (2.1508) Cc: RJ Atkinson , "" , 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: Sun, 14 Jul 2013 07:34:37 -0000 On Jul 9, 2013, at 11:58 AM, Carlos Pignataro (cpignata) = wrote: > WG, >=20 > I just posted a new revision, intended to address all WGLC comments on = this document. Thank you.=20 We have discussed this and judge there to be consensus to progress this. We would also like to apologize for how long it took to complete this = WGLC, and thank the authors (and WG) for their patience. We have / will = be making some changes to streamline things, and hopefully prevent long = delays in the future. W >=20 > You can find it at = http://tools.ietf.org/html/draft-ietf-opsec-ip-options-filtering-03. > You can also find diffs from the previous version at = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-ip-options-filtering-0= 3 >=20 > This new revision incorporates resolution to all comments, especially = from Arturo and Merike, as well as the text below. It also incorporates = a number of editorial (typographical, grammar) fixes. Hopefully we have = not missed anything. >=20 > Please review. >=20 > Thanks! >=20 > -- Carlos. >=20 > On Jul 9, 2013, at 10:27 AM, RJ Atkinson wrote: >=20 >> All, >>=20 >> Here is some candidate text to replace the indented text >> in Sections 4.12.2 & 4.13.2, leveraging Merike's suggested=20 >> introduction, and restoring (with minor edits) the previous=20 >> language: >>=20 >> Some private IP networks consider IP router-based >> per-interface selective filtering of packets based=20 >> on (a) the presence of an IPSO option (including BSO=20 >> and ESO) and (b) based on the contents of that IPSO=20 >> option to be important for operational security reasons. >> The recent IPv6 CALIPSO option specification discusses >> this in additional detail, albeit in an IPv6 context.=20 >> [RFC5570] >>=20 >> Such private IP networks commonly are built using both >> commercial and open-source products - for hosts, guards, >> firewalls, switches, routers, etc. Some commercial IP >> routers support this option, as do some IP routers which=20 >> are built on top of Multi-Level Secure (MLS) operating=20 >> systems (e.g. on top of Trusted Solaris [Solaris2008] or=20 >> Security-Enhanced Linux [SELinux2008]). >>=20 >> For example, many Cisco routers that run Cisco IOS include=20 >> support for selectively filtering packets that contain the >> IP Security Options (IPSO) with per-interface granularity. =20 >> This capability has been present in many Cisco routers=20 >> since the early 1990s [Cisco-IPSO-Cmds]. Some government=20 >> sector products reportedly also support the IP Security=20 >> Options (IPSO), for example CANEWARE [RFC4949]. =20 >>=20 >> Support for the IPSO Basic Security Option also is=20 >> included in the "IPsec Configuration Policy Information=20 >> Model" [RFC3585] and in the "IPsec Security Policy=20 >> Database Configuration MIB" [RFC4807]. Section 4.6.1 >> of the IP Security Domain of Interpretation [RFC2407] >> includes support for labeled IPsec security associations >> compatible with the IP Security Options. >>=20 >> I'm greatly obliged to Merike for her suggested text,=20 >> which is included in the proposed revised text above, >> and to Arturo for agreeing that an edited version of=20 >> the original text could be retained in this document. >>=20 >>=20 >> Yours, >>=20 >> Ran Atkinson >>=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 -- "Build a man a fire, and he'll be warm for a day. Set a man on fire, and = he'll be warm for the rest of his life." -- Terry Pratchett From kkumar@google.com Sun Jul 14 12:33:40 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 962ED21F9B19 for ; Sun, 14 Jul 2013 12:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.060, 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 rlUgROHvd4VS for ; Sun, 14 Jul 2013 12:33:40 -0700 (PDT) Received: from mail-qe0-x230.google.com (mail-qe0-x230.google.com [IPv6:2607:f8b0:400d:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 2365421F99E8 for ; Sun, 14 Jul 2013 12:33:39 -0700 (PDT) Received: by mail-qe0-f48.google.com with SMTP id 2so6069622qea.35 for ; Sun, 14 Jul 2013 12:33:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=4IN52dHfY1FIrnMfHi0CmCZsMTYWFvWYS6Ujzq9eZmc=; b=OdPXHCaM0p5FUDj2K4JK7c+lFGARnEIATRlzqS8KWG2pw9Yu+PFjEqCt+5e9xyjGYg DORbW3HP/jvlaAeCoKszK4uH2RrEUFwsPoyuer225MRYf9Al470RG7azr/HTjnKgAP6q 2Uni4WzSiJSFKJAkdA1RzGrVWAvkbZ1yVM+4NJpOeZbzf2MzRBbiPuslyeoLiXZRx9Qp VrbjBmISgLs29+ZHKEEZ2Z2hKkKRyjG9lMCFV9CC1jbG1ZfBHrMXx3ZfW8W1O5nZ/T9o YwXGQdPCzBRn8yB7ovFLfCzGdJ4pY1Wl0IdVIcWOdNVMiMgziCQpc8xukozGDtzeoiRa mlcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=4IN52dHfY1FIrnMfHi0CmCZsMTYWFvWYS6Ujzq9eZmc=; b=mp5jiRGc//J4BkBaIfwx9xNKy5iE30xCTeMOlaTfekqg3sx0lpPMZ3+19YJwnW4ClV nEsgy7P/uiYaae90KOXhsVg7Lwf7mZwL1ViK1c2DUTCnnblMoVXqAh8bb8feeWqezY7O 2YxE6KeQmo9A7/H3ZR3L2aayBnceLeiQlCvdLG7Ej7JTqTd/elo9ndk7sPrCMciZ7DAT XctVkycM1W2HZtv1i1v6D4/Zwv5F7HhWFAl7go0g+b1GJ9mmVLuJyefbQ7jtBEOqvAa6 VABUnO7CDYwVPnfiEBDyMRgQNR7CFXKYp0pUvH4u4J1UInYVvZ0J1BqlWWwKK1zKQ/0u bHJQ== X-Received: by 10.224.168.14 with SMTP id s14mr47599251qay.91.1373830419487; Sun, 14 Jul 2013 12:33:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.41.238 with HTTP; Sun, 14 Jul 2013 12:33:19 -0700 (PDT) From: KK Date: Sun, 14 Jul 2013 12:33:19 -0700 Message-ID: To: "opsec@ietf.org" Content-Type: multipart/alternative; boundary=089e0149ca7422bd5404e17dd2d9 X-Gm-Message-State: ALoCoQkltyDGpua2w8qMQr4W362oqoxEfve7h2q4QIG1zoYHdCoxkm6/vcbbQhBO3FdZ8NzGhJ2UUd6Ff+mok91+iazW2dG1APIi/0Cg3WeTj/J3k6GqQlBnt5PSPH+grnLKNgQ6G2VPkMgx5bmH07uxQcJgZDa4Je6TpSIFrFzUeKcX3KPCVZFNqsY/04SEWkeyNkKloRBW Subject: [OPSEC] A few important dates 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, 14 Jul 2013 19:33:40 -0000 --089e0149ca7422bd5404e17dd2d9 Content-Type: text/plain; charset=ISO-8859-1 Dear All, Just wanted to send out a quick reminder with a few important dates: 2013-07-15 (Monday): Internet Draft submission cut-off (for all drafts, including -00) by UTC 24:00 2013-07-16 (Tuesday): Please send in your agenda items by UTC 24:00 2013-07-29 (Monday): OPSEC meeting at 0900 hrs Regards, KK --089e0149ca7422bd5404e17dd2d9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear All,

Just wanted to s= end out a quick reminder with a few important dates:

2013-07-15 (Monday): Internet Draft submission cut-of= f (for all drafts, including -00) by UTC 24:00

2013-07-16 (Tuesday): Please send in your agenda item= s by UTC 24:00
2013-07-29 (Monday): OPSEC meeting at 0900 hrs

Regards,
KK
--089e0149ca7422bd5404e17dd2d9-- From jerduran@cisco.com Sun Jul 14 15:06:53 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 CE61C21F9BD0 for ; Sun, 14 Jul 2013 15:06:46 -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 MgqGo6ZDjcUC for ; Sun, 14 Jul 2013 15:06:41 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 998EA21F9B1E for ; Sun, 14 Jul 2013 15:06:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8084; q=dns/txt; s=iport; t=1373839601; x=1375049201; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jf5DadRLrSN0u5cJUw3rI3W8VQYAElCrOHNJEUxRRb4=; b=LYGXIuEWUoV08ioQtTdFhxoFhUtsQg2DPoOhmoQwnICajMpIuC3jU1Oe C/GynQPZCN9btoD+2o3zbJQV9ZQHdCuQZs8sLvdTb5PKjYPC4zR3zBTfZ 7Je8ZnNDaCWuR/Iv3j+TEmqGgIMtNGZ+MKvlD08V6Tf2REH6wdjG2Qnfi I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFACEg41GtJXHA/2dsb2JhbABagwY0T8FOgQwWdIIjAQEBAQIBHVUHBQsCAQgRBAEBCx0HMhQJCAIEDgUIDId2Bgy1OI4iEH8CLAUHgwttA5kFkCSDEoFqBxcGGg X-IronPort-AV: E=Sophos;i="4.89,665,1367971200"; d="scan'208";a="234735343" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 14 Jul 2013 22:06:41 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6EM6eMI031272 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 14 Jul 2013 22:06:40 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.35]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Sun, 14 Jul 2013 17:06:40 -0500 From: "Jerome Durand (jerduran)" To: "George, Wes" Thread-Topic: [OPSEC] Start of WGLC for draft-ietf-opsec-bgp-security Thread-Index: AQHOKxNjRfwP+9mUrkKCCRf4VNu1qZjCQRiAgKN58gA= Date: Sun, 14 Jul 2013 22:06:40 +0000 Message-ID: <0145702467942740A26A9633AA8B60FA4726CDF2@xmb-rcd-x01.cisco.com> References: <2671C6CDFBB59E47B64C10B3E0BD5923042CFA42B4@PRVPEXVS15.corp.twcable.com> In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD5923042CFA42B4@PRVPEXVS15.corp.twcable.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.163.23] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-opsec-bgp-security@tools.ietf.org" , "opsec@ietf.org" Subject: Re: [OPSEC] Start of WGLC for draft-ietf-opsec-bgp-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: Sun, 14 Jul 2013 22:06:53 -0000 Hi Wesley, It's been some time you have sent us these great comments but please be sur= e they are highly appreciated. Answers in-line: > Section 4.1: TCP MD5 (and the resulting reference 2385) is obsoleted. Whi= le I support mentioning it here, because it is still in wide use for many r= easons, it really shouldn=92t be used as a normative reference, and the cur= rent text really isn=92t adequate without recommending AO (instead of MD5) = in a bit stronger terms, especially for a BCP document. > It may also be appropriate to reference one or more of the KARP documents= , especially the BGP sections of draft-ietf-karp-routing-tcp-analysis, RFC = 6518/6862, all of which are concerned with securing the communication of ro= uting protocols (compared with SIDR, which is concerned with securing BGP= =92s semantics). Added. Link to KARP RFC 6952 is helping us not re-writting the full story. > 5.1.2.4 =96 typically I-Ds do not refer to WGs, which tend to be ephemera= l, but rather their document output, which is not. While it may not be with= in the scope of this document to discuss the relative level of success that= SIDR has achieved in providing new ways to secure BGP, it might be useful = to at least be clearer on what is in operation today (origin validation) vs= still in progress (path validation), and be clearer about how this dovetai= ls with the other recommendations made in this document. IMO, most of the r= ecommendations made in this document stand on their own, and should remain = in use independent of SIDR=92s level of deployment, and I think it=92s usef= ul for the document to say this. This document=92s recommendations are all = foundational, things that SIDR could eventually build on to improve things = further. It=92s ok to assume that the reader is familiar with SIDR, but ref= erences should be provided for the reader to review if they are not. Refere= nces to 6480, the bgpsec-reqs and bgpsec-threats documents might be a good = start, and perhaps even draft-ietf-grow-simple-leak-attack-bgpsec-no-help. Good inputs. I haven't added draft-ietf-grow-simple-leak-attack-bgpsec-no-h= elp yet but I keep that in mind to illustrate that SIDR is to put on top of= existing rules. > Also, =93the rest of this section assumes=85.=94 This is only a few sente= nces from the end of the section. Is (or was) there more intended to be add= ed to this section, or is this sentence misplaced, or what? Removed. > 5.2.2.1 =96 inconsistent use of MUST (should be caps?) Done > 8 =96 this probably needs to discuss the security aspects of an AS migrat= ion and the attending exceptions to some of these rules. A draft is in prog= ress to document these vendor-specific migration knobs here: draft-ga-idr-a= s-migration, because while it doesn=92t necessarily need to be standardized= (it=92s mostly local to the router where the knobs are turned, is largely = transparent to the remote peer, and doesn=92t need interop) it=92s pretty i= mportant for things that want to protect the AS-Path from manipulation or s= poofing (they shouldn=92t break this legitimate use). Good point. I have added a short paragraph at the end of the current bullet= points to recall that rules should be further analyzed upon ASN renumberin= g. > Also, the beginning of this sections says =93the following rules SHOULD= =85=94 but then the 5th bullet says =93must=94 =96 if the must is not norma= tive, it might be worth rewording this bullet to eliminate confusion/confli= ct between the two normative keywords The MUST applies to an exception to the fifth bullet point. Could you pleas= e provide me with better wording as I fail to find one myself. > 10 =96 rationale for community scrubbing recommendation? Well from past experience we've seen that when communities are intentionnal= y removed by upstreams it is often annoying for someone. We just want to re= call that unless necessary communities should not be manipulated without ca= ution. > 14 =96 the statement here, while true, is incomplete. Are there security = considerations created by implementing any of the things recommended in thi= s document, or open BGP security issues that are not resolved by this docum= ent=92s recommendations? Those should be discussed here. One that I can thi= nk of is that many of the items in this draft don=92t do much to protect ag= ainst crafted-packet attacks that cause the BGP machinery to choke on itsel= f, especially of the zero-day variety. Some of this is implementation-speci= fic (limitations on whether you can filter against known vulnerabilities), = some of it is related to the way that the BGP state machine itself deals wi= th errors, etc. (more on this in draft-ietf-grow-ops-reqs-for-bgp-error-ha= ndling) Good point. > Generally, I support this document. It=92s really useful to have all of t= his in one place, because that=92s been lacking in the past. However, this = is a document that would benefit from additional operational feedback. I=92= d encourage the authors to take the feedback from WGLC, spin an update, and= then request review and input on the *NOG lists before this goes to IETF l= ast call. It=92s a much wider community than the folks that hang out on ops= ec, or in IETF in general, and given the amount of discussion in government= -land and in other interested groups around best practice for securing rout= ing infrastructure, I can see this being used as a prescriptive tool, so it= =92s in our best interest to make sure that it=92s well-vetted and complete= . Not to say that the current recommendations don=92t represent BCP in this= space, but I=92m sure that there=92s stuff that we=92re forgetting that wo= uld be good to add, and additional pairs of eyes are more likely to remembe= r some of those things. Again thank you Wesley for your inputs. We've been presenting in RIPE commu= nity last year. We should do more but time is lacking. Any help to further = advertise this document is welcome. There should be a -01 RSN. Please drop me an email if you see better wordin= g for your comments. Jerome > =20 > Thanks, > =20 > Wes George > =20 > =20 > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of= KK > Sent: Wednesday, March 27, 2013 1:49 PM > To: opsec@ietf.org > Cc: > Subject: [OPSEC] Start of WGLC for draft-ietf-opsec-bgp-security > =20 > Dear OpSec WG, > =20 > This starts a Working Group Last Call for draft-ietf-opsec-bgp-security. > All three authors have replied, stating that they do not know of any IPR = associated with this draft. > =20 > The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-= opsec-bgp-security/ >=20 >=20 > Please review this draft to see if you think it is ready for publication = and comments to the list, clearly stating your view. > =20 > This WGLC ends 10-April-2013. > =20 > Thanks, > KK > (as OpSec WG co-chair) > =20 >=20 >=20 > This E-mail and any of its attachments may contain Time Warner Cable prop= rietary information, which is privileged, confidential, or subject to copyr= ight belonging to Time Warner Cable. This E-mail is intended solely for the= use of the individual or entity to which it is addressed. If you are not t= he intended recipient of this E-mail, you are hereby notified that any diss= emination, distribution, copying, or action taken in relation to the conten= ts of and attachments to this E-mail is strictly prohibited and may be unla= wful. If you have received this E-mail in error, please notify the sender i= mmediately and permanently delete the original and any copy of this E-mail = and any printout. -- Jerome Durand Consulting Systems Engineer - Routing & Switching jerduran@cisco.com - +33 6 35 11 60 50 http://reseauxblog.cisco.fr - http://ipv6blog.cisco.fr CISCO France 11, rue Camille Desmoulins 92782 Issy les Moulineaux CEDEX 9 FRANCE From internet-drafts@ietf.org Sun Jul 14 15:34:39 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 8A1B321F9C08; Sun, 14 Jul 2013 15:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.060, 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 irFpC4glKisG; Sun, 14 Jul 2013 15:34:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2976321F9BC0; Sun, 14 Jul 2013 15:34:39 -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: <20130714223439.21571.70821.idtracker@ietfa.amsl.com> Date: Sun, 14 Jul 2013 15:34:39 -0700 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-bgp-security-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: Sun, 14 Jul 2013 22:34:39 -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 : BGP operations and security Author(s) : Jerome Durand Ivan Pepelnjak Gert Doering Filename : draft-ietf-opsec-bgp-security-01.txt Pages : 26 Date : 2013-07-14 Abstract: BGP (Border Gateway Protocol) is the protocol almost exclusively used in the Internet to exchange routing information between network domains. Due to this central nature, it's important to understand the security measures that can and should be deployed to prevent accidental or intentional routing disturbances. This document describes measures to protect the BGP sessions itself (like TTL, MD5, control plane filtering) and to better control the flow of routing information, using prefix filtering and automatization of prefix filters, max-prefix filtering, AS path filtering, route flap dampening and BGP community scrubbing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-bgp-security There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-bgp-security-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-bgp-security-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From gvandeve@cisco.com Mon Jul 15 03:55:34 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 4C54A11E80D9 for ; Mon, 15 Jul 2013 03:55:34 -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 Bojv2YSaJG32 for ; Mon, 15 Jul 2013 03:55:29 -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 40B7811E80DC for ; Mon, 15 Jul 2013 03:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14205; q=dns/txt; s=iport; t=1373885729; x=1375095329; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GSTXqpqSHtVey2PyoqiO3GtNM1oF5At4yrhiuA7cTv4=; b=QJtld78u0lpgxkx/VtgZdURSGBnNJNX8PTUstDkpsSLoNYMwr7mhkX4k d8/EOrF21aL2g+4+Iv/JpqIcwIIBfv5sylmBJwE7rocxizRDmg8EXjQwp IBYMzaZp0ybAuZsJyAuJNcUH9x+ePo6fnPvxW/9UvlfQxkvgYFAk7ZXvf o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEGABzU41GtJV2b/2dsb2JhbABagkJENE+vYok4iDaBDxZ0giMBAQEELUwQAgEIEQQBAQsdBzIUCQgCBAENBQgMB4d1DLUljzMxBgGDC20DmQWQJIMSgig X-IronPort-AV: E=Sophos;i="4.89,668,1367971200"; d="scan'208,217";a="234878287" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 15 Jul 2013 10:55:19 +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 r6FAtISR011186 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Jul 2013 10:55:18 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.22]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Mon, 15 Jul 2013 05:55:17 -0500 From: "Gunter Van de Velde (gvandeve)" To: KK , joel jaeggli Thread-Topic: [OPSEC] Revised Charter Text Thread-Index: AQHOdbTgrx2n6k/0FEuuGtGRiwTD+plPHaQAgAHZiACAFLDQ8A== Date: Mon, 15 Jul 2013 10:55:19 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B240D1B28D7@xmb-aln-x12.cisco.com> References: <51D0A61A.3040901@bogus.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.207.214] Content-Type: multipart/alternative; boundary="_000_67832B1175062E48926BF3CB27C49B240D1B28D7xmbalnx12ciscoc_" 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: Mon, 15 Jul 2013 10:55:34 -0000 --_000_67832B1175062E48926BF3CB27C49B240D1B28D7xmbalnx12ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Maybe at the end of this year we should look into the milestones again and = see what is missed or changed? G/ From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of K= K Sent: 02 July 2013 03:57 To: joel jaeggli Cc: opsec@ietf.org; opsec chairs Subject: Re: [OPSEC] Revised Charter Text Yes indeed, I think an update of the milestones is a bit overdue. We did on= e late last year, will work on getting updates in. On Sun, Jun 30, 2013 at 2:41 PM, joel jaeggli > wrote: On 6/30/13 10:11 AM, KK wrote: Hey Folks, Just a reminder, we'll be wrapping this up today. this is a perhaps related question that is NOT tied to the charter text wh= ich is are there milestone(s) which we should be adding associated with pa= rticular areas of work that are ongoing (the nd security draft). joel Thanks, KK On Thu, Jun 13, 2013 at 10:59 AM, KK <= mailto:kk@google.com>> 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. """ --_000_67832B1175062E48926BF3CB27C49B240D1B28D7xmbalnx12ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Maybe at the end of this = year we should look into the milestones again and see what is missed or cha= nged?

 <= /p>

 <= /p>

G/

 <= /p>

From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org= ] On Behalf Of KK
Sent: 02 July 2013 03:57
To: joel jaeggli
Cc: opsec@ietf.org; opsec chairs
Subject: Re: [OPSEC] Revised Charter Text

 

Yes indeed, I think an update of the milestones is a= bit overdue. We did one late last year, will work on getting updates in.

 

On Sun, Jun 30, 2013 at 2:41 PM, joel jaeggli <joelja@bogus.com>= ; wrote:

On 6/30/13 10:11 AM, KK wrote:

Hey Folks,

Just a reminder, we'll be wrapping this up today.

this is a perhaps related question that is  NOT= tied to the charter text which is are there milestone(s) which we should b= e  adding associated with particular areas of work that are ongoing (t= he nd security draft).

joel

Thanks,
KK




On Thu, Jun 13, 2013 at 10:59 AM, KK <kk@google.com <mailto:kk@google.com>> 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 revis= ion
    are mostly related to elaborating on the type of documents th= is WG
    produces along with some minor wordsmithing here and there.
    We would like to get you to review the text and provide comme= nts.
    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 l= ove
    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 curren= t
    practices with regard to network security. In particular, eff= orts
    will be made to clarify the rationale supporting current
    operational practice, address gaps in currently understood be= st
    practices for forwarding, control plane, and management plane=
    security and clarify liabilities inherent in security practic= es
    where they exist.


    Scope:


    The scope of the OPSEC WG is intended to include the protecti= on
    and secure operation of the forwarding, control and managemen= t
    planes. Documentation of operational issues, revision of exis= ting
    operational

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


    Method:


    It is expected that the product of the working group will res= ult
    in the publication of informational or BCP RFCs. Taxonomy or<= br>     problem statement documents may provide a basis for such docu= ments.


    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<= br>     produced. This will be primarily based on operational experie= nce.
    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 wri= ting
    that are used to address the threat

    * the possibility that a solution does not exist within exist= ing
    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. S= uch 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<= br>     groups that develop

    protocols or the community of protocol developers at large an= d
    implementers of these protocols.


    Non-Goals:


    The OPSEC WG is not the place to do new protocols. New protoc= ol
    work should be addressed in a working group chartered in the<= br>     appropriate area or as individual submissions. The OPSEC WG m= ay
    take on documents related to the practices of using such work= .


    """

 

 

--_000_67832B1175062E48926BF3CB27C49B240D1B28D7xmbalnx12ciscoc_-- From internet-drafts@ietf.org Mon Jul 15 14:15:16 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 8AFCD21E8147; Mon, 15 Jul 2013 14:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, 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 emctT0daMloH; Mon, 15 Jul 2013 14:15:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 273E821E80C3; Mon, 15 Jul 2013 14:15:16 -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: <20130715211516.20110.82627.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 14:15:16 -0700 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-ipv6-host-scanning-02.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: Mon, 15 Jul 2013 21:15:16 -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 : Network Reconnaissance in IPv6 Networks Author(s) : Fernando Gont Tim Chown Filename : draft-ietf-opsec-ipv6-host-scanning-02.txt Pages : 36 Date : 2013-07-15 Abstract: IPv6 offers a much larger address space than that of its IPv4 counterpart. The standard /64 IPv6 subnets can (in theory) accommodate approximately 1.844 * 10^19 hosts, thus resulting in a much lower host density (#hosts/#addresses) than is typical in IPv4 networks, where a site typically has 65,000 or less unique addresses. As a result, it is widely assumed that it would take a tremendous effort to perform address scanning attacks against IPv6 networks, and therefore classic IPv6 address scanning attacks have been considered unfeasible. This document updates RFC 5157 by providing further analysis on how traditional address scanning techniques apply to IPv6 networks, and exploring some additional techniques that can be employed for IPv6 network reconnaissance. In doing so, this document formally obsoletes RFC 5157. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-host-scanning There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-ipv6-host-scanning-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-ipv6-host-scanning-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jul 15 14:16:38 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 D7D8521E8175; Mon, 15 Jul 2013 14:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, 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 P7mjfFoy6NPr; Mon, 15 Jul 2013 14:16:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E351A21E80C3; Mon, 15 Jul 2013 14:16:37 -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: <20130715211637.19232.87008.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 14:16:37 -0700 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-v6-03.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: Mon, 15 Jul 2013 21:16:39 -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 : Operational Security Considerations for IPv6 Networks Author(s) : Kiran Kumar Chittimaneni Merike Kaeo Eric Vyncke Filename : draft-ietf-opsec-v6-03.txt Pages : 40 Date : 2013-07-15 Abstract: Knowledge and experience on how to operate IPv4 securely is available: whether it is the Internet or an enterprise internal network. However, IPv6 presents some new security challenges. RFC 4942 describes the security issues in the protocol but network managers also need a more practical, operations-minded best common practices. This document analyzes the operational security issues in all places of a network (service providers, enterprises and residential users) and proposes technical and procedural mitigations techniques. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-v6 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-v6-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-v6-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Donald.Smith@CenturyLink.com Mon Jul 15 15:14:23 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 7AF9821E8110; Mon, 15 Jul 2013 15:14:23 -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=[AWL=0.001, 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 h2y09Xd6edzQ; Mon, 15 Jul 2013 15:14:17 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 4612B21E8103; Mon, 15 Jul 2013 15:14:17 -0700 (PDT) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id r6FMEEFT004191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Jul 2013 16:14:15 -0600 (MDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 5441A1E003F; Mon, 15 Jul 2013 17:14:09 -0500 (CDT) Received: from suomp61i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 32AA81E0032; Mon, 15 Jul 2013 17:14:09 -0500 (CDT) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id r6FME8YR006982; Mon, 15 Jul 2013 17:14:08 -0500 (CDT) Received: from vddcwhubex502.ctl.intranet (vddcwhubex502.qintra.com [151.119.128.29]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id r6FME8eC006973 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Jul 2013 17:14:08 -0500 (CDT) Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex502.ctl.intranet ([2002:9777:801d::9777:801d]) with mapi id 14.02.0318.001; Mon, 15 Jul 2013 16:14:09 -0600 From: "Smith, Donald" To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [OPSEC] I-D Action: draft-ietf-opsec-bgp-security-01.txt Thread-Index: AQHOgOJyX0RuLj1wv0Wj84q8bZl9zplmRq3y Date: Mon, 15 Jul 2013 22:14:07 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D0A38CFD6@PDDCWMBXEX503.ctl.intranet> References: <20130714223439.21571.70821.idtracker@ietfa.amsl.com> In-Reply-To: <20130714223439.21571.70821.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.70.40.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "opsec@ietf.org" Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-bgp-security-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: Mon, 15 Jul 2013 22:14:23 -0000 This is true but there is another case not listed. "Attacks on TCP sessions used by BGP (ex: sending spoofed TCP RST packets) could bring down the TCP session. Following a successful ARP spoofing attack (or other similar Man-in-the-Middle attack), the attacker might even be able to inject packets into the TCP stream (routing attacks)." The spoofed rst tested we did in our lab based on this paper "Slipping in t= he tcp window" by Paul A Watson documented is NOT just for resets. What he documented was around resets and so where his tests but reset isn't= magic it was just simpler. I never implemented a injection attack with ack but in theory that works ju= st as well. It might take a bit longer but it would work in theory. The reset testing we did killed sessions within a minute all the time (we c= heated a bit we knew the src and dst ports) but were guessing the ack value= based on windows size. So there is nothing magic about the rst element. It is just a bit easier to= just send the resets and not try to do a prefix hijack or something like t= hat. This paragraph mentions MD5 but tcp-ao actually obsoletes rfc 2385 so you m= ight want to change that example to another algorithm. Having said that MD5 collisions require you know M to create M' as far as I= know. So since the bad guy doesn't know your shared secret I would say md5= is still valid for bgp session security. If the bad guy does know your shared secret then he doesn't have to create = M' he can create an M that would be valid;) "The drawback of TCP session protection is additional configuration and management overhead for authentication information (ex: MD5 password) maintenance. Protection of TCP sessions used by BGP is thus recommended when peerings are established over shared networks where spoofing can be done (like IXPs)." Recommending MD5 to tcp-ao without strongly recommending TTL security with = it is a bit dangerous. The authors mention TTL security right below that but I think it should be = recommended IF you implement either of those options. "BGP sessions can be made harder to spoof with the TTL security [9]. Instead of sending TCP packets with TTL value =3D 1, the routers send the TCP packets with TTL value =3D 255 and the receiver checks that the TTL value equals 255. Since it's impossible to send an IP packet with TTL =3D 255 to a non-directly-connected IP host, BGP TTL security effectively prevents all spoofing attacks coming from third parties not directly connected to the same subnet as the BGP-speaking routers. Network administrators SHOULD implement TTL security on directly connected BGP peerings." In many modern routers the ttl is decremented by the line card before the p= acket is sent up the "stack" so I believe in most cases the "router" will s= ee a ttl of 254. Some routers do NOT have an initial TTL of 255. Having a default initial TT= L of 255 should be strongly recommended in the TTL section (all routers hec= k everything should have an initial of 255 we could do a lot more antispoof= ing work if they did). TTL security should be changed to GTSM. That is what is referenced at the b= ottom and the correct term:) The rest looked good to me. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@centurylink.com From: opsec-bounces@ietf.org [opsec-bounces@ietf.org] on behalf of internet= -drafts@ietf.org [internet-drafts@ietf.org] Sent: Sunday, July 14, 2013 4:34 PM To: i-d-announce@ietf.org Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-bgp-security-01.txt 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 : BGP operations and security Author(s) : Jerome Durand Ivan Pepelnjak Gert Doering Filename : draft-ietf-opsec-bgp-security-01.txt Pages : 26 Date : 2013-07-14 Abstract: BGP (Border Gateway Protocol) is the protocol almost exclusively used in the Internet to exchange routing information between network domains. Due to this central nature, it's important to understand the security measures that can and should be deployed to prevent accidental or intentional routing disturbances. This document describes measures to protect the BGP sessions itself (like TTL, MD5, control plane filtering) and to better control the flow of routing information, using prefix filtering and automatization of prefix filters, max-prefix filtering, AS path filtering, route flap dampening and BGP community scrubbing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-bgp-security There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-bgp-security-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-bgp-security-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec= From wesley.george@twcable.com Tue Jul 23 10:14:38 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 8E41D21E80CE for ; Tue, 23 Jul 2013 10:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.213 X-Spam-Level: X-Spam-Status: No, score=-1.213 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 dHeVn50aJjsz for ; Tue, 23 Jul 2013 10:14:33 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF5B11E823F for ; Tue, 23 Jul 2013 10:14:33 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.89,729,1367985600"; d="scan'208";a="111832073" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 23 Jul 2013 13:13:26 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Tue, 23 Jul 2013 13:14:32 -0400 From: "George, Wes" To: "Jerome Durand (jerduran)" Date: Tue, 23 Jul 2013 13:14:31 -0400 Thread-Topic: [OPSEC] Start of WGLC for draft-ietf-opsec-bgp-security Thread-Index: AQHOKxNjRfwP+9mUrkKCCRf4VNu1qZjCQRiAgKN58gCADXmSUA== Message-ID: <2671C6CDFBB59E47B64C10B3E0BD592304392E0792@PRVPEXVS15.corp.twcable.com> References: <2671C6CDFBB59E47B64C10B3E0BD5923042CFA42B4@PRVPEXVS15.corp.twcable.com> <0145702467942740A26A9633AA8B60FA4726CDF2@xmb-rcd-x01.cisco.com> In-Reply-To: <0145702467942740A26A9633AA8B60FA4726CDF2@xmb-rcd-x01.cisco.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-opsec-bgp-security@tools.ietf.org" , "opsec@ietf.org" Subject: Re: [OPSEC] Start of WGLC for draft-ietf-opsec-bgp-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: Tue, 23 Jul 2013 17:14:38 -0000 I've reviewed the -01 for changes, most of my previous comments are address= ed. A few responses below inline Thanks, Wes > -----Original Message----- > From: Jerome Durand (jerduran) [mailto:jerduran@cisco.com] > Sent: Sunday, July 14, 2013 6:07 PM > > > Also, the beginning of this section (8) says "the following rules > SHOULD..." but then the 5th bullet says "must" - if the must is not > normative, it might be worth rewording this bullet to eliminate > confusion/conflict between the two normative keywords > > The MUST applies to an exception to the fifth bullet point. Could you > please provide me with better wording as I fail to find one myself. > [WEG] You might want to remove the SHOULD from the preamble text and instea= d rewrite each bullet with normative language to eliminate "do not" and "tr= y to" (eg instead of "From customers, try to accept only AS(4)-Paths..." ma= ybe "You SHOULD accept only AS(4)-Paths from customers...") so that each bu= llet stands alone. Regarding the MUST in the 5th bullet, "SHOULD" is often extended to "SHOULD= ...unless..." to cover exceptions, especially when those exceptions result = in downgrading a MUST to a SHOULD, so I think if you were to cover it this = way, the MUST will become unnecessary. > > 10 - rationale for community scrubbing recommendation? > > Well from past experience we've seen that when communities are > intentionnaly removed by upstreams it is often annoying for someone. We > just want to recall that unless necessary communities should not be > manipulated without caution. [WEG] Sure. I wasn't questioning the recommendation, I was more pointing ou= t that some rationale explaining why you recommend this would be helpful wi= thin the document, especially to put it into the context of the security co= nsiderations of removing or leaving communities in place. > > > Anything below this line has been added by my company's mail server, I have= no control over it. ----------------- This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From cpignata@cisco.com Sun Jul 28 14:01:25 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 4480821F9E6C for ; Sun, 28 Jul 2013 14:01:25 -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=[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 8sFsxKYnDUX1 for ; Sun, 28 Jul 2013 14:01:20 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 473FB21F9E76 for ; Sun, 28 Jul 2013 14:01:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5152; q=dns/txt; s=iport; t=1375045269; x=1376254869; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/Bth86h589eup4SXGPsHqw+ila11CdP34MvKKH35leM=; b=Lcb0Kw/mJGRt6uIZnO8ml/Tf6/r+rkba7WA+ckgoTQDBxywihncYAls1 bzNk229aBMton8s0GMJDWoll2CeEfFISApriBtJPuGXOFCwqc63LcWGHQ ltA9Hd7G8SBDbT1eK61zZiYfhAOGOUMocqr3gWtpAbZLv/XQkmQdR9LO0 Y=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAKuF9VGtJV2b/2dsb2JhbABbgwY1Sga9UoEXFnSCJAEBAQMBAQEBawsQAgEIGAokIQYBCiUCBA4FCAEFC4dlAwkGBwWuKg2IXo0VgjcxB4MWbwOQEoEtg1legxKKfYUmgxSCKg X-IronPort-AV: E=Sophos;i="4.89,764,1367971200"; d="asc'?scan'208";a="240560225" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 28 Jul 2013 21:01:08 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6SL18TC014618 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 28 Jul 2013 21:01:08 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.29]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Sun, 28 Jul 2013 16:01:07 -0500 From: "Carlos Pignataro (cpignata)" To: Warren Kumari Thread-Topic: [OPSEC] Review of: draft-ietf-opsec-ip-options-filtering-02 Thread-Index: AQHOe+pau4UDPw83oEGNf2neu7CvGJlcvOiAgAAZWwCAB07TgIAW4g4A Date: Sun, 28 Jul 2013 21:01:07 +0000 Message-ID: <95067C434CE250468B77282634C96ED322D5E9F0@xmb-aln-x02.cisco.com> References: <60119.1373294971@sonic.net> <1565B7C7-E70B-4645-971E-421CE90B27E4@gmail.com> <95067C434CE250468B77282634C96ED322CD0A9C@xmb-aln-x02.cisco.com> <4DAFAE6C-C7A1-4BB2-B70A-F727DCE6F847@kumari.net> In-Reply-To: <4DAFAE6C-C7A1-4BB2-B70A-F727DCE6F847@kumari.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.106.13] Content-Type: multipart/signed; boundary="Apple-Mail=_63889E5E-F343-4287-BEAE-1625321FFA27"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "" , RJ Atkinson 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: Sun, 28 Jul 2013 21:01:25 -0000 --Apple-Mail=_63889E5E-F343-4287-BEAE-1625321FFA27 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Warren, On Jul 14, 2013, at 9:34 AM, Warren Kumari wrote: >=20 > On Jul 9, 2013, at 11:58 AM, Carlos Pignataro (cpignata) = wrote: >=20 >> WG, >>=20 >> I just posted a new revision, intended to address all WGLC comments = on this document. >=20 > >=20 > Thank you.=20 >=20 > We have discussed this and judge there to be consensus to progress = this. Thanks. All the WGLC comments were resolved with revision -04 posted on = July 11th. Do you have a target for when the doc will be sent to the IESG? -- Carlos. >=20 > We would also like to apologize for how long it took to complete this = WGLC, and thank the authors (and WG) for their patience. We have / will = be making some changes to streamline things, and hopefully prevent long = delays in the future. >=20 >=20 > W > >=20 >>=20 >> You can find it at = http://tools.ietf.org/html/draft-ietf-opsec-ip-options-filtering-03. >> You can also find diffs from the previous version at = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-ip-options-filtering-0= 3 >>=20 >> This new revision incorporates resolution to all comments, especially = from Arturo and Merike, as well as the text below. It also incorporates = a number of editorial (typographical, grammar) fixes. Hopefully we have = not missed anything. >>=20 >> Please review. >>=20 >> Thanks! >>=20 >> -- Carlos. >>=20 >> On Jul 9, 2013, at 10:27 AM, RJ Atkinson wrote: >>=20 >>> All, >>>=20 >>> Here is some candidate text to replace the indented text >>> in Sections 4.12.2 & 4.13.2, leveraging Merike's suggested=20 >>> introduction, and restoring (with minor edits) the previous=20 >>> language: >>>=20 >>> Some private IP networks consider IP router-based >>> per-interface selective filtering of packets based=20 >>> on (a) the presence of an IPSO option (including BSO=20 >>> and ESO) and (b) based on the contents of that IPSO=20 >>> option to be important for operational security reasons. >>> The recent IPv6 CALIPSO option specification discusses >>> this in additional detail, albeit in an IPv6 context.=20 >>> [RFC5570] >>>=20 >>> Such private IP networks commonly are built using both >>> commercial and open-source products - for hosts, guards, >>> firewalls, switches, routers, etc. Some commercial IP >>> routers support this option, as do some IP routers which=20 >>> are built on top of Multi-Level Secure (MLS) operating=20 >>> systems (e.g. on top of Trusted Solaris [Solaris2008] or=20 >>> Security-Enhanced Linux [SELinux2008]). >>>=20 >>> For example, many Cisco routers that run Cisco IOS include=20 >>> support for selectively filtering packets that contain the >>> IP Security Options (IPSO) with per-interface granularity. =20 >>> This capability has been present in many Cisco routers=20 >>> since the early 1990s [Cisco-IPSO-Cmds]. Some government=20 >>> sector products reportedly also support the IP Security=20 >>> Options (IPSO), for example CANEWARE [RFC4949]. =20 >>>=20 >>> Support for the IPSO Basic Security Option also is=20 >>> included in the "IPsec Configuration Policy Information=20 >>> Model" [RFC3585] and in the "IPsec Security Policy=20 >>> Database Configuration MIB" [RFC4807]. Section 4.6.1 >>> of the IP Security Domain of Interpretation [RFC2407] >>> includes support for labeled IPsec security associations >>> compatible with the IP Security Options. >>>=20 >>> I'm greatly obliged to Merike for her suggested text,=20 >>> which is included in the proposed revised text above, >>> and to Arturo for agreeing that an edited version of=20 >>> the original text could be retained in this document. >>>=20 >>>=20 >>> Yours, >>>=20 >>> Ran Atkinson >>>=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 > -- > "Build a man a fire, and he'll be warm for a day. Set a man on fire, = and he'll be warm for the rest of his life." -- Terry Pratchett >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec --Apple-Mail=_63889E5E-F343-4287-BEAE-1625321FFA27 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlH1hpIACgkQtfDPGTp3USyRFgCfXK+qq6zCYM5IhsdNhQd82ZVi rJkAn1zBy851rs2TJMGYKccpblIGGtUX =+6ey -----END PGP SIGNATURE----- --Apple-Mail=_63889E5E-F343-4287-BEAE-1625321FFA27-- From kkumar@google.com Sun Jul 28 20:22:58 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 4CAE921F9EF0 for ; Sun, 28 Jul 2013 20:22:58 -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 pc77OpMKFHIy for ; Sun, 28 Jul 2013 20:22:57 -0700 (PDT) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 3247721F9DFB for ; Sun, 28 Jul 2013 20:22:57 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id j6so2391477oag.14 for ; Sun, 28 Jul 2013 20:22:56 -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=QTPJMdzPFMbHGIQpq/klb8HGY7n1jW+Z1ptKspa3RYU=; b=ZaElagR+RfBvm/hirDw508eeMhvYVpj7a2Z4TZJqMatp4gKZvqFPKtU3wgMwoTHvzo 0IM5S75JlVbqS6YDDGCzOCgfT4+cND+OmBA8S7XDMLFeBXziwllN8UXbhKinI8sFnY7I 6IcZduXTVPaA//iNBrV6c9Fc5qaBEMZpsz+M5sDzDPAO9WVwP7sPPzB89a4GAq37v/Hy YtRwkUENmz0aoZ64zDFL8t01F08njCjr8Nz1hRPBXCn9WQRrW0PpA23Bmh8BmUjzB5u+ fWmX5pCDZESynORfYs9DuNfvFO8beU5F7pnheo5znfgIQBQ2KYf+IJpLaoemE+XEtEUM n4Xg== 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=QTPJMdzPFMbHGIQpq/klb8HGY7n1jW+Z1ptKspa3RYU=; b=O0zp0b8hvnDexeolN9GLHYJ8XTkdmNUAcFVQY7hB0KfEjUrnrYqXV2p56lGU39DOif pR2GABmbIHIwSgzG+uKe2kPD2STGEdUC4ONv0BzBGMKfWugHfmW/DU/Yy3q4Akgzlt8H GonhKU5hevb95XsMjAhZK1SNt9YJvBEkQurNr9sP0ayj2lSmN8HOZQQFXmyPA7AM0dCQ 90rrqvpFeIZJ5lI9HAof0OCCblWzpE8WcKTrWp2BmdIbYbZXr9nFU+1ztALAq+2Uh3Id 7rG1M3aa8BBcJykwtMcF5fvhEE4bUZSMfHwnlEZ6S7yAeuc167DYzzHca0n3uDB5e82u H5ow== X-Received: by 10.42.73.66 with SMTP id r2mr22041112icj.9.1375068176398; Sun, 28 Jul 2013 20:22:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.31.161 with HTTP; Sun, 28 Jul 2013 20:22:36 -0700 (PDT) In-Reply-To: <95067C434CE250468B77282634C96ED322D5E9F0@xmb-aln-x02.cisco.com> References: <60119.1373294971@sonic.net> <1565B7C7-E70B-4645-971E-421CE90B27E4@gmail.com> <95067C434CE250468B77282634C96ED322CD0A9C@xmb-aln-x02.cisco.com> <4DAFAE6C-C7A1-4BB2-B70A-F727DCE6F847@kumari.net> <95067C434CE250468B77282634C96ED322D5E9F0@xmb-aln-x02.cisco.com> From: KK Date: Sun, 28 Jul 2013 20:22:36 -0700 Message-ID: To: "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=90e6ba615234325dc604e29e02a8 X-Gm-Message-State: ALoCoQmaXzT8MwvNDottKInXY8w/+6i8IBtjYtOVkDZQO70jqsSDgIqAL6dkrMPw5pVsAzLPSdNCFYDfmdnD2bMZQwjMnncwbhaICsFOUJKL9shyO43bbZ7KINIhWdL6yXibA4y0Jomi5rxQFJVcol1HooxXX7oL4iY6N2su80q3Ksh8VIYecr8A8JCPBN4wLFKYzsrPgrhS Cc: RJ Atkinson , "" , 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, 29 Jul 2013 03:22:58 -0000 --90e6ba615234325dc604e29e02a8 Content-Type: text/plain; charset=ISO-8859-1 Hi Carlos, I have the shepherd write-up almost ready to be shipped out. My plan is to do it this week. Thanks you for your patience. Regards, KK On Sun, Jul 28, 2013 at 2:01 PM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Warren, > > On Jul 14, 2013, at 9:34 AM, Warren Kumari wrote: > > > > > On Jul 9, 2013, at 11:58 AM, Carlos Pignataro (cpignata) < > cpignata@cisco.com> wrote: > > > >> WG, > >> > >> I just posted a new revision, intended to address all WGLC comments on > this document. > > > > > > > > Thank you. > > > > We have discussed this and judge there to be consensus to progress this. > > Thanks. All the WGLC comments were resolved with revision -04 posted on > July 11th. > > Do you have a target for when the doc will be sent to the IESG? > > -- Carlos. > > > > > We would also like to apologize for how long it took to complete this > WGLC, and thank the authors (and WG) for their patience. We have / will be > making some changes to streamline things, and hopefully prevent long delays > in the future. > > > > > > W > > > > > >> > >> You can find it at > http://tools.ietf.org/html/draft-ietf-opsec-ip-options-filtering-03. > >> You can also find diffs from the previous version at > http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-ip-options-filtering-03 > >> > >> This new revision incorporates resolution to all comments, especially > from Arturo and Merike, as well as the text below. It also incorporates a > number of editorial (typographical, grammar) fixes. Hopefully we have not > missed anything. > >> > >> Please review. > >> > >> Thanks! > >> > >> -- Carlos. > >> > >> On Jul 9, 2013, at 10:27 AM, RJ Atkinson wrote: > >> > >>> All, > >>> > >>> Here is some candidate text to replace the indented text > >>> in Sections 4.12.2 & 4.13.2, leveraging Merike's suggested > >>> introduction, and restoring (with minor edits) the previous > >>> language: > >>> > >>> Some private IP networks consider IP router-based > >>> per-interface selective filtering of packets based > >>> on (a) the presence of an IPSO option (including BSO > >>> and ESO) and (b) based on the contents of that IPSO > >>> option to be important for operational security reasons. > >>> The recent IPv6 CALIPSO option specification discusses > >>> this in additional detail, albeit in an IPv6 context. > >>> [RFC5570] > >>> > >>> Such private IP networks commonly are built using both > >>> commercial and open-source products - for hosts, guards, > >>> firewalls, switches, routers, etc. Some commercial IP > >>> routers support this option, as do some IP routers which > >>> are built on top of Multi-Level Secure (MLS) operating > >>> systems (e.g. on top of Trusted Solaris [Solaris2008] or > >>> Security-Enhanced Linux [SELinux2008]). > >>> > >>> For example, many Cisco routers that run Cisco IOS include > >>> support for selectively filtering packets that contain the > >>> IP Security Options (IPSO) with per-interface granularity. > >>> This capability has been present in many Cisco routers > >>> since the early 1990s [Cisco-IPSO-Cmds]. Some government > >>> sector products reportedly also support the IP Security > >>> Options (IPSO), for example CANEWARE [RFC4949]. > >>> > >>> Support for the IPSO Basic Security Option also is > >>> included in the "IPsec Configuration Policy Information > >>> Model" [RFC3585] and in the "IPsec Security Policy > >>> Database Configuration MIB" [RFC4807]. Section 4.6.1 > >>> of the IP Security Domain of Interpretation [RFC2407] > >>> includes support for labeled IPsec security associations > >>> compatible with the IP Security Options. > >>> > >>> I'm greatly obliged to Merike for her suggested text, > >>> which is included in the proposed revised text above, > >>> and to Arturo for agreeing that an edited version of > >>> the original text could be retained in this document. > >>> > >>> > >>> Yours, > >>> > >>> Ran Atkinson > >>> > >>> > >>> _______________________________________________ > >>> OPSEC mailing list > >>> OPSEC@ietf.org > >>> https://www.ietf.org/mailman/listinfo/opsec > >> > >> _______________________________________________ > >> OPSEC mailing list > >> OPSEC@ietf.org > >> https://www.ietf.org/mailman/listinfo/opsec > >> > > > > -- > > "Build a man a fire, and he'll be warm for a day. Set a man on fire, and > he'll be warm for the rest of his life." -- Terry Pratchett > > > > > > _______________________________________________ > > OPSEC mailing list > > OPSEC@ietf.org > > https://www.ietf.org/mailman/listinfo/opsec > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > > --90e6ba615234325dc604e29e02a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Carlos,

I have the shepherd write-up= almost ready to be shipped out. My plan is to do it this week.
<= br>
Thanks you for your patience.

Regards,
KK

On Sun, Jul 28, 2013 at 2:01 PM, Carlos Pignat= aro (cpignata) <cpignata@cisco.com> wrote:
Warren,

On Jul 14, 2013, at 9:34 AM, Warren Kumari <warren@kumari.net> wrote:

>
> On Jul 9, 2013, at 11:58 AM, Carlos Pignataro (cpignata) &l= t;cpignata@cisco.co= m> wrote:
>
>> WG,
>>
>> I just posted a new revision, intended to address all WGLC comment= s on this document.
>
> <chair hat>
>
> Thank you.
>
> We have discussed this and judge there to be consensus to progress thi= s.

Thanks. All the WGLC comments were resolved with revision -04 posted = on July 11th.

Do you have a target for when the doc will be sent to the IESG?

-- Carlos.

>
> We would also like to apologize for how long it took to complete this = WGLC, and thank the authors (and WG) for their patience. We have / will be = making some changes to streamline things, and hopefully prevent long delays= in the future.
>
>
> W
> </chair hat>
>
>>
>> You can find it at http://tools.ietf.org/ht= ml/draft-ietf-opsec-ip-options-filtering-03.
>> You can also find diffs from the previous version at http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-ip-op= tions-filtering-03
>>
>> This new revision incorporates resolution to all comments, especia= lly from Arturo and Merike, as well as the text below. It also incorporates= a number of editorial (typographical, grammar) fixes. Hopefully we have no= t missed anything.
>>
>> Please review.
>>
>> Thanks!
>>
>> -- Carlos.
>>
>> On Jul 9, 2013, at 10:27 AM, RJ Atkinson <rja.lists@gmail.com> wrote:
>>
>>> All,
>>>
>>> Here is some candidate text to replace the indented text
>>> in Sections 4.12.2 & 4.13.2, leveraging Merike's sugge= sted
>>> introduction, and restoring (with minor edits) the previous >>> language:
>>>
>>> =A0 =A0 Some private IP networks consider IP router-based
>>> =A0 =A0 per-interface selective filtering of packets based
>>> =A0 =A0 on (a) the presence of an IPSO option (including BSO >>> =A0 =A0 and ESO) and (b) based on the contents of that IPSO >>> =A0 =A0 option to be important for operational security reason= s.
>>> =A0 =A0 The recent IPv6 CALIPSO option specification discusses=
>>> =A0 =A0 this in additional detail, albeit in an IPv6 context.<= br> >>> =A0 =A0 [RFC5570]
>>>
>>> =A0 =A0 Such private IP networks commonly are built using both=
>>> =A0 =A0 commercial and open-source products - for hosts, guard= s,
>>> =A0 =A0 firewalls, switches, routers, etc. =A0Some commercial = IP
>>> =A0 =A0 routers support this option, as do some IP routers whi= ch
>>> =A0 =A0 are built on top of Multi-Level Secure (MLS) operating=
>>> =A0 =A0 systems (e.g. on top of Trusted Solaris [Solaris2008] = or
>>> =A0 =A0 Security-Enhanced Linux [SELinux2008]).
>>>
>>> =A0 =A0 For example, many Cisco routers that run Cisco IOS inc= lude
>>> =A0 =A0 support for selectively filtering packets that contain= the
>>> =A0 =A0 IP Security Options (IPSO) with per-interface granular= ity.
>>> =A0 =A0 This capability has been present in many Cisco routers=
>>> =A0 =A0 since the early 1990s [Cisco-IPSO-Cmds]. =A0Some gover= nment
>>> =A0 =A0 sector products reportedly also support the IP Securit= y
>>> =A0 =A0 Options (IPSO), for example CANEWARE [RFC4949].
>>>
>>> =A0 =A0 Support for the IPSO Basic Security Option also is
>>> =A0 =A0 included in the "IPsec Configuration Policy Infor= mation
>>> =A0 =A0 Model" [RFC3585] and in the "IPsec Security = Policy
>>> =A0 =A0 Database Configuration MIB" [RFC4807]. =A0Section= 4.6.1
>>> =A0 =A0 of the IP Security Domain of Interpretation [RFC2407]<= br> >>> =A0 =A0 includes support for labeled IPsec security associatio= ns
>>> =A0 =A0 compatible with the IP Security Options.
>>>
>>> I'm greatly obliged to Merike for her suggested text,
>>> which is included in the proposed revised text above,
>>> and to Arturo for agreeing that an edited version of
>>> the original text could be retained in this document.
>>>
>>>
>>> Yours,
>>>
>>> Ran Atkinson
>>>
>>>
>>> _______________________________________________
>>> OPSEC mailing list
>>> OPSEC@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/opsec
>>
>> _______________________________________________
>> OPSEC mailing list
>> OPSEC@ietf.org=
>> https://www.ietf.org/mailman/listinfo/opsec
>>
>
> --
> "Build a man a fire, and he'll be warm for a day. Set a man o= n fire, and he'll be warm for the rest of his life." -- Terry Prat= chett
>
>
> _______________________________________________
> OPSEC mailing list
> OPSEC@ietf.org=
> https://www.ietf.org/mailman/listinfo/opsec


_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/opsec


--90e6ba615234325dc604e29e02a8-- From joelja@bogus.com Sun Jul 28 22:51:29 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 7F7E621F9F8E for ; Sun, 28 Jul 2013 22:51:28 -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=[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 yUuKNlQDIFq1 for ; Sun, 28 Jul 2013 22:51:27 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id AD06221F99F2 for ; Sun, 28 Jul 2013 22:51:27 -0700 (PDT) Received: from dhcp-603a.meeting.ietf.org (dhcp-603a.meeting.ietf.org [130.129.96.58]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r6T5pOvU045057 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 29 Jul 2013 05:51:26 GMT (envelope-from joelja@bogus.com) Message-ID: <51F602DA.7060502@bogus.com> Date: Mon, 29 Jul 2013 07:51:22 +0200 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Thunderbird/23.0 MIME-Version: 1.0 To: "opsec@ietf.org" , draft-jdurand-bgp-security@tools.ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 29 Jul 2013 05:51:27 +0000 (UTC) Subject: [OPSEC] some thoughts on draft-jdurand-bgp-security-02.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: Mon, 29 Jul 2013 05:51:30 -0000 since this is on the agenda I'd thought I'd add some comments section-4 worth noting citing/rfc 6192 Protecting the Router Control Plane section 5.1.2.3 these sections are too deep. needs better organization, e.g. section 5 is actually probably two or three sessions. e.g. 5.1.1. Prefixes that MUST not be routed by definition Most of Regional Internet Registries do also operate an IRR and can control that registered routes conform to allocations made. 3 of 5 should cite http://tools.ietf.org/html/rfc4012 rpsl would be helpful to cite irrtoolset provide an example in an appendix. the tier one example isn't that helpful would be more interesting to cite the example for a customer vantge point e.g. managing objects so that your upstreams will accept them. ---- rpki section needs to be fleshed out e.g. what you do with it, how it's used what it can't be used for needs examples. The rest of this section assumes the reader understands all technologies associated with SIDR. Whut??????? 5.1.4 mixes customer prefixes filtering policy with local prefixes… issues around loop-detection (e.g. disconnected islands) vs more specific(s) e.g. hijacking. outbound filtering (prefix advertisement) 5.3 and later prefer to think of these things as import/export policy rather than describing everything as filter. 8. o Do not accept overly long AS path prepending from the customer. going to have to scope that. From rbonica@juniper.net Mon Jul 29 00:17: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 7800421F9AED for ; Mon, 29 Jul 2013 00:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.467 X-Spam-Level: X-Spam-Status: No, score=-100.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, 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 tHN3fbmqQp7P for ; Mon, 29 Jul 2013 00:17:21 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id D640E21F9B28 for ; Mon, 29 Jul 2013 00:17:17 -0700 (PDT) Received: from mail151-ch1-R.bigfish.com (10.43.68.253) by CH1EHSOBE019.bigfish.com (10.43.70.76) with Microsoft SMTP Server id 14.1.225.22; Mon, 29 Jul 2013 07:17:17 +0000 Received: from mail151-ch1 (localhost [127.0.0.1]) by mail151-ch1-R.bigfish.com (Postfix) with ESMTP id D09BA3200A0 for ; Mon, 29 Jul 2013 07:17:16 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(zzzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz17326ah1de096h18602eh8275dh1de097hz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail151-ch1: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=rbonica@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.237.149; KIP:(null); UIP:(null); (null); H:BY2PRD0511HT005.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail151-ch1 (localhost.localdomain [127.0.0.1]) by mail151-ch1 (MessageSwitch) id 1375082234285843_9403; Mon, 29 Jul 2013 07:17:14 +0000 (UTC) Received: from CH1EHSMHS008.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.254]) by mail151-ch1.bigfish.com (Postfix) with ESMTP id 34E442E004A for ; Mon, 29 Jul 2013 07:17:14 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.224.52) by CH1EHSMHS008.bigfish.com (10.43.70.8) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 29 Jul 2013 07:17:13 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMF02-SAC.jnpr.net (172.24.192.18) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 29 Jul 2013 00:17:11 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.3.146.0; Mon, 29 Jul 2013 00:17:10 -0700 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.182) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 29 Jul 2013 00:21:22 -0700 Received: from mail40-ch1-R.bigfish.com (10.43.68.229) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.22; Mon, 29 Jul 2013 07:17:10 +0000 Received: from mail40-ch1 (localhost [127.0.0.1]) by mail40-ch1-R.bigfish.com (Postfix) with ESMTP id CF7672E007A for ; Mon, 29 Jul 2013 07:17:09 +0000 (UTC) Received: from mail40-ch1 (localhost.localdomain [127.0.0.1]) by mail40-ch1 (MessageSwitch) id 1375082227676698_25631; Mon, 29 Jul 2013 07:17:07 +0000 (UTC) Received: from CH1EHSMHS031.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.244]) by mail40-ch1.bigfish.com (Postfix) with ESMTP id 96B04360048 for ; Mon, 29 Jul 2013 07:17:07 +0000 (UTC) Received: from BY2PRD0511HT005.namprd05.prod.outlook.com (157.56.237.149) by CH1EHSMHS031.bigfish.com (10.43.70.31) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 29 Jul 2013 07:17:07 +0000 Received: from BY2PRD0511MB428.namprd05.prod.outlook.com ([169.254.5.84]) by BY2PRD0511HT005.namprd05.prod.outlook.com ([10.255.129.40]) with mapi id 14.16.0341.000; Mon, 29 Jul 2013 07:17:06 +0000 From: Ronald Bonica To: "opsec@ietf.org" Thread-Topic: draft-jdurand-bgp-security-02 Thread-Index: Ac6MK5/WQi9kv0LRR+KCwOluP7GboQ== Date: Mon, 29 Jul 2013 07:17:05 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2512712A15@BY2PRD0511MB428.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [OPSEC] draft-jdurand-bgp-security-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, 29 Jul 2013 07:17:31 -0000 Folks, In Section 5.1.1.1, you say, "At the time of the writing of this document, = there is no dynamic IPv4 registry listing special prefixes and their status= on the internet." The IANA IPv4 Special-Purpose Address Registry was massi= vely updated on May 22, and you may want to leverage it. Please see http://= www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-regis= try.xhtml. -------------------------- Ron Bonica vcard: www.bonica.org/ron/ronbonica.vcf From ietf@meetecho.com Mon Jul 29 03:21:08 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 D109B21F9D6F for ; Mon, 29 Jul 2013 03:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.037 X-Spam-Level: *** X-Spam-Status: No, score=3.037 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, DATE_IN_FUTURE_06_12=1.897, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 dkhq2--K5tQp for ; Mon, 29 Jul 2013 03:21:04 -0700 (PDT) Received: from smtpdg7.aruba.it (smtpdg3.aruba.it [62.149.158.233]) by ietfa.amsl.com (Postfix) with ESMTP id 21B5221F9D5C for ; Mon, 29 Jul 2013 03:21:02 -0700 (PDT) Received: from meetecho ([130.129.6.44]) by smtpcmd03.ad.aruba.it with bizsmtp id 6ALz1m01R0wzZHu01AM0yd; Mon, 29 Jul 2013 12:21:00 +0200 Date: Mon, 29 Jul 2013 12:21:24 -0700 (PDT) From: Meetecho Team To: opsec@ietf.org Message-ID: <26800268.1.1375125684798.JavaMail.root@meetecho> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_0_12248553.1375125684777" Subject: [OPSEC] OPSEC session recording available 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, 29 Jul 2013 10:21:08 -0000 ------=_Part_0_12248553.1375125684777 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the OPSEC WG session at IETF 87 is available at the following URL: http://ietf87.conf.meetecho.com/index.php/Recorded_Sessions#OPSEC In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_0_12248553.1375125684777-- From maz@iij.ad.jp Tue Jul 30 06:05:57 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 995EA11E81CB for ; Tue, 30 Jul 2013 06:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 9YTbMNJL38fQ for ; Tue, 30 Jul 2013 06:05:53 -0700 (PDT) Received: from omgo.iij.ad.jp (mo30.iij.ad.jp [202.232.30.71]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED2A21F957B for ; Tue, 30 Jul 2013 06:05:53 -0700 (PDT) DKIM-Signature: v=1;a=rsa-sha256;c=relaxed/simple;d=iij.ad.jp;h=Date: Message-Id:To:Subject:From:In-Reply-To:References:Mime-Version:Content-Type: Content-Transfer-Encoding; i=maz@iij.ad.jp; s=omgo1; t=1375189551; x=1376399151; bh=Uxvb/5hrPqxx4ayHaV39ud2EN/0cMng6S7UBvfBrTCw=; b=sTHIL1y8W5OQu+1U8SQYV1g4WR4 Pe2o7XsyPIeOU3n8FkKwY5irbeGFf4PwONBmv9B6GQd+04vYGWpzcnFTwpyTOVGhTMQoNUe19tSWk WjMUGnqADq/OleEGZz5t8AN0aCwG9aeE0enHJR7/dQy38o8Gzi3s0uYdhgvWO7RGbQc=; Received: by omgo.iij.ad.jp (mo30) id r6UD5pDT012747; Tue, 30 Jul 2013 22:05:51 +0900 Date: Tue, 30 Jul 2013 22:05:15 +0900 (JST) Message-Id: <20130730.220515.204112887.maz@iij.ad.jp> To: opsec@ietf.org From: Matsuzaki Yoshinobu In-Reply-To: <20130714223439.21571.70821.idtracker@ietfa.amsl.com> References: <20130714223439.21571.70821.idtracker@ietfa.amsl.com> X-PGP-Fingerprint: 8E 9C EC 04 87 6B B5 0E 1B 6D 46 3B CB F7 72 CE X-PGP-Fingerprint-DSA: CCF0 9311 060F DD75 2B63 9578 7FED 4A9C 4DBF 0817 Organization: IIJ Network Engineering and Operations X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-bgp-security-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, 30 Jul 2013 13:05:57 -0000 Some comments about the prefix filtering to clarify use cases. As an AS operator, I always care about 1. bgp neighbor IP and 2. bgp nexthop (and routes used by bgp recursive route lookup) to protect our routing. For iBGP, "5.1.4. Filtering prefixes belonging to local AS" works well. Regarding eBGP, we peers with other ASes over IXPs and also private links. The IXP case is well documented at "5.1.5. Internet exchange point (IXP) LAN prefixes", but we also need to care about the private link prefixes, as sometimes these prefixes are assigned by peering partners. As we usually assign /30(IPv4) and /64, /126 or /127(IPv6) for those private links, we are protecting our network from unintended routing by denying too specifics described at "5.1.3. Prefixes too specific". Regards, ----- Matsuzaki Yoshinobu - IIJ/AS2497 INOC-DBA: 2497*629 internet-drafts@ietf.org wrote > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF. > > Title : BGP operations and security > Author(s) : Jerome Durand > Ivan Pepelnjak > Gert Doering > Filename : draft-ietf-opsec-bgp-security-01.txt > Pages : 26 > Date : 2013-07-14 > > Abstract: > BGP (Border Gateway Protocol) is the protocol almost exclusively used > in the Internet to exchange routing information between network > domains. Due to this central nature, it's important to understand > the security measures that can and should be deployed to prevent > accidental or intentional routing disturbances. > > This document describes measures to protect the BGP sessions itself > (like TTL, MD5, control plane filtering) and to better control the > flow of routing information, using prefix filtering and > automatization of prefix filters, max-prefix filtering, AS path > filtering, route flap dampening and BGP community scrubbing. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-opsec-bgp-security > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-opsec-bgp-security-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-bgp-security-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From jacques.latour@cira.ca Tue Jul 30 09:12:41 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 309B921F99A9 for ; Tue, 30 Jul 2013 09:12:41 -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 9BySMApGs2+J for ; Tue, 30 Jul 2013 09:12:36 -0700 (PDT) Received: from office-mx.cira.ca (office-smtp.cira.ca [192.228.22.119]) by ietfa.amsl.com (Postfix) with ESMTP id AF08C21E80CC for ; Tue, 30 Jul 2013 09:12:35 -0700 (PDT) Received: from office-mx0 (office-mx0 [127.0.0.1]) by office-mx.cira.ca (Postfix) with SMTP id 2565E13FB02; Tue, 30 Jul 2013 12:11:46 -0400 (EDT) Received: from mbxhub.cira.ca (mbxhub.cira.ca [192.228.22.115]) by office-mx.cira.ca (Postfix) with ESMTP id 717A613FB02; Tue, 30 Jul 2013 12:11:45 -0400 (EDT) Received: from MBX01.cira1.cira.ca ([10.2.16.30]) by exch-hub.cira1.cira.ca ([10.2.16.28]) with mapi; Tue, 30 Jul 2013 12:11:45 -0400 From: Jacques Latour To: Matsuzaki Yoshinobu , "opsec@ietf.org" Date: Tue, 30 Jul 2013 12:11:44 -0400 Thread-Topic: [OPSEC] I-D Action: draft-ietf-opsec-bgp-security-01.txt Thread-Index: Ac6NJY8xQ+6IvuxsSWSABnP51N0w2gAGdcqQ Message-ID: References: <20130714223439.21571.70821.idtracker@ietfa.amsl.com> <20130730.220515.204112887.maz@iij.ad.jp> In-Reply-To: <20130730.220515.204112887.maz@iij.ad.jp> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-VAMS: NONE Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-bgp-security-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, 30 Jul 2013 16:12:41 -0000 Page 24 - incorrect reference [34] , "IANA IPv4 Special Purpose Address Registry", , . > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of > Matsuzaki Yoshinobu > Sent: July-30-13 9:05 AM > To: opsec@ietf.org > Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-bgp-security-01.txt >=20 > Some comments about the prefix filtering to clarify use cases. >=20 > As an AS operator, I always care about 1. bgp neighbor IP and 2. bgp next= hop > (and routes used by bgp recursive route lookup) to protect our routing. >=20 > For iBGP, "5.1.4. Filtering prefixes belonging to local AS" works well. = Regarding > eBGP, we peers with other ASes over IXPs and also private links. The IXP= case is > well documented at "5.1.5. Internet exchange point (IXP) LAN prefixes", b= ut we > also need to care about the private link prefixes, as sometimes these pre= fixes > are assigned by peering partners. >=20 > As we usually assign /30(IPv4) and /64, /126 or /127(IPv6) for those priv= ate > links, we are protecting our network from unintended routing by denying t= oo > specifics described at "5.1.3. Prefixes too specific". >=20 > Regards, > ----- > Matsuzaki Yoshinobu > - IIJ/AS2497 INOC-DBA: 2497*629 >=20 >=20 > internet-drafts@ietf.org wrote > > > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > > This draft is a work item of the Operational Security Capabilities for= IP > Network Infrastructure Working Group of the IETF. > > > > Title : BGP operations and security > > Author(s) : Jerome Durand > > Ivan Pepelnjak > > Gert Doering > > Filename : draft-ietf-opsec-bgp-security-01.txt > > Pages : 26 > > Date : 2013-07-14 > > > > Abstract: > > BGP (Border Gateway Protocol) is the protocol almost exclusively use= d > > in the Internet to exchange routing information between network > > domains. Due to this central nature, it's important to understand > > the security measures that can and should be deployed to prevent > > accidental or intentional routing disturbances. > > > > This document describes measures to protect the BGP sessions itself > > (like TTL, MD5, control plane filtering) and to better control the > > flow of routing information, using prefix filtering and > > automatization of prefix filters, max-prefix filtering, AS path > > filtering, route flap dampening and BGP community scrubbing. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-opsec-bgp-security > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-opsec-bgp-security-01 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-bgp-security-01 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > OPSEC mailing list > > OPSEC@ietf.org > > https://www.ietf.org/mailman/listinfo/opsec > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From jerduran@cisco.com Tue Jul 30 14:38:35 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 1F9EB21E809F for ; Tue, 30 Jul 2013 14:38:35 -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 CwH5TaNbi7Ex for ; Tue, 30 Jul 2013 14:38:30 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 375AA21E8092 for ; Tue, 30 Jul 2013 14:38:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=978; q=dns/txt; s=iport; t=1375220310; x=1376429910; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PNkUYQ69QsvAF7GWRUp7eI1reXs3ZOgfbAmh7Ec7D3c=; b=XW5J0UoufW9pXueXZ0FICgv5sCsd+oAcPuWTjRDu99XYPyyRZwMrjFuL AjStAXkk9amb03viGmCp2Ioc2M69u1iBL3kQ6epcb8ODmH9Z6U/RrD7nh AVADe1cwEJnCxGUr2wnNn8kNp4pXlbHj5L5HJSXWFMmPDg0OPB2GmX5r8 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0FAJMx+FGtJV2b/2dsb2JhbABbgwY1gxm7T4EfFnSCJAEBAQMBAQEBRiULBQsCAQgOOCcLJQIEDgUJiAEGDLhSj0szB4MYcQOIco5tkUyDFA X-IronPort-AV: E=Sophos;i="4.89,781,1367971200"; d="scan'208";a="241503725" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 30 Jul 2013 21:38:29 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6ULcTts012726 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jul 2013 21:38:29 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.104]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Tue, 30 Jul 2013 16:38:28 -0500 From: "Jerome Durand (jerduran)" To: Ronald Bonica Thread-Topic: [OPSEC] draft-jdurand-bgp-security-02 Thread-Index: AQHOjW0gJQIzrDRDZU2GKpFBwl05Lg== Date: Tue, 30 Jul 2013 21:38:27 +0000 Message-ID: <404D99FF-C2B6-47F2-A849-24E870D226F9@cisco.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2512712A15@BY2PRD0511MB428.namprd05.prod.outlook.com> In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2512712A15@BY2PRD0511MB428.namprd05.prod.outlook.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsec@ietf.org" Subject: Re: [OPSEC] draft-jdurand-bgp-security-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: Tue, 30 Jul 2013 21:38:35 -0000 Hi Ron, Actually version -01 posted right before the deadline should now list the n= ew registry in that section. This registry is great and I hope new text is = fine. Thank you, Jerome Durand Le 29 juil. 2013 =E0 09:17, "Ronald Bonica" a =E9crit= : > Folks, >=20 > In Section 5.1.1.1, you say, "At the time of the writing of this document= , there is no dynamic IPv4 registry listing special prefixes and their stat= us on the internet." The IANA IPv4 Special-Purpose Address Registry was mas= sively updated on May 22, and you may want to leverage it. Please see http:= //www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-reg= istry.xhtml. >=20 >=20 >=20 > -------------------------- > Ron Bonica > vcard: www.bonica.org/ron/ronbonica.vcf >=20 >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec