From warren@kumari.net Sat Jun 2 13:43:52 2012 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 E01C621F859E; Sat, 2 Jun 2012 13:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Up-XVey0F2fk; Sat, 2 Jun 2012 13:43:52 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB6721F8599; Sat, 2 Jun 2012 13:43:51 -0700 (PDT) Received: from [192.168.100.40] (unknown [207.34.158.233]) by vimes.kumari.net (Postfix) with ESMTPSA id C6FD41B40819; Sat, 2 Jun 2012 16:43:50 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari X-Priority: 3 In-Reply-To: <016b01cd37fc$9e125420$4001a8c0@gateway.2wire.net> Date: Sat, 2 Jun 2012 16:43:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13205C286662DE4387D9AF3AC30EF456D76BA8836D@EMBX01-WF.jnpr.net> <016b01cd37fc$9e125420$4001a8c0@gateway.2wire.net> To: t.petch X-Mailer: Apple Mail (2.1278) Cc: grow@ietf.org, Warren Kumari , opsec@ietf.org Subject: Re: [OPSEC] [GROW] draft-ietf-grow-private-ip-sp-cores 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, 02 Jun 2012 20:43:53 -0000 --=20 A. No Q. Is it sensible to top-post? On May 22, 2012, at 5:23 AM, t.petch wrote: > ----- Original Message ----- > From: "Ronald Bonica" > To: ; > Sent: Thursday, May 17, 2012 5:11 PM >> Folks, >>=20 >> Thanks for introducing this document! >>=20 >> I would like to bring the authors' attention to the following > documents that are working in OPSEC: >>=20 >> - draft-behringer-lla-only >> - draft-baker-opsec-passive-ip-address >>=20 >> To some extent, draft-grow and draft-behringer are debating with one > another. While draft-baker is not directly involved in the debate, it = is > not uninvolved, either. It is a shame that the three documents are = being > considered in different WGs. >=20 > I think it a bigger shame that draft-ietf-grow-private-ip-sp-cores is > not in the RFC Editor queue awaiting publication! Ok, so I guess the obvious question here is -- *why* is this not in the = Ed queue (and please don't say "Because WGLC / LC hasn't happened yet, = dummy" :-)). I spent a little time going back through the archives, but suspect I'm = missing something / somethings (note: I have not read the meeting = minutes yet)=85 There seems to be very little discussion regarding this / these, but the = general impression I got was that the WG likes this draft and would like = a: it to subsume -beringer- or b: to simply get published. It was = unclear to me how many folk had read / supported the draft, but... I suspect that I'm missing some context / some off list discussions=85=20= Is this just a "someone needs to wave the WGLC wand" situation? W >=20 > It is a natural companion to RFC6598 and could have, should have, been > in the queue at the same time. This I-D was relevant when it was = first > written 2 years ago, and I see its relevance decreasing with time, as > people stumble over the mistakes that this I-D could have prevented. = It > has taken those 2 years to get this I-D IETF-ready, little has changed > in the content in that time, and it is time we got it out of the door. >=20 > Of course there is scope for improvement, there always is, but that is > an argument for never publishing anything. If the authors of the = other > I-Ds want to build on it, then of course they can produce a bis that > covers more, but let's publish what we have got. >=20 > Tom Petch >=20 >>=20 >> For the purpose of discussing these three documents, I think that a > little cross-posting is acceptable. >>=20 >> -------------------------- >> Ron Bonica >> vcard: www.bonica.org/ron/ronbonica.vcf >>=20 >>=20 >> _______________________________________________ >> GROW mailing list >> GROW@ietf.org >> https://www.ietf.org/mailman/listinfo/grow >>=20 >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec >=20 From christopher.morrow@gmail.com Tue Jun 5 11:09:44 2012 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 00A1F21F87C0; Tue, 5 Jun 2012 11:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8GcYFx+IGnd; Tue, 5 Jun 2012 11:09:43 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEB621F87B2; Tue, 5 Jun 2012 11:09:43 -0700 (PDT) Received: by yhq56 with SMTP id 56so4648683yhq.31 for ; Tue, 05 Jun 2012 11:09:43 -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:content-transfer-encoding; bh=trwMPAo/i+3S4YYKwRgdeVgyOKWIGzH1j1aNnpzyETs=; b=oazRPZXdtHlglvB66VyH+8nZBgnJPrjpNBJKLmK7bMbltqY76EvV//43pDwV1/dTGK CXh2g5N+jKmA7gdXl5ugT5S02qwdRVUawsMgc0pfyVJMIcnqZ/KeKgF6bTTwXZv2CCR4 H8k+4JkEo8Su5XVPRvuhGunPw6Au8CKZnEUPFn5FTHj0MhWIm/QiNA8DntT8hshkNjwC nujetaH7Zqlf9kiTGhwGZpnAY+xXjqTUvyv6ZQ+W338I2TeAXpG9w4GnIrdzYzvCQzlp aMgntkcyKRDX8zXVTSXSUx0iXKuRSEeSLVfi4gG1Qcp1zIV50mncGNModd94D91rHvVM dNEQ== MIME-Version: 1.0 Received: by 10.60.24.7 with SMTP id q7mr17515722oef.50.1338919782596; Tue, 05 Jun 2012 11:09:42 -0700 (PDT) Received: by 10.182.166.71 with HTTP; Tue, 5 Jun 2012 11:09:42 -0700 (PDT) In-Reply-To: References: <13205C286662DE4387D9AF3AC30EF456D76BA8836D@EMBX01-WF.jnpr.net> <016b01cd37fc$9e125420$4001a8c0@gateway.2wire.net> Date: Tue, 5 Jun 2012 14:09:42 -0400 Message-ID: From: Christopher Morrow To: Warren Kumari Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 05 Jun 2012 11:37:10 -0700 Cc: grow@ietf.org, opsec@ietf.org, "t.petch" Subject: Re: [OPSEC] [GROW] draft-ietf-grow-private-ip-sp-cores 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, 05 Jun 2012 18:09:44 -0000 On Sat, Jun 2, 2012 at 4:43 PM, Warren Kumari wrote: > > I suspect that I'm missing some context / some off list discussions=85 > > Is this just a "someone needs to wave the WGLC wand" situation? I believe my calendar failed me :( I think the WGLC finished with people's issues covered. let me go find the original thread and kick the can down the street. From christopher.morrow@gmail.com Tue Jun 5 11:12:36 2012 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 A595321F8735; Tue, 5 Jun 2012 11:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJFRK4z+0chU; Tue, 5 Jun 2012 11:12:36 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 12ADF21F8734; Tue, 5 Jun 2012 11:12:36 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so774862obb.31 for ; Tue, 05 Jun 2012 11:12:35 -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:content-transfer-encoding; bh=xVrymNq7RojGToynS9fk5S78V3Uip29HElTnGukJCjc=; b=VqWtccci6cXfbEQTbfiiNkQcr3oepD3ZnX7AB0/E10ZQTUbrY0zRs+EUYeCGmwndLL LtDnERnQky1BYK+V45wSMyYNG2FEW99Yl+X+SJN8LzYxLq1YLiaq/dFTZRtYDdJ1HePV KubLqxVF0umvUKBEME9NeiTD+Eef560zbP6PNcig4s9wxZTkheXvgt7H12CjF+du1vBK MHXD25EfBwIxLKswDw2R4tf8fcyIXTkyZiE/J8FaOwsP3h56L1mSpGT2EiipUhUwWN06 m+uRN4HLo9xpHKd5eMDLRogESO1DM0YtBZrc2I3knjJDeXK84kyjYqUfm8q0rXIwP0t7 iFLQ== MIME-Version: 1.0 Received: by 10.182.111.39 with SMTP id if7mr17439312obb.55.1338919955620; Tue, 05 Jun 2012 11:12:35 -0700 (PDT) Received: by 10.182.166.71 with HTTP; Tue, 5 Jun 2012 11:12:35 -0700 (PDT) In-Reply-To: References: <13205C286662DE4387D9AF3AC30EF456D76BA8836D@EMBX01-WF.jnpr.net> <016b01cd37fc$9e125420$4001a8c0@gateway.2wire.net> Date: Tue, 5 Jun 2012 14:12:35 -0400 Message-ID: From: Christopher Morrow To: Warren Kumari Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 05 Jun 2012 11:37:10 -0700 Cc: grow@ietf.org, opsec@ietf.org, "t.petch" Subject: Re: [OPSEC] [GROW] draft-ietf-grow-private-ip-sp-cores 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, 05 Jun 2012 18:12:36 -0000 On Tue, Jun 5, 2012 at 2:09 PM, Christopher Morrow wrote: > On Sat, Jun 2, 2012 at 4:43 PM, Warren Kumari wrote: >> >> I suspect that I'm missing some context / some off list discussions=85 >> >> Is this just a "someone needs to wave the WGLC wand" situation? > > I believe my calendar failed me :( I think the WGLC finished with > people's issues covered. oh, my calendar didn't fail me :( scheduling WGLC did. > let me go find the original thread and kick the can down the street. From warren@kumari.net Tue Jun 5 11:57:35 2012 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 E6C2B21F867A for ; Tue, 5 Jun 2012 11:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZMpOMGR7D9Y for ; Tue, 5 Jun 2012 11:57:35 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 2B65E21F86A1 for ; Tue, 5 Jun 2012 11:57:35 -0700 (PDT) Received: from dhcp-220-207.meetings.nanog.org (dhcp-220-207.meetings.nanog.org [199.187.220.207]) by vimes.kumari.net (Postfix) with ESMTPSA id DDEC91B40115; Tue, 5 Jun 2012 14:57:33 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <4FC7C0C2.9080708@juniper.net> Date: Tue, 5 Jun 2012 11:57:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55C66AF5-F84F-44BF-9972-8725244F3302@kumari.net> <4FC7C0C2.9080708@juniper.net> To: Dave Dugal X-Mailer: Apple Mail (2.1278) Cc: "opsec@ietf.org" , Warren Kumari Subject: Re: [OPSEC] Call for adoption of draft-gont-opsec-ip-options-filtering 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, 05 Jun 2012 18:57:36 -0000 On May 31, 2012, at 12:04 PM, Dave Dugal wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Hi Warren. >=20 > I have also read Fernando's draft and do see the value and benefit of > proposing a more granular approach to IP options filtering. Many > times, the only mitigation for a particular attack or issue is to drop > all optioned packets, which depending on configuration and topology > can do more harm than good. BCP'ing a more finely granular approach > is not without merit. >=20 > Should we adopt this draft, I do agree with previous comments that > perhaps more fine-tuning of recommended options, tradeoffs and caveats > is warranted, but that discussion can continue within the WG. >=20 > I support the adoption of this draft as an OPSEC working group = document. Great, thank you.. Anyone else? We only have another 2 or so days before the adoption call = closes, and I'd really like to see some more feedback, even a simple = "Support" or "No, worst idea ever!!!" W >=20 > - --- > Dave Dugal > Sr. Product Security Incident Wrangler >=20 >=20 > On 5/31/2012 9:42 AM, Warren Kumari proclaimed ... >> Dear Working Group, >>=20 >> We are now halfway through the call for adoption on this draft -- >> please take a moment to read and comment on if you support the >> adoption of this draft=85 >>=20 >> W On May 24, 2012, at 11:58 AM, Warren Kumari wrote: >>=20 >>> Dear Working Group, >>>=20 >>> This is to start a two week poll to adopt=20 >>> draft-gont-opsec-ip-options-filtering ( helpful link: >>> http://tools.ietf.org/html/draft-gont-opsec-ip-options-filtering-04) >>>=20 >>>=20 > as an OpSec Working Group draft. >>>=20 >>> Please send your comments to the OpSec list (opsec@ietf.org). >>>=20 >>> This adoption call closes on June 7th, 2012. >>>=20 >>> (This document was discussed in the Paris meeting, and not enough >>> people had read the document to be able to predict consensus. >>> Please take a moment (or 5) to read and comment. I should mention >>> that Memorial Day is coming up in the US soon -- there is nothing >>> quite so enjoyable as reading drafts on the beach -- try it!) >>>=20 >>> W >>>=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 >>=20 >> _______________________________________________ OPSEC mailing list=20 >> OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec >>=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (MingW32) >=20 > iEYEARECAAYFAk/HwMIACgkQh59lzatuAqXiuwCgtXDacC7wSx0gtdfC41JRXcJN > 03MAoPf9m5FVlWOrHlOJzsPrRI117UqR > =3DlEqG > -----END PGP SIGNATURE----- > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec >=20 -- What our ancestors would really be thinking, if they were alive today, = is: "Why is it so dark in here?" -- (Terry Pratchett, Pyramids) From Donald.Smith@CenturyLink.com Tue Jun 5 14:23:48 2012 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 D4EBF21F8853 for ; Tue, 5 Jun 2012 14:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6] 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 9vbkclLqBZi8 for ; Tue, 5 Jun 2012 14:23:47 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 9F96221F8841 for ; Tue, 5 Jun 2012 14:23:47 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id q55LNkQ5004017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jun 2012 15:23:46 -0600 (MDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 8A81E1E004E; Tue, 5 Jun 2012 15:23:41 -0600 (MDT) Received: from sudnp796.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 6BAC71E004D; Tue, 5 Jun 2012 15:23:41 -0600 (MDT) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id q55LNfwQ028271; Tue, 5 Jun 2012 15:23:41 -0600 (MDT) Received: from qtdenexhtm20.AD.QINTRA.COM (qtdenexhtm20.ad.qintra.com [151.119.91.229]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id q55LNe3f028265 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 5 Jun 2012 15:23:40 -0600 (MDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm20.AD.QINTRA.COM ([151.119.91.229]) with mapi; Tue, 5 Jun 2012 15:23:40 -0600 From: "Smith, Donald" To: Warren Kumari , Dave Dugal Content-Class: urn:content-classes:message Date: Tue, 5 Jun 2012 15:23:54 -0600 Thread-Topic: [OPSEC] Call for adoption of draft-gont-opsec-ip-options-filtering Thread-Index: Ac1DTRWiJPrfhqT2T3eziURuNO/lOQAE7dJSAAAtbFo= Message-ID: References: <55C66AF5-F84F-44BF-9972-8725244F3302@kumari.net> <4FC7C0C2.9080708@juniper.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-mimectl: Produced By Microsoft Exchange V8.3.105.0 Content-Type: multipart/alternative; boundary="_000_B8C643FFCA5D4AEEB946CC10701F8E5Dmimectl_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "opsec@ietf.org" Subject: Re: [OPSEC] Call for adoption of draft-gont-opsec-ip-options-filtering 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, 05 Jun 2012 21:23:49 -0000 --_000_B8C643FFCA5D4AEEB946CC10701F8E5Dmimectl_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This isn't quite correct. 4.3.4. Operational and Interoperability Impact if Blocked Network troubleshooting techniques that may employ the LSRR option (such as ping or traceroute) would break. Nevertheless, it should be noted that it is virtually impossible to use the LSRR option for troubleshooting, due to widespread dropping of packets that contain such option. 4.3.5. Advice Routers, security gateways, and firewalls SHOULD, by default, drop IP packets that contain an LSRR option. Most routers don't drop LSRR or SSRR they ignore them. no ip source-route d= rops that ip option towards the router itself it shouldn't afaik drop the p= ackets themselves. Now given that that is the default config for them and most other router ve= ndors I believe your correct in saying you can pretty safely drop these pac= kets. This also is incorrect as I understand it. 4.5.4. Operational and Interoperability Impact if Blocked Network troubleshooting techniques that may employ the RR option (such as ping with the RR option) would break. Nevertheless, it should be noted that it is virtually impossible to use such techniques due to widespread dropping of packets that contain RR options. 4.5.5. Advice Routers, security gateways, and firewalls SHOULD drop IP packets containing a Record Route option. While RR can be dropped it requires a 12.++ image to do options acls on a c= isco so that is "fairly" recent 8 years or so ago:) I don't know of many ISPs that drop RR. Feel free to correct me if someone knows of this being a common practice. This isn't the operational impact statement it is a security statement. 4.7.4. Operational and Interoperability Impact if Blocked No security issues are known for this option, other than the general security implications of IP options discussed in Section 3. This: 4.10.1. Uses This option and originally provided a mechanism to discover the Path- MTU. It is now obsolete. Should be this 4.10.1. Uses This option originally provided a mechanism to discover the Path- MTU. It is now obsolete. 4.18.4. Operational and Interoperability Impact if Blocked None. Rather then None as is used throughout the document how about "no known imp= act" or something along those lines? 4.23 doesn't include any specific adivse it does however point to other rfc= s with language on ignoring unknown options. I think we should make it a SHOULD drop but am open to discussion this furt= her. Lastly the "generic section 3" threat should probably be standardized you h= ave a couple of slightly different versions. 4.17.3. Threats There are no know threats arising from this option, other than the general security implications of IP options discussed in Section 3. 4.10.3. Threats No security issues are known for this option, other than the general security implications of IP options discussed in Section 3. Also support addoption once this issues can be worked out. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com ________________________________ From: opsec-bounces@ietf.org [opsec-bounces@ietf.org] On Behalf Of Warren K= umari [warren@kumari.net] Sent: Tuesday, June 05, 2012 12:57 PM To: Dave Dugal Cc: opsec@ietf.org; Warren Kumari Subject: Re: [OPSEC] Call for adoption of draft-gont-opsec-ip-options-filte= ring On May 31, 2012, at 12:04 PM, Dave Dugal wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Warren. > > I have also read Fernando's draft and do see the value and benefit of > proposing a more granular approach to IP options filtering. Many > times, the only mitigation for a particular attack or issue is to drop > all optioned packets, which depending on configuration and topology > can do more harm than good. BCP'ing a more finely granular approach > is not without merit. > > Should we adopt this draft, I do agree with previous comments that > perhaps more fine-tuning of recommended options, tradeoffs and caveats > is warranted, but that discussion can continue within the WG. > > I support the adoption of this draft as an OPSEC working group document. Great, thank you.. Anyone else? We only have another 2 or so days before the adoption call clo= ses, and I'd really like to see some more feedback, even a simple "Support"= or "No, worst idea ever!!!" W > > - --- > Dave Dugal > Sr. Product Security Incident Wrangler > > > On 5/31/2012 9:42 AM, Warren Kumari proclaimed ... >> Dear Working Group, >> >> We are now halfway through the call for adoption on this draft -- >> please take a moment to read and comment on if you support the >> adoption of this draft=85 >> >> W On May 24, 2012, at 11:58 AM, Warren Kumari wrote: >> >>> Dear Working Group, >>> >>> This is to start a two week poll to adopt >>> draft-gont-opsec-ip-options-filtering ( helpful link: >>> http://tools.ietf.org/html/draft-gont-opsec-ip-options-filtering-04) >>> >>> > as an OpSec Working Group draft. >>> >>> Please send your comments to the OpSec list (opsec@ietf.org). >>> >>> This adoption call closes on June 7th, 2012. >>> >>> (This document was discussed in the Paris meeting, and not enough >>> people had read the document to be able to predict consensus. >>> Please take a moment (or 5) to read and comment. I should mention >>> that Memorial Day is coming up in the US soon -- there is nothing >>> quite so enjoyable as reading drafts on the beach -- try it!) >>> >>> W >>> >>> -- With Feudalism, it's your Count that votes. >>> >>> >>> _______________________________________________ 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 >> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (MingW32) > > iEYEARECAAYFAk/HwMIACgkQh59lzatuAqXiuwCgtXDacC7wSx0gtdfC41JRXcJN > 03MAoPf9m5FVlWOrHlOJzsPrRI117UqR > =3DlEqG > -----END PGP SIGNATURE----- > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > -- What our ancestors would really be thinking, if they were alive today, is: = "Why is it so dark in here?" -- (Terry Pratchett, Pyramids) _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec ________________________________ This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. --_000_B8C643FFCA5D4AEEB946CC10701F8E5Dmimectl_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
This is= n't quite correct.
4.3.4. Operational and Interoperability Impact if Blocked

Network troubleshooting techniques that may employ the LSRR option
(such as ping or traceroute) would break. Neverthe= less, it should be
noted that it is virtually impossible to use the LSRR option for
troubleshooting, due to widespread dropping of packets that contain
such option.
4.3.5. Advice
Routers, security gateways, and firewalls SHOULD, by default, drop IP
packets that contain an LSRR option.
Most routers don't drop LSRR or SSRR they ignore them. no ip= source-route drops that ip option towards th= e router itself it shouldn't afaik drop the packets themselves.
Now given that that is the default config for= them and most other router vendors I believe your correct in saying you ca= n pretty safely drop these packets.
This also is incorrect as I understand it.
4.5.4. Operational and Interoperability Impact if Blocked
Network troubleshooting techniques that may employ the RR option
(such as ping with the RR option) would break. Nevertheless, it
should be noted that it is virtually impossible to use such
techniques due to widespread dropping of packets that contain RR
options.
4.5.5. Advice
Routers, security gateways, and firewalls SHOULD drop IP packets
containing a Record Route option.
While RR can be dropped it requires a 12.++ image = to do options acls on a cisco so that is "fairly" recent 8 years or so ago:) I don't know of many ISPs that drop RR.
Feel free to correct me if someone knows of this being a common practice. This isn't the operational impact statement it is a security statement.
4.7.4. Operational and Interoperability Impact if Blocked

No security issues are known for this option, other than the general
security implications of IP options discussed in Section 3.
This:
4.10.1. Uses

This option and originally provided a mechanism to discover the Path-
MTU. It is now obsolete.
Should be this
4.10.1. Uses

This option originally provided a mechanism to discover the Path-
MTU. It is now obsolete.
4.18.4. Operational and Interoperability Impact if Blocked
None.
Rather then None as is used throughout the document how about "no know= n impact" or something along those lines?
4.23 doesn't include any specific adivse it d= oes however point to other rfcs with language= on ignoring unknown options.
I think we should make it a SHOULD drop but am open to discussion this furt= her.
Lastly the "generic section 3" threat should pro= bably be standardized you have a couple of slightly different versions.
 
4.17.3.  Threats
   There are no know threats arising from this o= ption, other than the
   general security implications of IP options discussed in Secti= on 3.
4.10.3.  Threats
   No security issues are known for this option,= other than the general
   security implications of IP options discussed in Section 3.

Also support addoption once this issues can b= e worked out.
 
 
 
(coffee !=3D sleep) & (!coffee =3D=3D sleep)
 Donald.Sm= ith@qwest.com
From: opsec-bounc= es@ietf.org [opsec-bounces@ietf.org] On Behalf Of Warren Kumari [warren@kum= ari.net]
Sent: Tuesday, June 05, 2012 12:57 PM
To: Dave Dugal
Cc: opsec@ietf.org; Warren Kumari
Subject: Re: [OPSEC] Call for adoption of draft-gont-opsec-ip-option= s-filtering


On May 31, 2012, at 12:04 PM, Dave Dugal wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Warren.
>
> I have also read Fernando's draft and do see the value and benefit of<= br> > proposing a more granular approach to IP options filtering.  Many=
> times, the only mitigation for a particular attack or issue is to drop=
> all optioned packets, which depending on configuration and topology > can do more harm than good.  BCP'ing a more finely granular appro= ach
> is not without merit.
>
> Should we adopt this draft, I do agree with previous comments that
> perhaps more fine-tuning of recommended options, tradeoffs and caveats=
> is warranted, but that discussion can continue within the WG.
>
> I support the adoption of this draft as an OPSEC working group documen= t.

Great, thank you..

Anyone else? We only have another 2 or so days before the adoption call clo= ses, and I'd really like to see some more feedback, even a simple "Sup= port" or "No, worst idea ever!!!"

W


>
> - ---
> Dave Dugal
> Sr. Product Security Incident Wrangler
>
>
> On 5/31/2012 9:42 AM, Warren Kumari <warren@kumari.net> proclaim= ed ...
>> Dear Working Group,
>>
>> We are now halfway through the call for adoption on this draft --<= br> >> please take a moment to read and comment on if you support the
>> adoption of this draft=85
>>
>> W On May 24, 2012, at 11:58 AM, Warren Kumari wrote:
>>
>>> Dear Working Group,
>>>
>>> This is to start a two week poll to adopt
>>> draft-gont-opsec-ip-options-filtering ( helpful link:
>>> http://tools.ietf.org/html/draft-gont-opsec-ip-options-filtering-04) >>>
>>>
> as an OpSec Working Group draft.
>>>
>>> Please send your comments to the OpSec list (opsec@ietf.org).<= br> >>>
>>> This adoption call closes on June 7th, 2012.
>>>
>>> (This document was discussed in the Paris meeting, and not eno= ugh
>>> people had read the document to be able to predict consensus.<= br> >>> Please take a moment (or 5) to read and comment. I should ment= ion
>>> that Memorial Day is coming up in the US soon -- there is noth= ing
>>> quite so enjoyable as reading drafts on the beach -- try it!)<= br> >>>
>>> W
>>>
>>> -- With Feudalism, it's your Count that votes.
>>>
>>>
>>> _______________________________________________ OPSEC mailing<= br> >>> list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec
>>>
>>
>> _______________________________________________ OPSEC mailing list=
>> OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (MingW32)
>
> iEYEARECAAYFAk/HwMIACgkQh59lzatuAqXiuwCgtXDacC7wSx0gtdfC41JRXcJN
> 03MAoPf9m5FVlWOrHlOJzsPrRI117UqR
> =3DlEqG
> -----END PGP SIGNATURE-----
> _______________________________________________
> OPSEC mailing list
> OPSEC@ietf.org
> https://www.ietf.org/mailman/listinfo/opsec
>

--
What our ancestors would really be thinking, if they were alive today, is: = "Why is it so dark in here?"

    -- (Terry Pratchett, Pyramids)


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

This communication is the pr= operty of CenturyLink and may contain confidential or privileged informatio= n. Unauthorized use of this communication is strictly
prohibited and may be unlawful. If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy<= br> all copies of the communication and any attachments.
 --_000_B8C643FFCA5D4AEEB946CC10701F8E5Dmimectl_-- From pkampana@cisco.com Tue Jun 5 14:36:12 2012 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 70AE921F87E1 for ; Tue, 5 Jun 2012 14:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 In9O0l3yvmlR for ; Tue, 5 Jun 2012 14:36:11 -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 AF8B021F87B4 for ; Tue, 5 Jun 2012 14:36:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkampana@cisco.com; l=3553; q=dns/txt; s=iport; t=1338932171; x=1340141771; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=y18zTvna6p7ZT60xfAA599x8nIBB4OPZtAwKom0xYQM=; b=QKHKxwnGX4TBQiDPe0E0QeI4UdU/KgHXPhajhOQK3Kb9bD4ialGzrZyp ALgTXCLt9dYkuSCZ12AmKwt4UZJXcuvbvfxjNqSAkZhJnMZooS5QAZWhP 4Q3M8aKBXScxP8VNwG0IIuXf87VUM0NcjATHRxoRqxvRRfF380Wtm5G7r 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAIZ7zk+tJV2d/2dsb2JhbABFpU2OdYEHghgBAQEEAQEBBQoBCgsCEDQLDAEDAgkPAgQBAQEnBxkOHwkIAQEEEwsXh2kLlzefc4sThhkDjT2IbY0BgWaCfA X-IronPort-AV: E=Sophos;i="4.75,720,1330905600"; d="scan'208";a="89574406" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 05 Jun 2012 21:36:11 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q55LaBGr002076; Tue, 5 Jun 2012 21:36:11 GMT Received: from xmb-rcd-107.cisco.com ([72.163.62.149]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Jun 2012 16:36:10 -0500 Received: from WIN-ICH1QO6NCS6 ([10.150.28.193]) by xmb-rcd-107.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Jun 2012 16:36:10 -0500 Received: from WINICH1QO6NCS6 by WIN-ICH1QO6NCS6 (PGP Universal service); Tue, 05 Jun 2012 17:35:03 -0500 X-PGP-Universal: processed; by WIN-ICH1QO6NCS6 on Tue, 05 Jun 2012 17:35:03 -0500 From: "Panos Kampanakis" To: "'Warren Kumari'" References: <55C66AF5-F84F-44BF-9972-8725244F3302@kumari.net><4FC7C0C2.9080708@juniper.net> In-Reply-To: Date: Tue, 5 Jun 2012 17:35:01 -0400 Organization: Cisco Systems Inc. Message-ID: <00aa01cd4363$108976c0$319c6440$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1DTRVRbqb/Sv41T06S3poetfqy+gAFclYg Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us X-OriginalArrivalTime: 05 Jun 2012 21:36:10.0755 (UTC) FILETIME=[3967F530:01CD4363] Cc: opsec@ietf.org Subject: Re: [OPSEC] Call for adoption ofdraft-gont-opsec-ip-options-filtering 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, 05 Jun 2012 21:36:12 -0000 I also support the adoption of this as WG item. Panos -----Original Message----- From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of Warren Kumari Sent: Tuesday, June 05, 2012 2:58 PM To: Dave Dugal Cc: opsec@ietf.org; Warren Kumari Subject: Re: [OPSEC] Call for adoption ofdraft-gont-opsec-ip-options-filtering On May 31, 2012, at 12:04 PM, Dave Dugal wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Warren. > > I have also read Fernando's draft and do see the value and benefit of > proposing a more granular approach to IP options filtering. Many > times, the only mitigation for a particular attack or issue is to drop > all optioned packets, which depending on configuration and topology > can do more harm than good. BCP'ing a more finely granular approach > is not without merit. > > Should we adopt this draft, I do agree with previous comments that > perhaps more fine-tuning of recommended options, tradeoffs and caveats > is warranted, but that discussion can continue within the WG. > > I support the adoption of this draft as an OPSEC working group document. Great, thank you.. Anyone else? We only have another 2 or so days before the adoption call closes, and I'd really like to see some more feedback, even a simple "Support" or "No, worst idea ever!!!" W > > - --- > Dave Dugal > Sr. Product Security Incident Wrangler > > > On 5/31/2012 9:42 AM, Warren Kumari proclaimed ... >> Dear Working Group, >> >> We are now halfway through the call for adoption on this draft -- >> please take a moment to read and comment on if you support the >> adoption of this draft. >> >> W On May 24, 2012, at 11:58 AM, Warren Kumari wrote: >> >>> Dear Working Group, >>> >>> This is to start a two week poll to adopt >>> draft-gont-opsec-ip-options-filtering ( helpful link: >>> http://tools.ietf.org/html/draft-gont-opsec-ip-options-filtering-04) >>> >>> > as an OpSec Working Group draft. >>> >>> Please send your comments to the OpSec list (opsec@ietf.org). >>> >>> This adoption call closes on June 7th, 2012. >>> >>> (This document was discussed in the Paris meeting, and not enough >>> people had read the document to be able to predict consensus. >>> Please take a moment (or 5) to read and comment. I should mention >>> that Memorial Day is coming up in the US soon -- there is nothing >>> quite so enjoyable as reading drafts on the beach -- try it!) >>> >>> W >>> >>> -- With Feudalism, it's your Count that votes. >>> >>> >>> _______________________________________________ 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 >> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (MingW32) > > iEYEARECAAYFAk/HwMIACgkQh59lzatuAqXiuwCgtXDacC7wSx0gtdfC41JRXcJN > 03MAoPf9m5FVlWOrHlOJzsPrRI117UqR > =lEqG > -----END PGP SIGNATURE----- > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > -- What our ancestors would really be thinking, if they were alive today, is: "Why is it so dark in here?" -- (Terry Pratchett, Pyramids) _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From fernando.gont.netbook.win@gmail.com Tue Jun 5 18:18:21 2012 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 6168621F8570 for ; Tue, 5 Jun 2012 18:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 bm+QF7onWP9b for ; Tue, 5 Jun 2012 18:18:20 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id D79C121F856F for ; Tue, 5 Jun 2012 18:18:19 -0700 (PDT) Received: by yhq56 with SMTP id 56so4987372yhq.31 for ; Tue, 05 Jun 2012 18:18:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=6yp18K4/xxs3tDJkIaIHN1h/6Q34A2So0yU2hGrV5tA=; b=q1ZXudCxcKk4p84AsQwO/nwl4ftsS3l97I0tSCbvVE69Y3hi/WSoeiM+TzOf+Jq4s3 /sW5yhJ4Hl3BpaxeGSX75tLZklml2TEcVjS8AGEa6KuVbGye06gXAG2UjSbUl9jMvaKI /ydO9bEDKKW7AMO2Pz4GaP0wBNLWT5/FZ9OJnNF7OLdEQh1RlGu5NtyF9DUrOkm9Yh3U yRTdW5Ljbr59aRYfa2KS4FvAeYj/Tx7MA9GmCF+JzfxQkjxYERQx1mkp36xuG3lLYdXh JDWNVDMoSBBZmV4RFG0P135jhVwdms/0Lu4pbEzl/Bz6Jx/6wJFjkDkoULTR8mLY77Ni CXPA== Received: by 10.236.179.106 with SMTP id g70mr14133214yhm.53.1338945499028; Tue, 05 Jun 2012 18:18:19 -0700 (PDT) Received: from [192.168.123.103] ([186.134.29.236]) by mx.google.com with ESMTPS id y10sm662877yha.4.2012.06.05.18.18.11 (version=SSLv3 cipher=OTHER); Tue, 05 Jun 2012 18:18:17 -0700 (PDT) Sender: Fernando Gont Message-ID: <4FCEA796.1080107@gont.com.ar> Date: Tue, 05 Jun 2012 21:43:02 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Smith, Donald" References: <55C66AF5-F84F-44BF-9972-8725244F3302@kumari.net> <4FC7C0C2.9080708@juniper.net>, In-Reply-To: X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: "opsec@ietf.org" , Warren Kumari Subject: Re: [OPSEC] Call for adoption of draft-gont-opsec-ip-options-filtering 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, 06 Jun 2012 01:18:21 -0000 Hi, Donald, On 06/05/2012 06:23 PM, Smith, Donald wrote: > This isn't quite correct. 4.3.4. Operational and Interoperability > Impact if Blocked > > Network troubleshooting techniques that may employ the LSRRoption > (such as ping or traceroute) would break. Nevertheless, it should > be noted that it is virtually impossible to use the LSRRoption for > troubleshooting, due to widespread dropping of packets that > contain such option. 4.3.5. Advice Routers, security gateways, and > firewalls SHOULD, by default, drop IP packets that contain an > LSRRoption. Most routers don't drop LSRRor SSRRthey ignore them. no > ipsource-route drops that ipoption towards the router itself it > shouldn't afaikdrop the packets themselves. Now given that that is > the default configfor them and most other router vendors I believe > your correct in saying you can pretty safely drop these packets. Just double-checking: Is your argument that the advice is okay, but just that we should note that routers typically ignore this option rather than drop them. THat aside: Can anyone check the defaults for Ciscos and Junipers? > This also is incorrect as I understand it. 4.5.4. Operational and > Interoperability Impact if Blocked Network troubleshooting > techniques that may employ the RR option (such as ping with the RR > option) would break. Nevertheless, it should be noted that it is > virtually impossible to use such techniques due to widespread > dropping of packets that contain RR options. 4.5.5. Advice Routers, > security gateways, and firewalls SHOULD drop IP packets containing > a Record Route option. While RR can be dropped it requires a 12.++ > image to do options aclson a ciscoso that is "fairly" recent 8 > years or so ago:) I don't know of many ISPs that drop RR. Feel free > to correct me if someone knows of this being a common practice. As with the other one, can folks provide input on this one? > This isn't the operational impact statement it is a security > statement. 4.7.4. Operational and Interoperability Impact if > Blocked > > No security issues are known for this option, other than the > general security implications of IP options discussed in Section > 3. Will fix this one. > This: 4.10.1. Uses > > This option and originally provided a mechanism to discover the > Path- MTU. It is now obsolete. Should be this 4.10.1. Uses > > This option originally provided a mechanism to discover the Path- > MTU. It is now obsolete. 4.18.4. Operational and Interoperability > Impact if Blocked None. Rather then None as is used throughout the > document how about "no known impact" or something along those > lines? Have we ever relied upon this option for Path-MTU discovery? Has this option ever been widely deployed? -- My take is that the answer to these two is "No". > 4.23 doesn't include any specific adivseit does however point to > other rfcswith language on ignoring unknown options. I think we > should make it a SHOULD drop but am open to discussion this > further. According to discussions with the other co-authors for, and considering that this document provides advices for routers (rather than firewalls), folks would like to ignore (rather than drop) packets containing unknown options. What do you folks think? > Lastly the "generic section 3" threat should probably be > standardized you have a couple of slightly different versions. > > 4.17.3. Threats There are no know threats arising from this > option, other than the general security implications of IP options > discussed in Section 3. 4.10.3. Threats No security issues are > known for this option, other than the general security implications > of IP options discussed in Section 3. Will do. > Also support addoption once this issues can be worked out. Great. Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From rbonica@juniper.net Tue Jun 5 19:57:48 2012 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 4B3F811E8097 for ; Tue, 5 Jun 2012 19:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.507 X-Spam-Level: X-Spam-Status: No, score=-106.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5pAuqj8SSAF for ; Tue, 5 Jun 2012 19:57:47 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 3A73511E808C for ; Tue, 5 Jun 2012 19:57:46 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKT87HJtlg7t0oLHjnXD//FGIMZ51MzK43@postini.com; Tue, 05 Jun 2012 19:57:47 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 5 Jun 2012 19:55:27 -0700 Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 5 Jun 2012 19:55:27 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 5 Jun 2012 22:55:26 -0400 From: Ronald Bonica To: Fernando Gont , "Smith, Donald" Date: Tue, 5 Jun 2012 22:55:24 -0400 Thread-Topic: [OPSEC] Call for adoption of draft-gont-opsec-ip-options-filtering Thread-Index: Ac1DglMnf1Hx7D7nSNyzoTyhOD/I/gADTH3Q Message-ID: <13205C286662DE4387D9AF3AC30EF456D76C82FB5F@EMBX01-WF.jnpr.net> References: <55C66AF5-F84F-44BF-9972-8725244F3302@kumari.net> <4FC7C0C2.9080708@juniper.net>, <4FCEA796.1080107@gont.com.ar> In-Reply-To: <4FCEA796.1080107@gont.com.ar> 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: "opsec@ietf.org" , Warren Kumari Subject: Re: [OPSEC] Call for adoption of draft-gont-opsec-ip-options-filtering 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, 06 Jun 2012 02:57:48 -0000 On JUNOS, the behavior is configurable with the default being to ignore. Se= e - http://www.juniper.net/techpubs/en_US/junos12.1/topics/reference/configur= ation-statement/source-routing-edit-routing-options.html Ron > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf > Of Fernando Gont > Sent: Tuesday, June 05, 2012 8:43 PM > To: Smith, Donald > Cc: opsec@ietf.org; Warren Kumari > Subject: Re: [OPSEC] Call for adoption of draft-gont-opsec-ip-options- > filtering >=20 > Hi, Donald, >=20 > On 06/05/2012 06:23 PM, Smith, Donald wrote: > > This isn't quite correct. 4.3.4. Operational and Interoperability > > Impact if Blocked > > > > Network troubleshooting techniques that may employ the LSRRoption > > (such as ping or traceroute) would break. Nevertheless, it should be > > noted that it is virtually impossible to use the LSRRoption for > > troubleshooting, due to widespread dropping of packets that contain > > such option. 4.3.5. Advice Routers, security gateways, and firewalls > > SHOULD, by default, drop IP packets that contain an LSRRoption. Most > > routers don't drop LSRRor SSRRthey ignore them. no ipsource-route > > drops that ipoption towards the router itself it shouldn't afaikdrop > > the packets themselves. Now given that that is the default configfor > > them and most other router vendors I believe your correct in saying > > you can pretty safely drop these packets. >=20 > Just double-checking: Is your argument that the advice is okay, but > just that we should note that routers typically ignore this option > rather than drop them. >=20 > THat aside: Can anyone check the defaults for Ciscos and Junipers? >=20 >=20 >=20 > > This also is incorrect as I understand it. 4.5.4. Operational and > > Interoperability Impact if Blocked Network troubleshooting techniques > > that may employ the RR option (such as ping with the RR > > option) would break. Nevertheless, it should be noted that it is > > virtually impossible to use such techniques due to widespread > dropping > > of packets that contain RR options. 4.5.5. Advice Routers, security > > gateways, and firewalls SHOULD drop IP packets containing a Record > > Route option. While RR can be dropped it requires a 12.++ image to do > > options aclson a ciscoso that is "fairly" recent 8 years or so ago:) > I > > don't know of many ISPs that drop RR. Feel free to correct me if > > someone knows of this being a common practice. >=20 > As with the other one, can folks provide input on this one? >=20 >=20 > > This isn't the operational impact statement it is a security > > statement. 4.7.4. Operational and Interoperability Impact if Blocked > > > > No security issues are known for this option, other than the general > > security implications of IP options discussed in Section 3. >=20 > Will fix this one. >=20 >=20 > > This: 4.10.1. Uses > > > > This option and originally provided a mechanism to discover the > > Path- MTU. It is now obsolete. Should be this 4.10.1. Uses > > > > This option originally provided a mechanism to discover the Path- > MTU. > > It is now obsolete. 4.18.4. Operational and Interoperability Impact > if > > Blocked None. Rather then None as is used throughout the document how > > about "no known impact" or something along those lines? >=20 > Have we ever relied upon this option for Path-MTU discovery? Has this > option ever been widely deployed? -- My take is that the answer to > these two is "No". >=20 >=20 >=20 > > 4.23 doesn't include any specific adivseit does however point to > other > > rfcswith language on ignoring unknown options. I think we should make > > it a SHOULD drop but am open to discussion this further. >=20 > According to discussions with the other co-authors for, and considering > that this document provides advices for routers (rather than > firewalls), folks would like to ignore (rather than drop) packets > containing unknown options. >=20 > What do you folks think? >=20 >=20 > > Lastly the "generic section 3" threat should probably be standardized > > you have a couple of slightly different versions. > > > > 4.17.3. Threats There are no know threats arising from this option, > > other than the general security implications of IP options discussed > > in Section 3. 4.10.3. Threats No security issues are known for this > > option, other than the general security implications of IP options > > discussed in Section 3. >=20 > Will do. >=20 >=20 >=20 > > Also support addoption once this issues can be worked out. >=20 > Great. Thanks! >=20 > Best regards, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: > 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From Donald.Smith@CenturyLink.com Wed Jun 6 11:24:41 2012 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 94D3611E8086 for ; Wed, 6 Jun 2012 11:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.301, 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 W7LYG5wsQhW1 for ; Wed, 6 Jun 2012 11:24:40 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id CA14321F85B8 for ; Wed, 6 Jun 2012 11:24:40 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id q56IOa4m002108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jun 2012 13:24:37 -0500 (CDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 558B01E0064; Wed, 6 Jun 2012 12:24:31 -0600 (MDT) Received: from suomp60i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 2094F1E0049; Wed, 6 Jun 2012 12:24:31 -0600 (MDT) Received: from suomp60i.qintra.com (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id q56IOU4I015640; Wed, 6 Jun 2012 13:24:30 -0500 (CDT) Received: from qtdenexhtm22.AD.QINTRA.COM (qtdenexhtm22.ad.qintra.com [151.119.91.231]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id q56IOUht015625 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Wed, 6 Jun 2012 13:24:30 -0500 (CDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Wed, 6 Jun 2012 12:24:29 -0600 From: "Smith, Donald" To: "'Fernando Gont'" Date: Wed, 6 Jun 2012 12:24:28 -0600 Thread-Topic: [OPSEC] Call for adoption of draft-gont-opsec-ip-options-filtering Thread-Index: Ac1DgkPAzjeasedbT0Gjn9Dz1Rc/nQAjo6hw Message-ID: References: <55C66AF5-F84F-44BF-9972-8725244F3302@kumari.net> <4FC7C0C2.9080708@juniper.net>, <4FCEA796.1080107@gont.com.ar> In-Reply-To: <4FCEA796.1080107@gont.com.ar> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "'opsec@ietf.org'" , 'Warren Kumari' Subject: Re: [OPSEC] Call for adoption of draft-gont-opsec-ip-options-filtering 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, 06 Jun 2012 18:24:41 -0000 When packets collide the controllers cease transmission AND wait a random t= ime before retransmission (mostly)! Donald.Smith@CenturyLink.com > -----Original Message----- > From: Fernando Gont [mailto:fernando.gont.netbook.win@gmail.com] On > Behalf Of Fernando Gont > Sent: Tuesday, June 05, 2012 6:43 PM > To: Smith, Donald > Cc: Warren Kumari; Dave Dugal; opsec@ietf.org > Subject: Re: [OPSEC] Call for adoption of draft-gont-opsec-ip-options- > filtering > > Hi, Donald, > > On 06/05/2012 06:23 PM, Smith, Donald wrote: > > This isn't quite correct. 4.3.4. Operational and Interoperability > > Impact if Blocked > > > > Network troubleshooting techniques that may employ the LSRRoption > > (such as ping or traceroute) would break. Nevertheless, it should > > be noted that it is virtually impossible to use the LSRRoption for > > troubleshooting, due to widespread dropping of packets that > > contain such option. 4.3.5. Advice Routers, security gateways, and > > firewalls SHOULD, by default, drop IP packets that contain an > > LSRRoption. Most routers don't drop LSRRor SSRRthey ignore them. no > > ipsource-route drops that ipoption towards the router itself it > > shouldn't afaikdrop the packets themselves. Now given that that is > > the default configfor them and most other router vendors I believe > > your correct in saying you can pretty safely drop these packets. > > Just double-checking: Is your argument that the advice is okay, but > just that we should note that routers typically ignore this option > rather than drop them. Correct. Ignore vs drop your recommendation can stand. > > THat aside: Can anyone check the defaults for Ciscos and Junipers? > > > > > This also is incorrect as I understand it. 4.5.4. Operational and > > Interoperability Impact if Blocked Network troubleshooting > > techniques that may employ the RR option (such as ping with the RR > > option) would break. Nevertheless, it should be noted that it is > > virtually impossible to use such techniques due to widespread > > dropping of packets that contain RR options. 4.5.5. Advice Routers, > > security gateways, and firewalls SHOULD drop IP packets containing > > a Record Route option. While RR can be dropped it requires a 12.++ > > image to do options aclson a ciscoso that is "fairly" recent 8 > > years or so ago:) I don't know of many ISPs that drop RR. Feel free > > to correct me if someone knows of this being a common practice. > > As with the other one, can folks provide input on this one? > > > > This isn't the operational impact statement it is a security > > statement. 4.7.4. Operational and Interoperability Impact if > > Blocked > > > > No security issues are known for this option, other than the > > general security implications of IP options discussed in Section > > 3. > > Will fix this one. > > > > This: 4.10.1. Uses > > > > This option and originally provided a mechanism to discover the > > Path- MTU. It is now obsolete. Should be this 4.10.1. Uses > > > > This option originally provided a mechanism to discover the Path- > > MTU. It is now obsolete. 4.18.4. Operational and Interoperability > > Impact if Blocked None. My real point on this one was the use of none vs no known impact. > > Rather then None as is used throughout the > > document how about "no known impact" or something along those > > lines? > > Have we ever relied upon this option for Path-MTU discovery? Has this > option ever been widely deployed? -- My take is that the answer to > these two is "No". > > > > > 4.23 doesn't include any specific advise does however point to > > other rfcs with language on ignoring unknown options. I think we > > should make it a SHOULD drop but am open to discussion this > > further. > > According to discussions with the other co-authors for, and > considering that this document provides advices for routers (rather > than firewalls), folks would like to ignore (rather than drop) packets > containing unknown options. > > What do you folks think? That would be the default for MOST ISPs. The general rule of thumb is we fo= rward traffic period. Dropping anything even something that we don't expect= to see THROUGH the routers is not advisable. To the router on the other ha= nd (thus ignore) is advisable. > > > > Lastly the "generic section 3" threat should probably be > > standardized you have a couple of slightly different versions. > > > > 4.17.3. Threats There are no know threats arising from this > > option, other than the general security implications of IP options > > discussed in Section 3. 4.10.3. Threats No security issues are > > known for this option, other than the general security implications > > of IP options discussed in Section 3. > > Will do. > > > > > Also support addoption once this issues can be worked out. > > Great. Thanks! > > Best regards, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@si6networks.com > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From jtk@cymru.com Wed Jun 6 16:07:40 2012 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 5A2DC11E807F for ; Wed, 6 Jun 2012 16:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_24=0.6] 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 X6Wg1W+kaBEX for ; Wed, 6 Jun 2012 16:07:38 -0700 (PDT) Received: from mailout.cymru.com (mailout.cymru.com [38.229.36.8]) by ietfa.amsl.com (Postfix) with ESMTP id 16EBB11E8083 for ; Wed, 6 Jun 2012 16:07:38 -0700 (PDT) Received: from localhost (vpn-72-36.svcs.ord07.cymru.com [172.16.72.36]) by mailout.cymru.com (Postfix) with ESMTP id 0DD1C46F09E; Wed, 6 Jun 2012 23:07:32 +0000 (GMT) Date: Wed, 6 Jun 2012 18:07:31 -0500 From: John Kristoff To: Warren Kumari Message-ID: <20120606180731.246ea42f@localhost> In-Reply-To: <55C66AF5-F84F-44BF-9972-8725244F3302@kumari.net> References: <55C66AF5-F84F-44BF-9972-8725244F3302@kumari.net> X-Mailer: Claws Mail Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: opsec@ietf.org Subject: Re: [OPSEC] Call for adoption of draft-gont-opsec-ip-options-filtering 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, 06 Jun 2012 23:07:40 -0000 On Thu, 24 May 2012 11:58:58 -0400 Warren Kumari wrote: > This is to start a two week poll to adopt > draft-gont-opsec-ip-options-filtering ( helpful link: > http://tools.ietf.org/html/draft-gont-opsec-ip-options-filtering-04) > as an OpSec Working Group draft. > > Please send your comments to the OpSec list (opsec@ietf.org). Sorry for the slight delay, I started reviewing the document about a week ago, but didn't get around to finishing until now. I think it a document worth adopting. > (This document was discussed in the Paris meeting, and not enough > people had read the document to be able to predict consensus. Please > take a moment (or 5) to read and comment. I should mention that > Memorial Day is coming up in the US soon -- there is nothing quite so > enjoyable as reading drafts on the beach -- try it!) My comments on the document below. In the Abstract the second word "document" is repeated. Structurally having a single subsection is awkward. I'd suggest Putting 1.1 into it's own section number 2 and adjust the document accordingly. Likewise, remove the subsection 3.1 and just put what is now 3.1's text directly under 3.0. Throughout the draft Service Provider is capitalized. I don't see why it should be. In section 1 and elsewhere the past tense use of "optioned" and "un-optioned" is awkward. I'd suggest something like "datagrams with options" or "without options" instead. In section 1, I believe "tends to support" should instead be "tend to support". Also in section 1, the sentence starting with "Some results of regarding" is worded awkwardly. I'd suggest starting with it "Some results on" instead. In section 2, the first sentence should be terminated with a period and the following sentence can immediately follow it. Section 3.1 starts by saying "Router architectures can perform", but I think what is ultimately meant is "Router architectures often perform". A question for the group that may lead to another subsection under section 3, addressing one of the issues mentioned above... does the processing of datagrams with options potentially alter the order of packets? That is, if a datagram with options hits the slow path, may datagrams that arrived immediately after be forwarded first while the packet with options is being worked on? If so,this potential out of order delivery may be worth identifying as a general security implication. Why is the advice in 4.1.5 SHOULD NOT instead of MUST NOT? In section 4.3.1 the statement "in the routers within the peer of the ISP" is awkward. I'd suggest changing it to "between routers that are used in ISP peering relationships". Section 4.3.3 claims "The LSRR option has well-known security implications", but provides no supporting references and should. You can reference your own document, IETF RFC 6274. In section 4.3.3. the statement "the one that has probably received least attention" is probably better written as "one that has received little attention". Additionally, in section 4.3.3 there is specific mention of Microsoft1999 and OpenBSD1998. Why make an issue of those implementations here? To be consistent wouldn't you have to mention lots of other implementation issues with the handling of other options. In other words, you seem to point out some very specific issues that have been experienced with this option, but not others. In my experience I've seen a number of peering requirements for LSSR, but I can't recall them ever being enforced. While I suspect it gets very little use these days, contrary to the statement in 4.3.4 there is some evidence that that the LSRR option is still used for ISP-to-ISP connectivity troubleshooting: http://psg.com/peering.html http://www.gweep.net/~crimson/network/lsrr.html http://palvelut.aina.net/peering/index.html Outside even this limited usage, perhaps path asymmetry is common enough to render this and the following option obsolete anyway? If so, that would be an argument that could be added to sections 4.3.4 and 4.4.4. In section 4.4.1 the statement "within the peer of the ISP" is probably probably stated as "between ISPs". The last sentence in section 4.8.5 is long, awkward and contains at least one small grammatical error. Perhaps change to this: Additionally, routers, security gateways and firewalls SHOULD have a configuration setting that indicates what action to take when encountering the Router Alert option. The configuration option could be a choice of whether to react on the Router Alert option as indicated in the corresponding specification, ignore the option or drop the packet. The default configuration setting SHOULD be to ignore the Router Alert option. In section 4.10.1, the first sentence should probably start with "This option originally". The statement in Section 4.12.1 that reads "This option probably has more deployment now than when the IESG describes a similar option" should be supported with a reference to justify the claim if possible. To be consistent, shouldn't the first sentence in 4.12.3 be as it is in 4.11.3 and others? In section 4.12.5 it is recommended that the option be logged on a per-interface basis. Why is this recommended only for this option? Presumably 4.20.3 was not forgotten and will at least get the standard statement used in other Threats subsections. At the heart of most of this document is that datagrams with options have a tendency to melt routers since they have to do extra, hard to optimize for work. There are very few options in this document that document recommends not dropping. This could be viewed as a way to avoid going around and obsoleting all those options individually or as a shortcut to practically obsoleting options entirely. It might be argued that recommending dropping all these datagrams may pose more problems than simply ignoring them, especially by anything but the destination. That is, dropping may incur a processing penalty. For example, there is some cost when advocating for logging or if the system would generate an an ICMP destination unreachable message. I'm inclined to suggest that some nuance may be better here. For example, perhaps recommend changing "SHOULD drop packets" to "MAY drop packets" and "SHOULD ignore packets" for routing nodes. Perhaps destinations would get the same recommendation, but that might not necessarily need to be the case. There does not seem to be any consideration for the general case of excessive repetition of options, anomalous repeated options or malformed options. Perhaps these should be discussed at length also? It should be noted that this document would update IETF RFCs 791, 1122 and 1812. John From fernando.gont.netbook.win@gmail.com Thu Jun 7 00:26:56 2012 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 DECEB21F8621 for ; Thu, 7 Jun 2012 00:26:56 -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 30vJ+ixnaeQy for ; Thu, 7 Jun 2012 00:26:56 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id EDE7221F8620 for ; Thu, 7 Jun 2012 00:26:55 -0700 (PDT) Received: by yenq13 with SMTP id q13so207715yen.31 for ; Thu, 07 Jun 2012 00:26:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=9g1G8vTdHbDdUTXVPpZTixW3J/wv/LSTD1MjmIVuRiA=; b=SbFlr8VUyROYxjenUB8Hr1FkpB6i9Krz3KwH8PrIOnPExMnIpHR130NNYcsp5XF42V Xn4efizXnKDkc5VJksaifF14iugzB8CKgY0vIFGYS9mauxlisPPmLRDHu6H9rvv0KF+3 VQfjgiu8OLVJivuZZT5pEZFWXJGeYKuS/c8ggNj756a0hYG9dcEP/4tREHxD4ImAmOo5 n8YaSPk/r/U5/W5fik4vMmXHbzhch+9/EqlBJPYQ3PbkeF+xUM39EwZzzk1IOXQadYox AUsN7DgT3/Evnu6AOLEshgrWfV05t5mCNBZtexIPplPrZCkSyNFLfreBX4GxFbv4Go7r 4v5w== Received: by 10.101.3.39 with SMTP id f39mr329530ani.6.1339054015464; Thu, 07 Jun 2012 00:26:55 -0700 (PDT) Received: from [192.168.0.95] (server.199.76.itcsa.net. [190.15.199.76]) by mx.google.com with ESMTPS id i67sm7518597yhh.21.2012.06.07.00.26.52 (version=SSLv3 cipher=OTHER); Thu, 07 Jun 2012 00:26:54 -0700 (PDT) Sender: Fernando Gont Message-ID: <4FD057BA.9060809@gont.com.ar> Date: Thu, 07 Jun 2012 04:26:50 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Smith, Donald" References: <55C66AF5-F84F-44BF-9972-8725244F3302@kumari.net> <4FC7C0C2.9080708@juniper.net>, <4FCEA796.1080107@gont.com.ar> In-Reply-To: X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'opsec@ietf.org'" , 'Warren Kumari' Subject: Re: [OPSEC] Call for adoption of draft-gont-opsec-ip-options-filtering 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, 07 Jun 2012 07:26:57 -0000 On 06/06/2012 03:24 PM, Smith, Donald wrote: >>> This: 4.10.1. Uses >>> >>> This option and originally provided a mechanism to discover the >>> Path- MTU. It is now obsolete. Should be this 4.10.1. Uses >>> >>> This option originally provided a mechanism to discover the >>> Path- MTU. It is now obsolete. 4.18.4. Operational and >>> Interoperability Impact if Blocked None. > My real point on this one was the use of none vs no known impact. Ok, I will "standardize" the wording. such that all these options have the same text. Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From warren@kumari.net Fri Jun 8 11:49:29 2012 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 4B22411E80F9 for ; Fri, 8 Jun 2012 11:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.366 X-Spam-Level: X-Spam-Status: No, score=-106.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQotWiz++6Ov for ; Fri, 8 Jun 2012 11:49:28 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id C99E411E80F1 for ; Fri, 8 Jun 2012 11:49:28 -0700 (PDT) Received: from dhcp-172-19-118-235.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 3C5B61B4039F for ; Fri, 8 Jun 2012 14:49:28 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1278) From: Warren Kumari In-Reply-To: <55C66AF5-F84F-44BF-9972-8725244F3302@kumari.net> Date: Fri, 8 Jun 2012 14:49:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <229B797E-BF6D-4774-A42C-7C7F15F5DA07@kumari.net> References: <55C66AF5-F84F-44BF-9972-8725244F3302@kumari.net> To: opsec@ietf.org X-Mailer: Apple Mail (2.1278) Subject: Re: [OPSEC] Call for adoption of draft-gont-opsec-ip-options-filtering 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, 08 Jun 2012 18:49:29 -0000 On May 24, 2012, at 11:58 AM, Warren Kumari wrote: > Dear Working Group, >=20 > This is to start a two week poll to adopt > draft-gont-opsec-ip-options-filtering ( helpful link: = http://tools.ietf.org/html/draft-gont-opsec-ip-options-filtering-04) > as an OpSec Working Group draft. >=20 > Please send your comments to the OpSec list (opsec@ietf.org). >=20 > This adoption call closes on June 7th, 2012. Apologies, I was on a plane on the 7th and didn't get a chance to send = the "This is now closed!" mail=85. Anyway, this is now closed :-p While I would have liked to see more comments, there was enough to = adopt, so: The author is requested to resubmit the document as = draft-ietf-opsec-ip-options-filtering-00. Thank you to everyone who provided comments and feedback=85 W >=20 > (This document was discussed in the Paris meeting, and not enough = people had read the document to be able to predict consensus. Please = take a moment (or 5) to read and comment. I should mention that Memorial = Day is coming up in the US soon -- there is nothing quite so enjoyable = as reading drafts on the beach -- try it!) >=20 > W >=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 --=20 With Feudalism, it's your Count that votes. From internet-drafts@ietf.org Mon Jun 11 14:49:53 2012 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 9B30221F853D; Mon, 11 Jun 2012 14:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.229 X-Spam-Level: X-Spam-Status: No, score=-102.229 tagged_above=-999 required=5 tests=[AWL=0.370, 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 08e5bJzjvFzf; Mon, 11 Jun 2012 14:49:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 342E521F8464; Mon, 11 Jun 2012 14:49:53 -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.20 Message-ID: <20120611214953.5319.82997.idtracker@ietfa.amsl.com> Date: Mon, 11 Jun 2012 14:49:53 -0700 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-ip-options-filtering-00.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, 11 Jun 2012 21:49: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-00.txt Pages : 30 Date : 2012-06-11 Abstract: This document 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/submission.filename }}-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From fernando.gont.netbook.win@gmail.com Mon Jun 11 15:54:37 2012 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 707D611E809C for ; Mon, 11 Jun 2012 15:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.307 X-Spam-Level: X-Spam-Status: No, score=-2.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, 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 vKO-EpRA9yUy for ; Mon, 11 Jun 2012 15:54:37 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id B48A411E8099 for ; Mon, 11 Jun 2012 15:54:36 -0700 (PDT) Received: by ghbg16 with SMTP id g16so3477102ghb.31 for ; Mon, 11 Jun 2012 15:54:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=RQ60JlCcXoA6wqVwdsLjFpCc8zBVhyQJXlHTAUPh0Uk=; b=gcLghSBCrcBCwU7dCKGSf8vN10qLLtDAgAChECYofA4JkjPD/gKV7O+AAIm2WgjZPw ZgwW6RU5E8+CKkYZo7r9NGS6lWA8aivSlOBUWgrQXD9HK3hLaldh0IIRtoCdvaD61lnr Rp1/pbsmK6qu3d4TVhSNR/vGzmGRGpjENXCn9u4oL/3is2zw0CJ38kuzpx1HIPBzZ4pH fA2s1kz4Dp+KV5Z1f7TYOTi7KEd7BmTvkfExcflAX6ZylssoxIfp4heMeeAawEwctWCk qvMRY0m/IznCGGOgDXkdm8Zl6xHyDCjxK2cYPAhqD/r4aeipke4ddtcyRNQxEA4o8lF5 i6kw== Received: by 10.236.181.133 with SMTP id l5mr23731465yhm.81.1339455276264; Mon, 11 Jun 2012 15:54:36 -0700 (PDT) Received: from ?IPv6:2001:5c0:1000:a::5e5? ([2001:5c0:1000:a::5e5]) by mx.google.com with ESMTPS id w6sm60515855yhi.22.2012.06.11.15.54.33 (version=SSLv3 cipher=OTHER); Mon, 11 Jun 2012 15:54:35 -0700 (PDT) Sender: Fernando Gont Message-ID: <4FD67726.7050606@gont.com.ar> Date: Mon, 11 Jun 2012 19:54:30 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 CC: opsec@ietf.org References: <20120611214953.5319.82997.idtracker@ietfa.amsl.com> In-Reply-To: <20120611214953.5319.82997.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-ip-options-filtering-00.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, 11 Jun 2012 22:54:37 -0000 Folks, FYI, I've simply reposed the I-D as draft-ietf. Will start working on a rev that addresses the feedback we've received so far this week. Cheers, Fernando On 06/11/2012 06:49 PM, 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 : Recommendations on filtering of IPv4 packets containing IPv4 options > Author(s) : Fernando Gont > RJ Atkinson > Carlos Pignataro > Filename : draft-ietf-opsec-ip-options-filtering-00.txt > Pages : 30 > Date : 2012-06-11 > > Abstract: > This document 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/submission.filename }}-00 > > > 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 > -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From rja.lists@gmail.com Tue Jun 12 06:53:06 2012 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 B8D0A21F858F for ; Tue, 12 Jun 2012 06:53:06 -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 KAdKXSyOXxaM for ; Tue, 12 Jun 2012 06:53:05 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id B480621F8587 for ; Tue, 12 Jun 2012 06:53:05 -0700 (PDT) Received: by qabj40 with SMTP id j40so427246qab.15 for ; Tue, 12 Jun 2012 06:53:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:resent-from:date :content-transfer-encoding:resent-date:resent-to:message-id:to :x-mailer; bh=5SzMV+5s5dJ5J3RPJRvLweR7Y42hAflyvw/pCB2bsc8=; b=0VVyP1Vb2S99fZVe7yOLsORn7wcBJ3OoDz+1XBXPDnSjVTGu1kwH3/cKFw9gSEDtMO McGuEcWSKVRHYmuOznkAzJGJFIC0LVjLdpuB1F9rajx+pixOFr7tFOI7d4UxtP7agfgh c2+Xte0UoGU9q/LNXEKUUuhJCdt8K2GWPIHIJ928YaMBigd7IRrKCwdNf5N4gll27keV +55Ao7mpk4Iux/5nWyJJh9pSSpaqDXF6BaF17ErGZwWqzLJA322QXJ3JIZitykfKFdvD tuxhU5I1zaZIz3LwYalPd7RusK0MVN3g85KuOvhOWU9mITUDUQ8EUKiK5eyimH2FmVgZ uxBg== Received: by 10.224.101.8 with SMTP id a8mr20266908qao.1.1339509185036; Tue, 12 Jun 2012 06:53:05 -0700 (PDT) Received: from [10.30.20.11] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id e2sm3407272qap.15.2012.06.12.06.53.04 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Jun 2012 06:53:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: RJ Atkinson Resent-From: RJ Atkinson Date: Tue, 12 Jun 2012 09:36:12 -0400 Content-Transfer-Encoding: quoted-printable Resent-Date: Tue, 12 Jun 2012 09:53:04 -0400 Resent-To: opsec@ietf.org Message-Id: <667A7FD7-1E41-4A57-AA31-FEAACB7497ED@gmail.com> To: opsec@ietf.org X-Mailer: Apple Mail (2.1278) Resent-Message-Id: <20120612135305.B480621F8587@ietfa.amsl.com> Subject: [OPSEC] Additional corrections for draft-ietf-opsec-ip-options-filtering 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, 12 Jun 2012 13:53:06 -0000 1) Incorrect Advice in Section 4.22.5 The advice in Section 4.22.5 is incorrect, and simply will create pressure by experimenters to obtain unique experimental IP option allocations. This is not helpful from a security perspective. It also is not helpful from a standards perspective, as it creates pressure to allocate unique permanent option numbers to experiments that might have a relatively short lifetime. Such options normally will be ignored by routers, gateways, or other devices that don't recognise them -- as required already by both=20 RFC-1122 and RFC-1812 -- and as widely implemented in deployed=20 IP routers. =20 These experimental IP options do NOT create any new security risk. =20 So the correct Advice is for devices that don't recognise such=20 IP options to ignore the presence of those options when forwarding=20 or otherwise handling the packets. This correction to the text in 4.22.5 is entirely consistent with the existing text in Section 4.23 about handling for other "unrecognised IP options". 2) Incorrect reference for RFC-1108. The expansion of the reference for RFC-1108 is wrong. The title for that RFC is much longer. This problem has been noted in the past without actually being corrected. If this is a "tools problem", then please either pick different=20 tools, cause the tools problem to be fixed, or find a manual fix=20 for the problem. A manual fix might be required in the near-term. Reviewers deserve to be able to read the whole correct citation. 3) Incorrect Reference for [FIPS1994] This entry should read instead: [FIPS1994] US National Institute for Standards and Technology,=20 "Standard Security Label for Information Transfer", (US) Federal Information Processing Standards=20 Publication 188 (FIPS 188), NIST, Gaithersburg, MD,=20 USA, 6 September 1994. =20 = Kindly note that NIST is both author and publisher, and also that=20 the first use of the acronym NIST is fully expanded for clarity. Again, if this is a "tools problem", then please either use different tools or find a manual fix for the problem. 4) Incorrect reference placement [I-D.gp-intarea-obsolete-ipv4-options-iana] should be a normative reference, not an informative reference, because the advice=20 contained in *-ip-options-filtering is based on the premise that=20 the cited I-D will be approved by the IETF and the requested changes=20 will be made by IANA upon the direction of the IESG. 5) Proposed additional reference I'd suggest adding this refereed conference paper as an Informational=20 reference relating to SE-Linux, since it appears to be the key published paper relating to SE-Linux: [LS2001] Peter Loscocco and Stephen Smalley, "Integrating Flexible=20 Support for Security Policies into the Linux Operating System", in=20 Proceedings of the FREENIX Track: 2001 USENIX Annual Technical=20 Conference (FREENIX =9201), USENIX Association, Boston, MA, USA, June 2001. Yours, Ran From rja.lists@gmail.com Tue Jun 12 06:36:16 2012 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 8E83421F8541 for ; Tue, 12 Jun 2012 06:36:16 -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 GVJF-PogBR1t for ; Tue, 12 Jun 2012 06:36:15 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3327E21F853C for ; Tue, 12 Jun 2012 06:36:15 -0700 (PDT) Received: by qcsq13 with SMTP id q13so201263qcs.31 for ; Tue, 12 Jun 2012 06:36:14 -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=4e/Jb7zv5ClteRyT7mVG1zwLToFbPUyKFtLUXQS3HHw=; b=UQJpQQ0ev9Ekzpi3BdsLmv1jqVB2TyjzZiiVRhsDLztLLP6/0lGvZHOX+MuNlJgjzb t0rWnGJ33JVlQYIkkfhCIkFkeuwZI4/ksaVOYlVAVsbaGSN9EyHwCDwB8fmSfRfzV6Vi RozOar2Gv29/gNJKli8rttBRSxzG7TunaH3ct0jGKSy5CEEceUqZwZ9vA3OCuKyiIllh nAN6DTIUESs8T0AEcwf1IKImjSrn83V8dGQg6VwU52lAIoT9CHeqnzheYTM6676CGg0a 1j86u81VWGteXsb0RjVg7s/Mosjts9bLq5jAZJgG19NnadWYxH2bXvXjILLyla8qxdvo eRBA== Received: by 10.224.186.195 with SMTP id ct3mr19808190qab.24.1339508174326; Tue, 12 Jun 2012 06:36:14 -0700 (PDT) Received: from [10.30.20.11] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id fe8sm3342153qab.11.2012.06.12.06.36.12 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Jun 2012 06:36:13 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jun 2012 09:36:12 -0400 Message-Id: <667A7FD7-1E41-4A57-AA31-FEAACB7497ED@gmail.com> To: opsec@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Mailman-Approved-At: Tue, 12 Jun 2012 07:04:41 -0700 Subject: [OPSEC] Additional corrections for draft-ietf-opsec-ip-options-filtering 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, 12 Jun 2012 13:36:16 -0000 1) Incorrect Advice in Section 4.22.5 The advice in Section 4.22.5 is incorrect, and simply will create pressure by experimenters to obtain unique experimental IP option allocations. This is not helpful from a security perspective. It also is not helpful from a standards perspective, as it creates pressure to allocate unique permanent option numbers to experiments that might have a relatively short lifetime. Such options normally will be ignored by routers, gateways, or other devices that don't recognise them -- as required already by both=20 RFC-1122 and RFC-1812 -- and as widely implemented in deployed=20 IP routers. =20 These experimental IP options do NOT create any new security risk. =20 So the correct Advice is for devices that don't recognise such=20 IP options to ignore the presence of those options when forwarding=20 or otherwise handling the packets. This correction to the text in 4.22.5 is entirely consistent with the existing text in Section 4.23 about handling for other "unrecognised IP options". 2) Incorrect reference for RFC-1108. The expansion of the reference for RFC-1108 is wrong. The title for that RFC is much longer. This problem has been noted in the past without actually being corrected. If this is a "tools problem", then please either pick different=20 tools, cause the tools problem to be fixed, or find a manual fix=20 for the problem. A manual fix might be required in the near-term. Reviewers deserve to be able to read the whole correct citation. 3) Incorrect Reference for [FIPS1994] This entry should read instead: [FIPS1994] US National Institute for Standards and Technology,=20 "Standard Security Label for Information Transfer", (US) Federal Information Processing Standards=20 Publication 188 (FIPS 188), NIST, Gaithersburg, MD,=20 USA, 6 September 1994. =20 = Kindly note that NIST is both author and publisher, and also that=20 the first use of the acronym NIST is fully expanded for clarity. Again, if this is a "tools problem", then please either use different tools or find a manual fix for the problem. 4) Incorrect reference placement [I-D.gp-intarea-obsolete-ipv4-options-iana] should be a normative reference, not an informative reference, because the advice=20 contained in *-ip-options-filtering is based on the premise that=20 the cited I-D will be approved by the IETF and the requested changes=20 will be made by IANA upon the direction of the IESG. 5) Proposed additional reference I'd suggest adding this refereed conference paper as an Informational=20 reference relating to SE-Linux, since it appears to be the key published paper relating to SE-Linux: [LS2001] Peter Loscocco and Stephen Smalley, "Integrating Flexible=20= Support for Security Policies into the Linux Operating System", in=20 Proceedings of the FREENIX Track: 2001 USENIX Annual Technical=20 Conference (FREENIX =9201), USENIX Association, Boston, MA, USA, June 2001. Yours, Ran From fernando.gont.netbook.win@gmail.com Wed Jun 13 02:52:34 2012 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 C3A7A21F8569 for ; Wed, 13 Jun 2012 02:52:34 -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 Bbbtm0KRkj9r for ; Wed, 13 Jun 2012 02:52:33 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 76DB521F852C for ; Wed, 13 Jun 2012 02:52:29 -0700 (PDT) Received: by yenq13 with SMTP id q13so368517yen.31 for ; Wed, 13 Jun 2012 02:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=jJSmndtWELJqJFVz32RtB+SUR8Oen3fkKQcToinRt4Q=; b=GjwH+PggmXQpDkyGXnqWbt8ncHq0LU9K34oJkx0NK1ZTuGuJ8toIUty6+1UIi68gPQ VrA31aj6v3IPljp7Jojb+1UtJTsZyLCQ1k+0YiWTj4DUF1xR58YOPCcJ8EIniDCxeHj0 4i6uRhKSE62fu31+UiH8dTvj4uUunLvt4GzTtyRztNC1eSXy1IQjGaCyxpSO5y2jy0oV TlmDCraNIOeaOPJXVh6/Ljxp6yN+8SCfOnCL77MMuFGUhEdT7O/q6zXaUTk1Pw8Mk1gd cZy5t+G9drnzWwBPSGuQChDe3T1Efz3gHOi15eqlM4PUSjdWsEzC9XwxQS2rZ7KtphZ2 Y/4g== Received: by 10.101.131.14 with SMTP id i14mr9934457ann.44.1339581146915; Wed, 13 Jun 2012 02:52:26 -0700 (PDT) Received: from [192.168.0.182] (61-128-17-190.fibertel.com.ar. [190.17.128.61]) by mx.google.com with ESMTPS id l49sm7858861yhj.8.2012.06.13.02.52.24 (version=SSLv3 cipher=OTHER); Wed, 13 Jun 2012 02:52:25 -0700 (PDT) Sender: Fernando Gont Message-ID: <4FD862D6.2070505@gont.com.ar> Date: Wed, 13 Jun 2012 06:52:22 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: RJ Atkinson References: <667A7FD7-1E41-4A57-AA31-FEAACB7497ED@gmail.com> In-Reply-To: <667A7FD7-1E41-4A57-AA31-FEAACB7497ED@gmail.com> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: opsec@ietf.org Subject: Re: [OPSEC] Additional corrections for draft-ietf-opsec-ip-options-filtering 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, 13 Jun 2012 09:52:34 -0000 Hi, Ran, On 06/12/2012 10:36 AM, RJ Atkinson wrote: > 1) Incorrect Advice in Section 4.22.5 > > The advice in Section 4.22.5 is incorrect, and simply will create > pressure by experimenters to obtain unique experimental IP option > allocations. This is not helpful from a security perspective. > It also is not helpful from a standards perspective, as it creates > pressure to allocate unique permanent option numbers to experiments > that might have a relatively short lifetime. > > This correction to the text in 4.22.5 is entirely consistent > with the existing text in Section 4.23 about handling for > other "unrecognised IP options". Will fix this in the next rev. > 2) Incorrect reference for RFC-1108. > > The expansion of the reference for RFC-1108 is wrong. The title > for that RFC is much longer. This problem has been noted in the > past without actually being corrected. This is an error in the xml2rfc tool. I reported it at least twice, but it has not yet been fixed. Rather than changing the xml source, I decided to wait a bit in the hopes that they fixed the tool, such that this got fixed in the I-D automagically. Unless they fix this shortly, I'll replace the "automatic" reference with a handcrafted one, such that this error is fixed. > If this is a "tools problem", then please either pick different > tools, cause the tools problem to be fixed, or find a manual fix > for the problem. A manual fix might be required in the near-term. > Reviewers deserve to be able to read the whole correct citation. Will do. > 3) Incorrect Reference for [FIPS1994] > > This entry should read instead: > > [FIPS1994] > US National Institute for Standards and Technology, > "Standard Security Label for Information Transfer", > (US) Federal Information Processing Standards > Publication 188 (FIPS 188), NIST, Gaithersburg, MD, > USA, 6 September 1994. > > > > Kindly note that NIST is both author and publisher, and also that > the first use of the acronym NIST is fully expanded for clarity. > > Again, if this is a "tools problem", then please either use > different tools or find a manual fix for the problem. I will try to convey all this information in the xml. Unfortunately, this seems to be a kind of "black magic" -- even the RFC-Ed has to hack the xml to get the desired output. :-( Worst case scenario: I'll include this as a comment in the xml, such that the RFC-Ed does the final editing to make this look as expected. > 4) Incorrect reference placement > > [I-D.gp-intarea-obsolete-ipv4-options-iana] should be a normative > reference, not an informative reference, because the advice > contained in *-ip-options-filtering is based on the premise that > the cited I-D will be approved by the IETF and the requested changes > will be made by IANA upon the direction of the IESG. Will do. > 5) Proposed additional reference > > I'd suggest adding this refereed conference paper as an Informational > reference relating to SE-Linux, since it appears to be the key published > paper relating to SE-Linux: > > [LS2001] Peter Loscocco and Stephen Smalley, "Integrating Flexible > Support for Security Policies into the Linux Operating System", in > Proceedings of the FREENIX Track: 2001 USENIX Annual Technical > Conference (FREENIX ’01), USENIX Association, Boston, MA, USA, > June 2001. Will do. Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando.gont.netbook.win@gmail.com Wed Jun 13 07:00:13 2012 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 4BF4E21F85D0 for ; Wed, 13 Jun 2012 07:00:13 -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 nCHUp8Jjh0kC for ; Wed, 13 Jun 2012 07:00:12 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB3621F860F for ; Wed, 13 Jun 2012 07:00:12 -0700 (PDT) Received: by vcqp1 with SMTP id p1so375696vcq.31 for ; Wed, 13 Jun 2012 07:00:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; bh=VdekOLHTnt6zfz3N76fSKc0jGDNU3SqrjqV9sQ5ogWM=; b=dwI1UUfSeK/9wIY33rouQS2RuQCktrhr4j6PpzHWm8GIU8hCVfO7Tlin3553RrD49t K74CUYNNIdns01BRpG53JmMjlyVKmXLx+KZQPbU6dRiSxZHfQ+oG5GcE7ajvGbbNrzJO h3M29T4B6lbVTNyVnTonrtS1SjAM9jMrF2o+p2PR9HSI7z1iKJ8mdYD3erjjau6cm4Dw B3CVgyJFztUd80CRQSe8DUpGMKWbBZLYCjCgZHQm4QRNPJFwf8yjZqJhOQr8ahRHR4qY uE0oZ0377EXs55xagNMt5pSqQS+KQaVejUZjpyXu16/ShwW5WmGhNA4PS0ZOQHtrGU6c cfzQ== Received: by 10.220.242.78 with SMTP id lh14mr17127365vcb.64.1339596011630; Wed, 13 Jun 2012 07:00:11 -0700 (PDT) Received: from [192.168.0.203] (61-128-17-190.fibertel.com.ar. [190.17.128.61]) by mx.google.com with ESMTPS id z17sm1690104vdg.13.2012.06.13.07.00.08 (version=SSLv3 cipher=OTHER); Wed, 13 Jun 2012 07:00:09 -0700 (PDT) Sender: Fernando Gont Message-ID: <4FD89922.3050406@gont.com.ar> Date: Wed, 13 Jun 2012 10:44:02 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "'opsec@ietf.org'" X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSEC] Heads up: 6man poll for adoption of RA-Guard/firewalling/monitoring-related I-Ds 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, 13 Jun 2012 14:00:13 -0000 Folks, Just wanted to send a heads up regarding two 6man wg polls that have just been started for adoption of these documents: * draft-gont-6man-oversized-header-chain-02 (Security and Interoperability Implications of Oversized IPv6 Header Chains) * draft-gont-6man-nd-extension-headers-03 (Security Implications of the Use of IPv6 Extension Headers with IPv6 Neighbor Discovery) draft-gont-6man-oversized-header-chain-02 requires that when packets are fragmented, the first fragment must contain the entire IPv6 header chain. This is important for a number of reasons: it allows for stateless filtering (both at firewalls and at RA-Guard-like devices), prevents stateless translators from breaking, etc. draft-gont-6man-nd-extension-headers-03 forbids the use of fragmentation with Neighbor Discovery. This essentially enables Neighbor Discovery monitoring in IPv6, thus providing feature parity with IPv4 (think about arpwatch and the like) -- not to mention that it obviously mitigates fragmentation-based attacks against Neighbor Discovery and SEND. IMO, these two I-Ds propose small spec updates which could result in concrete operational and security benefits. Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From melinda.shore@gmail.com Wed Jun 13 11:45:18 2012 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 7F67711E809F for ; Wed, 13 Jun 2012 11:45:18 -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 HYgPOtcJ4go8 for ; Wed, 13 Jun 2012 11:45:18 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id EE09311E8096 for ; Wed, 13 Jun 2012 11:45:17 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so2691956pbc.31 for ; Wed, 13 Jun 2012 11:45:17 -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:x-forwarded-message-id:content-type :content-transfer-encoding; bh=miHK4maMqTEt90AvAFgJ8rqI4/a8sDVT21GsWhyccSE=; b=QTVsDQGYQpsGV1f3nLom0hWHoz3kB/vWvu5p/HJdcY0FoeYN/i6QYzecyrG+ExSDeu mV392j6MclKOOrqwssMD8NOU2rNVNCdkWugyDTZtbXr+b9shAUWRYq5VFU6/l2GteAgF p5t2DqVtG0TIS1jA2LlXLHzNabR2i8tlHuOcEUeGUswO2E1Ye82Wf50VoSie77X2vmzG rGbad3iVxiMTMPqxRjS3lBLi5+Xlz0Z3UsQWesDgrLUCRUY25ylYDG9ISaKiQOm/Jr89 NJQO1tx7e5k9b5/uZi4fWbFSjteE612iKnSC2GZDssRFB0EeBc8mphFkJc9YqPlGKNDb FgZw== Received: by 10.68.203.66 with SMTP id ko2mr54119916pbc.84.1339613117605; Wed, 13 Jun 2012 11:45:17 -0700 (PDT) Received: from spandex.local (66-230-82-149-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.82.149]) by mx.google.com with ESMTPS id tj4sm6582495pbc.33.2012.06.13.11.45.16 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Jun 2012 11:45:17 -0700 (PDT) Message-ID: <4FD8DFBB.5000004@gmail.com> Date: Wed, 13 Jun 2012 10:45:15 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: opsec@ietf.org References: <20120612195331.26093.18247.idtracker@ietfa.amsl.com> In-Reply-To: <20120612195331.26093.18247.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120612195331.26093.18247.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 13 Jun 2012 15:19:20 -0700 Subject: [OPSEC] Fwd: [OPSAWG] I-D Action: draft-ietf-opsawg-firewalls-00.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, 13 Jun 2012 18:45:18 -0000 Heads-up on a new working group draft in opsawg that's likely to be of interest to some folks involved with opsec. Thanks, Melinda -------- Original Message -------- Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-firewalls-00.txt Date: Tue, 12 Jun 2012 12:53:31 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: opsawg@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : On Firewalls in Internet Security Author(s) : Fred Baker Filename : draft-ietf-opsawg-firewalls-00.txt Pages : 12 Date : 2012-06-12 Abstract: There is an ongoing discussion regarding the place of firewalls in security. This note is intended to capture and try to make sense out of it. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-firewalls There's also a htmlized version available at: http://tools.ietf.org/html/submission.filename }}-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From gvandeve@cisco.com Tue Jun 19 01:58:54 2012 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 49CB921F85B5 for ; Tue, 19 Jun 2012 01:58:54 -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 5iiPg8SQmCAA for ; Tue, 19 Jun 2012 01:58:52 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 78C9F21F85C4 for ; Tue, 19 Jun 2012 01:58:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=24816; q=dns/txt; s=iport; t=1340096330; x=1341305930; h=mime-version:subject:date:message-id:from:to; bh=U1DY5FNo5iHG9x3okdwZwOUzdxjdUjg2iQssBEbfSaM=; b=YP6ZJnr5FcUA9WEJKJf50pLNeLbl7iB8W+7wjhzqph7DW4GjLPFr8Rcr v2FukNYn0o1R9e8Fb8w3YBaSIKvUKd15ZLpQTRgZ4atF/XPMQkyYoynhA au41cg7S7odIUWR3qu46e8k4+RZind4J8rZHirJfHy5yA335+wsSpVxWV I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIc+4E+Q/khR/2dsb2JhbABFgkWzD4EHghoBBBIBCREDNiUBKgYQCAdXAQQbGodpC5dLgSigJgSQaGADozyBZoJigVQE X-IronPort-AV: E=Sophos;i="4.75,795,1330905600"; d="scan'208,217";a="74604397" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 19 Jun 2012 08:58:45 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q5J8wjdA020674 for ; Tue, 19 Jun 2012 08:58:45 GMT Received: from xmb-ams-102.cisco.com ([144.254.74.77]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Jun 2012 10:58:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD4DF9.BBB00A25" Date: Tue, 19 Jun 2012 10:58:44 +0200 Message-ID: <5C99EC8C99D9BB45AC51D20DC2AD2DC507D5EAD2@XMB-AMS-102.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Important dates for IETF84 Thread-Index: Ac1N+bsVWCx2hMxNQoa6PGUQ2uN/4g== From: "Gunter Van de Velde (gvandeve)" To: X-OriginalArrivalTime: 19 Jun 2012 08:58:45.0668 (UTC) FILETIME=[BBCE7E40:01CD4DF9] Subject: [OPSEC] Important dates for IETF84 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, 19 Jun 2012 08:58:54 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD4DF9.BBB00A25 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, =20 Please find here a quick reminder of the important dates for IETF82: * 2012-04-30 (Week of): IETF Online Registration opens. * 2012-04-30 (Monday): Working Group and BOF scheduling begins. To request a Working Group session, use the IETF Meeting Session Request Tool . * 2012-06-04 (Monday): Cutoff date for requests to schedule Working Group meetings at 17:00 PT (UTC -7). To request a Working Group session, use the IETF Meeting Session Request Tool . * 2012-06-18 (Monday): Cutoff date for BOF proposal requests to Area Directors at 17:00 PT (UTC -7). To request a BOF, please see instructions on Requesting a BOF . * 2012-06-21 (Thursday): Cutoff date for Area Directors to approve BOFs at 17:00 PT (UTC -7). * 2012-06-28 (Thursday): Preliminary agenda published for comment. * 2012-07-02 (Monday): Cutoff date for requests to reschedule Working Group and BOF meetings 17:00 PT (UTC -7). * 2012-07-02 (Monday): Working Group Chair approval for initial document (Version -00) submissions appreciated by 17:00 PT (UTC -7). * 2012-07-06 (Friday): Final agenda to be published. * 2012-07-09 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PT (UTC -7), upload using IETF ID Submission Tool . * 2012-07-16 (Monday): Internet Draft final submission cut-off by 17:00 PT (UTC -7), upload using IETF ID Submission Tool . * 2012-07-18 (Wednesday): Draft Working Group agendas due by 17:00 PT (UTC -7), upload using IETF Meeting Materials Management Tool . * 2012-07-20 (Friday): Early Bird registration and payment cut-off at 17:00 PT (UTC -7). * 2012-07-23 (Monday): Revised Working Group agendas due by 17:00 PT (UTC -7), upload using IETF Meeting Materials Management Tool . * 2012-07-23 (Monday): Registration cancellation cut-off at 17:00 PT (UTC -7). * 2012-07-27 (Friday): Final Pre-Registration and Pre-Payment cut-off at 17:00 local meeting time. * 2012-07-29 - 2012-08-03: 84th IETF Meeting in Vancouver, BC, Canada. * 2012-08-31 (Friday): Proceedings submission cutoff date by 17:00 PT (UTC -7), upload using IETF Meeting Materials Management Tool . * 2012-09-19 (Wednesday): Proceedings submission corrections cutoff date by 17:00 PT (UTC -7), upload usingIETF Meeting Materials Management Tool . =20 G/ & KK OPSEC Chairs ------_=_NextPart_001_01CD4DF9.BBB00A25 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

Please find here a quick = reminder of the important dates for IETF82:

  • 2012-04-30 (Week of): IETF = Online Registration opens.
  • 2012-04-30 (Monday): Working Group and BOF scheduling begins. To request a Working Group = session, use the IETF Meeting Session Request = Tool.
  • 2012-06-04 (Monday): Cutoff date for requests to schedule Working Group meetings at 17:00 PT = (UTC -7). To request a Working Group session, use the IETF Meeting Session Request = Tool.
  • 2012-06-18 (Monday): Cutoff date for BOF proposal requests to Area Directors at 17:00 PT (UTC = -7). To request a BOF, please see instructions on Requesting a BOF.
  • 2012-06-21 (Thursday): Cutoff date for Area Directors to approve BOFs at 17:00 PT (UTC = -7).
  • 2012-06-28 (Thursday): Preliminary= agenda published for comment.
  • 2012-07-02 (Monday): Cutoff date for requests to reschedule Working Group and BOF meetings = 17:00 PT (UTC -7).
  • 2012-07-02 (Monday): Working Group Chair approval for initial document (Version -00) submissions appreciated by 17:00 PT (UTC -7).
  • 2012-07-06 (Friday): Final agenda to be published.
  • 2012-07-09 (Monday): Internet Draft Cut-off for initial document (-00) = submission by 17:00 PT (UTC -7), upload using IETF ID Submission Tool.
  • 2012-07-16 (Monday): Internet Draft final submission cut-off by 17:00 PT (UTC -7), = upload using IETF ID Submission Tool.
  • 2012-07-18 (Wednesday): Draft Working Group agendas due by 17:00 PT (UTC -7), upload using IETF Meeting Materials Management = Tool.
  • 2012-07-20 (Friday): Early Bird registration and payment cut-off at 17:00 PT (UTC = -7).
  • 2012-07-23 (Monday): Revised Working Group agendas due by 17:00 PT (UTC -7), upload using IETF Meeting Materials Management = Tool.
  • 2012-07-23 (Monday): Registratio= n cancellation cut-off at 17:00 PT (UTC -7).
  • 2012-07-27 (Friday): Final Pre-Registration and Pre-Payment cut-off at 17:00 local meeting = time.
  • 2012-07-29 = - 2012-08-03: 84th IETF Meeting in Vancouver, BC, = Canada.=
  • 2012-08-31 (Friday): Proceedings= submission cutoff date by 17:00 PT (UTC -7), upload using IETF Meeting Materials Management = Tool.
  • 2012-09-19 (Wednesday): Proceedings= submission corrections cutoff date by 17:00 PT (UTC -7), upload = usingIETF Meeting Materials Management = Tool.

 

G/ & = KK

OPSEC = Chairs

------_=_NextPart_001_01CD4DF9.BBB00A25-- From gvandeve@cisco.com Tue Jun 19 02:00:25 2012 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 D48BD21F85DF for ; Tue, 19 Jun 2012 02:00:24 -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 yIYD8w2iA4F7 for ; Tue, 19 Jun 2012 02:00:24 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 7847921F859E for ; Tue, 19 Jun 2012 02:00:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=5638; q=dns/txt; s=iport; t=1340096423; x=1341306023; h=mime-version:subject:date:message-id:from:to:cc; bh=85OgpnqWDk0O8/EJFLsb3UXDcFEN/Gm7KSxc+ycZUlc=; b=L1GxVkk/4o3a41LYz7qPV4iVpaaXPlFpWRpdQ+KkSbzllhPcDJsxifnr 34arUgPDJqDhJpxjWyakKZBe0X0+yDdr13/8Xd3N1g1jVvy3Y1BPuk/Kr C6Gqp+qCNopvjciXmBoOPR7nFDwKf6N7B+CiQleQCwkAsC/EUzM6xwXuv U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIc+4E+Q/khR/2dsb2JhbABFgkWqMIhfgQeCGgEEEgEJARADSRIBKgYYB1cBBBsah2mYfqAqji2CO2ADozyBZoJi X-IronPort-AV: E=Sophos;i="4.75,795,1330905600"; d="scan'208,217";a="5946884" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 19 Jun 2012 09:00:22 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q5J90MNp021220; Tue, 19 Jun 2012 09:00:22 GMT Received: from xmb-ams-102.cisco.com ([144.254.74.77]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Jun 2012 11:00:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD4DF9.F54F47C4" Date: Tue, 19 Jun 2012 11:00:21 +0200 Message-ID: <5C99EC8C99D9BB45AC51D20DC2AD2DC507D5EAD6@XMB-AMS-102.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OPSEC: Call for agenda items Thread-Index: Ac1N+fTK4doLPVGESQCt6CY3QPXkxw== From: "Gunter Van de Velde (gvandeve)" To: X-OriginalArrivalTime: 19 Jun 2012 09:00:22.0450 (UTC) FILETIME=[F57E4120:01CD4DF9] Subject: [OPSEC] OPSEC: 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: Tue, 19 Jun 2012 09:00:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD4DF9.F54F47C4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, =20 Please know that we are starting to work on the agenda for the OPSEC WG. =20 Please let us know if you desire a speaking slot during IETF84. =20 G/ ------_=_NextPart_001_01CD4DF9.F54F47C4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

Please know that we are starting = to work on the agenda for the OPSEC WG.

 

Please let us know if you desire = a speaking slot during IETF84.

 

G/

------_=_NextPart_001_01CD4DF9.F54F47C4-- From jerduran@cisco.com Tue Jun 19 02:26:51 2012 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 2961D21F8546 for ; Tue, 19 Jun 2012 02:26:51 -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 63WbDobvLJsQ for ; Tue, 19 Jun 2012 02:26:50 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9E521F852C for ; Tue, 19 Jun 2012 02:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jerduran@cisco.com; l=1771; q=dns/txt; s=iport; t=1340098010; x=1341307610; h=from:to:cc:subject:date:message-id:mime-version; bh=VN3wEtoiMyvIj+fbpb2baPzCiSieICDOQkFucfEEMqY=; b=ADJKaukLL861jLV9eMdQ5WyQDKWxEdgRwEyjfNHUrR9Thknd8AIOH2Mq 6vLiSNAIzh7v1iF8WKY4zu7Cqggvzddh4zIFl2MKZ/QWxB2pgXZnBAvYl QkI4bjlAohG/P42rhQxEvmq14VY/gd33yLk0AI+2WG7Vn4I4g7LSM+Xp5 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4JAJxF4E+tJXG9/2dsb2JhbABFhnKmCohYgQeCDxASAWYSAQsBdCcEDg4Zh2kLmHCgLpBoYAOVJY4XgWaCYA X-IronPort-AV: E=Sophos;i="4.75,797,1330905600"; d="scan'208,217";a="93705068" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 19 Jun 2012 09:26:50 +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 q5J9QnrW029260 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Jun 2012 09:26:49 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.99]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0298.004; Tue, 19 Jun 2012 04:26:49 -0500 From: "Jerome Durand (jerduran)" To: "opsec@ietf.org" Thread-Topic: BGP OPSEC draft - v01 published Thread-Index: AQHNTf2ndjLr0MG9b0WklrkL/NZ/+Q== Date: Tue, 19 Jun 2012 09:26:49 +0000 Message-ID: <9EECF951-DDD0-421F-8B60-D60218409151@cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.103.171] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-18978.005 x-tm-as-result: No--32.466100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_9EECF951DDD0421F8B60D60218409151ciscocom_" MIME-Version: 1.0 Cc: Ivan Pepelnjak Subject: [OPSEC] BGP OPSEC draft - v01 published 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, 19 Jun 2012 09:26:51 -0000 --_000_9EECF951DDD0421F8B60D60218409151ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Following our great discussions last IETF in Paris we'd like to inform you = that a new version of OPSEC BGP draft is now published in integrates the ma= ny different comments we have received so far. http://www.ietf.org/id/draft-jdurand-bgp-security-01.txt Many thanks to all contributors. We believe this version is now a good basi= s for a working group document. Please let us know what you think. Thank you, Jerome, Ivan and Gert --_000_9EECF951DDD0421F8B60D60218409151ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi all,

Following our great discussions last IETF in Paris we'd like to inform= you that a new version of OPSEC BGP draft is now published in integrates t= he many different comments we have received so far.

Many thanks to all contributors. We believe this version is now a= good basis for a working group document. Please let us know what you think= .

Thank you,

Jerome, Ivan and Gert
--_000_9EECF951DDD0421F8B60D60218409151ciscocom_-- From fernando.gont.netbook.win@gmail.com Tue Jun 19 10:42:13 2012 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 835A611E810E for ; Tue, 19 Jun 2012 10:42:13 -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 sEMR9SiNGT8g for ; Tue, 19 Jun 2012 10:42:12 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7652E11E80F6 for ; Tue, 19 Jun 2012 10:42:12 -0700 (PDT) Received: by eekd4 with SMTP id d4so2388816eek.31 for ; Tue, 19 Jun 2012 10:42:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=TGngY/dS2J99UByVmMovJFL4/IVPCh7AkFbz83Ha7wE=; b=ghGG8XtGpk6xvLTqgu1PNE281FRrGTJjy3QD8e2KYUTQrWj84cSl+pNXXqN4Rgnhtx Fy+cMljdD5VWHlFObZ5OGIR6rxBZD12H7p2flKQHmbpPJ5R3pUgeJONmj0Ad1C2oqR6/ xHXKvHr85ZQAvdkczh5ZV0JslLUqTfShZjGpbWPber9Xc6inGF3/Oj5RT5ULvScn/EX3 nJ78QLM/sdyTMpKb/CPkYpFtRahWrNQpJNV04x/Ch1nUIQSFhJx3DvDIlPyNGkCc2TA8 dE2+0x31nQLbN5EoeCTRZ37DIPAoN2AHq2H8YljfWLMalTMxUEg401qk+nDunDUyghbG g/GA== Received: by 10.14.53.74 with SMTP id f50mr4676762eec.173.1340127731572; Tue, 19 Jun 2012 10:42:11 -0700 (PDT) Received: from [192.168.173.5] (AAubervilliers-652-1-159-246.w90-3.abo.wanadoo.fr. [90.3.14.246]) by mx.google.com with ESMTPS id p41sm78963508eef.5.2012.06.19.10.42.08 (version=SSLv3 cipher=OTHER); Tue, 19 Jun 2012 10:42:09 -0700 (PDT) Sender: Fernando Gont Message-ID: <4FE0B9EC.9020907@gont.com.ar> Date: Tue, 19 Jun 2012 19:42:04 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Gunter Van de Velde (gvandeve)" References: <5C99EC8C99D9BB45AC51D20DC2AD2DC507D5EAD6@XMB-AMS-102.cisco.com> In-Reply-To: <5C99EC8C99D9BB45AC51D20DC2AD2DC507D5EAD6@XMB-AMS-102.cisco.com> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: opsec@ietf.org Subject: Re: [OPSEC] OPSEC: 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: Tue, 19 Jun 2012 17:42:13 -0000 HI, Gunter, I'd like agenda slots to present these I-Ds: * draft-gont-opsec-ipv6-host-scanning * draft-gont-opsec-ipv6-implications-on-ipv4-nets * draft-gont-opsec-dhcpv6-shield * draft-gont-opsec-ipv6-nd-shield-00 P.S.: PLease ack :-) Thanks! Best regards, Fernando On 06/19/2012 11:00 AM, Gunter Van de Velde (gvandeve) wrote: > Dear all, > > > > Please know that we are starting to work on the agenda for the OPSEC WG. > > > > Please let us know if you desire a speaking slot during IETF84. > > > > G/ > > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From gvandeve@cisco.com Wed Jun 20 01:46:14 2012 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 7E62C21F870E for ; Wed, 20 Jun 2012 01:46:14 -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 RZpxBV3Y-4Ls for ; Wed, 20 Jun 2012 01:46:14 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id AC6A421F870B for ; Wed, 20 Jun 2012 01:46:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=3128; q=dns/txt; s=iport; t=1340181973; x=1341391573; h=mime-version:subject:date:message-id:from:to; bh=jF9BslvShDX77mAAD0kCkruCpr60dBWd/jrdPx2GkzE=; b=Wo4yMqbbevpnMWmlJt/OyvBs6x9lyPGsDtxj1qfxPwotcvWLH17A+yqX /iO2KixS6mW0ja0sXqtC/fFtEYg2g2U5D/R3TP/ZK2MFCkhfL8m+Dut0B GdLX8p5BTjNjB/pYkHTBIASlkf+P6ulo84Fm58h6yr8rCTWblBD+P5Ym4 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEKN4U+Q/khR/2dsb2JhbABFgkWzGYEHghoBBBIBCREDWwEMHgYTBQdXAQQbGodpC5djgSigPYsugn+CPGADljuNCYFmgmE X-IronPort-AV: E=Sophos;i="4.77,440,1336348800"; d="scan'208,217";a="5994137" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 20 Jun 2012 08:46:12 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q5K8kCLk007763 for ; Wed, 20 Jun 2012 08:46:12 GMT Received: from xmb-ams-102.cisco.com ([144.254.74.77]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Jun 2012 10:46:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD4EC1.252B1CC1" Date: Wed, 20 Jun 2012 10:46:11 +0200 Message-ID: <5C99EC8C99D9BB45AC51D20DC2AD2DC507DDC4FB@XMB-AMS-102.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft: Filtering and Rate Limiting Capabilities for IP Network Infrastructure (draft-ietf-opsec-filter-caps-09) Thread-Index: Ac1OwSRvY+wHvg0JTpqCxyHBAUzx1g== From: "Gunter Van de Velde (gvandeve)" To: X-OriginalArrivalTime: 20 Jun 2012 08:46:12.0432 (UTC) FILETIME=[25418D00:01CD4EC1] Subject: [OPSEC] Draft: Filtering and Rate Limiting Capabilities for IP Network Infrastructure (draft-ietf-opsec-filter-caps-09) 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, 20 Jun 2012 08:46:14 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD4EC1.252B1CC1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 In the list of drafts at OPSEC charter there is: http://tools.ietf.org/html/draft-ietf-opsec-filter-caps-09 =20 with my WG chair hat on, does the initial team of editors want to update the draft and bring it into 2012? =20 G/ ------_=_NextPart_001_01CD4EC1.252B1CC1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

In the list of drafts at OPSEC = charter there is:

http:= //tools.ietf.org/html/draft-ietf-opsec-filter-caps-09

 

with my WG chair hat on, does = the initial team of editors want to update the draft and bring it into = 2012?

 

G/

------_=_NextPart_001_01CD4EC1.252B1CC1-- From christopher.morrow@gmail.com Wed Jun 20 07:15:34 2012 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 D6B5421F8769 for ; Wed, 20 Jun 2012 07:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tF799htvpZzs for ; Wed, 20 Jun 2012 07:15:34 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D82AB21F8766 for ; Wed, 20 Jun 2012 07:15:33 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so12086174obb.31 for ; Wed, 20 Jun 2012 07:15:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=MBfPHdb++a8kV8nsVF9EYVDKteyBBwL0ENqBkbH55wo=; b=gWoppIykPbT29r3bOLpIUUIyrWDuYU6A4cNYoH9P0+IuJ6C66QL09oDI/Uv7PNnxJm 5DMnntqqeiKRSZQK4nn+Xal2qROiy8Lfyqq9GF5v1MyRdtKSxnK76zSF4YZ2ImobJhgp u7U2Tr2+/KErvDZ+T+l5VDM1PKaRL/nHxe+epQ63yf7+eo+spze1sJRF7XNeK6zOvOB0 7oDFprYH8w1/qQobzLbZiB/9Ti9wSLL9Ky/pQkaQMv1UJ4riTZNuKgkNUF2AwmnxtMLA qyHA2uyQ6HLr/uFwdd44fjoN71KhGjd1jHhiXRch+0nzZE11R5PzTjdyvnllNHyI2u/Z qDXA== MIME-Version: 1.0 Received: by 10.182.228.6 with SMTP id se6mr23592854obc.29.1340201733473; Wed, 20 Jun 2012 07:15:33 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.138.10 with HTTP; Wed, 20 Jun 2012 07:15:33 -0700 (PDT) In-Reply-To: <5C99EC8C99D9BB45AC51D20DC2AD2DC507DDC4FB@XMB-AMS-102.cisco.com> References: <5C99EC8C99D9BB45AC51D20DC2AD2DC507DDC4FB@XMB-AMS-102.cisco.com> Date: Wed, 20 Jun 2012 10:15:33 -0400 X-Google-Sender-Auth: 1eRjaUDc4pZ9DKqxLMEdkeaON5I Message-ID: From: Christopher Morrow To: "Gunter Van de Velde (gvandeve)" Content-Type: text/plain; charset=ISO-8859-1 Cc: opsec@ietf.org Subject: Re: [OPSEC] Draft: Filtering and Rate Limiting Capabilities for IP Network Infrastructure (draft-ietf-opsec-filter-caps-09) 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, 20 Jun 2012 14:15:35 -0000 On Wed, Jun 20, 2012 at 4:46 AM, Gunter Van de Velde (gvandeve) wrote: > Hi all, > > > > In the list of drafts at OPSEC charter there is: > > http://tools.ietf.org/html/draft-ietf-opsec-filter-caps-09 > > > > with my WG chair hat on, does the initial team of editors want to update the > draft and bring it into 2012? would love to, but it seems to have fallen out of the capabilities list (or rather the original capablities list died off). From eludom@gmail.com Thu Jun 21 04:09:43 2012 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 D886321F85C7 for ; Thu, 21 Jun 2012 04:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1W0V-ObPYe-q for ; Thu, 21 Jun 2012 04:09:43 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2D28821F85C0 for ; Thu, 21 Jun 2012 04:09:43 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so282886vbb.31 for ; Thu, 21 Jun 2012 04:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=od25xez09DgOGfNHJBuosUeLII4rkRgW6eFJzHH4Xrc=; b=vOFhswmWLiRTxLNtcVV45ma2RFADUrs43R9rutNu8Rkfv2zqzlQ0zrie/CBruujX7C u9uIu+XZtSb0kziXQSe5Qfgh/KfVUWTdOfI9QytmYoHApD/KtdpaWfEcF15X8drtRFip bTgLWqO47Yn/rSo+5oTqPvUPN0hVi3+2hsogLi6LJ/4dV7IMg5v7vNrrzZ0OfZuFi6oH E83yEFq449uTZhffpyuOgx/l7RpjjpEniKZ+MJ4vzwLiM9hWDvyInawjlALYJgA35GGp IkSayERbuhKCW6nsquKjcSShK0hPaCqUMkZcp1HCIb35ya1MPSpjLoQ5Y93XwnRmal9J +Uyw== MIME-Version: 1.0 Received: by 10.52.73.42 with SMTP id i10mr10967876vdv.116.1340276982644; Thu, 21 Jun 2012 04:09:42 -0700 (PDT) Received: by 10.52.113.200 with HTTP; Thu, 21 Jun 2012 04:09:42 -0700 (PDT) In-Reply-To: References: <5C99EC8C99D9BB45AC51D20DC2AD2DC507DDC4FB@XMB-AMS-102.cisco.com> Date: Thu, 21 Jun 2012 07:09:42 -0400 Message-ID: From: George Jones To: Christopher Morrow Content-Type: multipart/alternative; boundary=20cf3071c664737f4a04c2f98db0 Cc: opsec@ietf.org Subject: Re: [OPSEC] Draft: Filtering and Rate Limiting Capabilities for IP Network Infrastructure (draft-ietf-opsec-filter-caps-09) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gmj@pobox.com List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 11:09:44 -0000 --20cf3071c664737f4a04c2f98db0 Content-Type: text/plain; charset=ISO-8859-1 That document existed in the context of http://tools.ietf.org/html/draft-ietf-opsec-framework-05 specifically, section 2.4. The framework was the roadmap for an earlier instantiation of the working group. For various reasons (including lack of authors) that vision was never fully fleshed out. The filter-caps document could be revived. It would probably have to be re-worked as a standalone unless the WG wants to revisit/revive the framework. ---George Jones On Wed, Jun 20, 2012 at 10:15 AM, Christopher Morrow < morrowc.lists@gmail.com> wrote: > On Wed, Jun 20, 2012 at 4:46 AM, Gunter Van de Velde (gvandeve) > wrote: > > Hi all, > > > > > > > > In the list of drafts at OPSEC charter there is: > > > > http://tools.ietf.org/html/draft-ietf-opsec-filter-caps-09 > > > > > > > > with my WG chair hat on, does the initial team of editors want to update > the > > draft and bring it into 2012? > > would love to, but it seems to have fallen out of the capabilities > list (or rather the original capablities list died off). > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > --20cf3071c664737f4a04c2f98db0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
That document existed in the context of=A0

=A0 http://to= ols.ietf.org/html/draft-ietf-opsec-framework-05

spec= ifically, section 2.4.

The framework was the roadmap for an earlier instantiat= ion of the working group.
For various reasons (including lack of = authors) that vision was never fully fleshed out.

The filter-caps document could be revived. =A0 It would probably have to be= re-worked as a standalone=A0
unless the WG wants to revisit/revi= ve the framework.

---George Jones

On Wed, Jun 20, 2012 at 10:15 AM, Christopher Morrow <= morrowc.lists@= gmail.com> wrote:
On Wed, Jun 20, 2012 at 4:46 AM, Gu= nter Van de Velde (gvandeve)
<gvandeve@cisco.com> wrote:=
> Hi all,
>
>
>
> In the list of drafts at OPSEC charter there is:
>
> http://tools.ietf.org/html/draft-ietf-opsec-filter-caps-= 09
>
>
>
> with my WG chair hat on, does the initial team of editors want to upda= te the
> draft and bring it into 2012?

would love to, but it seems to have fallen out of the capabilit= ies
list (or rather the original capablities list died off).
_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/opsec

--20cf3071c664737f4a04c2f98db0-- From gvandeve@cisco.com Fri Jun 22 04:59:56 2012 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 3CF6521F86C4 for ; Fri, 22 Jun 2012 04:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.486 X-Spam-Level: X-Spam-Status: No, score=-10.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 ktCT3o2VkXoc for ; Fri, 22 Jun 2012 04:59:55 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 713EB21F86B0 for ; Fri, 22 Jun 2012 04:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=1305; q=dns/txt; s=iport; t=1340366395; x=1341575995; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=VXRJUPBvFpiRQEJQtxsScwfcIMuEdfTluE/DxMiK7XI=; b=PltCWctzEN+ZSlqFAe3n/YRlZfOt8HQgCqW8zflPtEghqmGjpFD9jWdd VfYb/4FPXlh+457BZ/p+i4k5q1WDG/eVj5ll9zhL5O0MNM0rDnaQzb6IM gQfPWPOttx4OHU3xWX2eLS0F7oV3nokTa2AbwXdTMR1AfjlvLxsrtZ6gf M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAPhc5E+Q/khL/2dsb2JhbABFtWOBB4IYAQEBBAEBAQ8BChMKNAsMBAIBCBEEAQEBCgYXAQYBIAYfCQgBAQQTCBYEh1sDCwuZZJYyDYlKBIpLYxqFCGADoC6DGYFmgmGBXQ X-IronPort-AV: E=Sophos;i="4.77,458,1336348800"; d="scan'208";a="6108421" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 22 Jun 2012 11:59:50 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5MBxoAD031108; Fri, 22 Jun 2012 11:59:50 GMT Received: from xmb-ams-102.cisco.com ([144.254.74.77]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Jun 2012 13:59:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Jun 2012 13:59:44 +0200 Message-ID: <5C99EC8C99D9BB45AC51D20DC2AD2DC507DDCF45@XMB-AMS-102.cisco.com> In-Reply-To: <4FE0B9EC.9020907@gont.com.ar> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSEC] OPSEC: Call for agenda items Thread-Index: Ac1OQupMtAzqrLZGTC6KPNZV21Z81gCK0tkg References: <5C99EC8C99D9BB45AC51D20DC2AD2DC507D5EAD6@XMB-AMS-102.cisco.com> <4FE0B9EC.9020907@gont.com.ar> From: "Gunter Van de Velde (gvandeve)" To: "Fernando Gont" X-OriginalArrivalTime: 22 Jun 2012 11:59:51.0252 (UTC) FILETIME=[87704940:01CD506E] Cc: opsec@ietf.org Subject: Re: [OPSEC] OPSEC: 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: Fri, 22 Jun 2012 11:59:56 -0000 Request received. Many thanks. Let us first see how many other will ask for a slot, and then decide upon a priority list for topics to discuss. G/ -----Original Message----- From: Fernando Gont [mailto:fernando.gont.netbook.win@gmail.com] On Behalf Of Fernando Gont Sent: dinsdag 19 juni 2012 19:42 To: Gunter Van de Velde (gvandeve) Cc: opsec@ietf.org Subject: Re: [OPSEC] OPSEC: Call for agenda items HI, Gunter, I'd like agenda slots to present these I-Ds: * draft-gont-opsec-ipv6-host-scanning * draft-gont-opsec-ipv6-implications-on-ipv4-nets * draft-gont-opsec-dhcpv6-shield * draft-gont-opsec-ipv6-nd-shield-00 P.S.: PLease ack :-) Thanks! Best regards, Fernando On 06/19/2012 11:00 AM, Gunter Van de Velde (gvandeve) wrote: > Dear all, >=20 > =20 >=20 > Please know that we are starting to work on the agenda for the OPSEC WG. >=20 > =20 >=20 > Please let us know if you desire a speaking slot during IETF84. >=20 > =20 >=20 > G/ >=20 >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec --=20 Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1