From gvandeve@cisco.com Mon Jan 2 02:42:59 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 5A9D621F8D53 for ; Mon, 2 Jan 2012 02:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 l0WaA2w7dV3u for ; Mon, 2 Jan 2012 02:42:58 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id A886621F8CED for ; Mon, 2 Jan 2012 02:42:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=6451; q=dns/txt; s=iport; t=1325500977; x=1326710577; h=mime-version:subject:date:message-id:from:to; bh=GmwzavrLgJVofSrTnFuzCMyIZ0/g3ZPKtwKdbMtVOAI=; b=kG8vO+91kRDWYoM0Lv5nIPpf1v9jRhOsicitwY5gM2REY+oMcF6iTaBZ etEie+IVZfdpIpN/0h3BzeYhuznbXvUpa8rF7RVZAUsFbK8qXET0B2RUJ Cec1kUG7r8M+iCpy7AOxesh1LWq4R2q5QQzeIY/E9GzPNycjlJ+yP2psb U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkjACWJAU+Q/khR/2dsb2JhbABEggVJp1CCOIEFgXQBBBIBCREDWwEqBhgHVwEEGxqdDoEmAY0ekBOIdYI3YwSnNw X-IronPort-AV: E=Sophos;i="4.71,444,1320624000"; d="scan'208,217";a="125192495" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 02 Jan 2012 10:42:55 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q02AgtF4001829 for ; Mon, 2 Jan 2012 10:42:55 GMT Received: from xmb-ams-101.cisco.com ([144.254.74.76]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Jan 2012 11:42:55 +0100 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_01CCC93B.4924A41C" Date: Mon, 2 Jan 2012 11:42:54 +0100 Message-ID: <4269EA985EACD24987D82DAE2FEC62E504D1548C@XMB-AMS-101.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Milestones between now and IETF83 in Paris Thread-Index: AczJO0i0kgShcWFaSK+lJBOzHl74Tw== From: "Gunter Van de Velde (gvandeve)" To: X-OriginalArrivalTime: 02 Jan 2012 10:42:55.0552 (UTC) FILETIME=[49375C00:01CCC93B] Subject: [OPSEC] Milestones between now and IETF83 in Paris 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, 02 Jan 2012 10:42:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCC93B.4924A41C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I copied this from the v6OPS alias. =20 As we are approaching the New Year and the halfway point between the previous meeting and the next one, I thought it germain to enumerate the milestones. The following are the relevant document submission and scheduling milestones for IETF 83. =20 2012- 02-13 (Monday): Cutoff date for BOF proposal requests to Area Directors at 17:00 PT (UTC -8). To request a BOF, please see instructions on Requesting a BOF. =20 2012-02-23 (Thursday): Preliminary agenda published for comment. =20 2012-02-27 (Monday): Working Group Chair approval for initial document (Version -00) submissions appreciated by 17:00 PT (UTC -8). =20 2012-03-02 (Friday): Final agenda to be published. =20 2012-03-05 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PT (UTC -8), upload using IETF ID Submission Tool. =20 2012-03-12 (Monday): Internet Draft final submission cut-off by 17:00 PT (UTC -7), upload using IETF ID Submission Tool. =20 2012-03-14 (Wednesday): Draft Working Group agendas due by 17:00 PT (UTC -7), upload using IETF Meeting Materials Management Tool. =20 2012-03-25 - 2012-03-30: 83rd IETF Meeting in Paris, France. =20 =20 G/ ------_=_NextPart_001_01CCC93B.4924A41C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I copied this from the v6OPS = alias.

 

As we are approaching the New = Year and the halfway point between the previous meeting and the next one, I = thought it germain to enumerate the milestones. The following are the relevant = document submission and scheduling milestones for IETF 83.

 

2012- 02-13 (Monday): Cutoff = date for BOF proposal requests to Area Directors at 17:00 PT (UTC -8). To request = a BOF, please see instructions on Requesting a BOF.

 

2012-02-23 (Thursday): = Preliminary agenda published for comment.

 

2012-02-27 (Monday): Working = Group Chair approval for initial document (Version -00) submissions appreciated by = 17:00 PT (UTC -8).

 

2012-03-02 (Friday): Final = agenda to be published.

 

2012-03-05 (Monday): Internet = Draft Cut-off for initial document (-00) submission by 17:00 PT (UTC -8), = upload using IETF ID Submission Tool.

 

2012-03-12 (Monday): Internet = Draft final submission cut-off by 17:00 PT (UTC -7), upload using IETF ID = Submission Tool.

 

2012-03-14 (Wednesday): Draft = Working Group agendas due by 17:00 PT (UTC -7), upload using IETF Meeting = Materials Management Tool.

 

2012-03-25 - 2012-03-30: 83rd = IETF Meeting in Paris, France.

 

 

G/

------_=_NextPart_001_01CCC93B.4924A41C-- From cpignata@cisco.com Mon Jan 23 10:12:50 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 D91A821F85D7 for ; Mon, 23 Jan 2012 10:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.443 X-Spam-Level: X-Spam-Status: No, score=-108.443 tagged_above=-999 required=5 tests=[AWL=-1.857, BAYES_20=-0.74, FRT_BELOW2=2.154, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xhz+WfZZcnu for ; Mon, 23 Jan 2012 10:12:49 -0800 (PST) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id ACA5F21F8478 for ; Mon, 23 Jan 2012 10:12:49 -0800 (PST) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q0NICmic014384 for ; Mon, 23 Jan 2012 13:12:48 -0500 (EST) Received: from [64.102.157.104] (dhcp-64-102-157-104.cisco.com [64.102.157.104]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q0NIClDl022786; Mon, 23 Jan 2012 13:12:48 -0500 (EST) Message-ID: <4F1DA31E.5080608@cisco.com> Date: Mon, 23 Jan 2012 13:12:46 -0500 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Fernando Gont References: <4DB74CBD.2050003@gont.com.ar> <4DCCA138.2000908@cisco.com> <4DD5F510.5060405@gont.com.ar> <4DF8D73F.7020803@cisco.com> <4EEC00AD.8020702@gont.com.ar> In-Reply-To: <4EEC00AD.8020702@gont.com.ar> X-Enigmail-Version: 1.3.4 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] Fwd: New Version Notification for draft-gont-opsec-ip-options-filtering-01 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, 23 Jan 2012 18:12:51 -0000 Hi, Fernando, Please see inline. On 12/16/2011 9:38 PM, Fernando Gont wrote: > Hi, Carlos, > > My apologies for the delay in my response. Please find my comments inline... > > On 06/15/2011 01:01 PM, Carlos Pignataro wrote: >> In a way, the comment behind my comment was that if today optioned >> packets are already mostly blocked/filtered out, the value of a >> per-option analysis decreases. >> >> Dan Wing was kind enough to run his experiment with existing options (as >> opposed to unknown options), with these results: >> >> Without any IP options: >> # grep open normal-nop.out | wc >> 486 2430 29901 > > Sorry, what does each of the columns stand for? > This is the standard output of `wc` (word count), where the columns are number of lines, words, and characters, respectively. Only the first column is meaningful here (wc -l), and the important piece was that you get only a 3.29% success when using known options. Without any IP options: # grep open normal-nop.out | wc 486 2430 29901 ^^^ with just NOP, NOP, NOP, EOL: // --ip-options \x01\x01\x01\x00 # grep open ip-options-nop.out | wc 16 80 1099 ^^ And 16 is a 3.29% of 486. [BTW: the script is at ] > > >> I am not aware of papers with more scientific analysis of success rates >> with existing options. But: >> >> --->8--- >> Data seems to indicate that there is a current widespread >> practice of blocking IPv4 optioned packets. There are various >> plausible approaches to minimize the potential negative effects >> of IPv4 optioned packets while allowing some options semantics. >> One approach is to allow for specific options that are expected >> or needed, and a default deny. A different approach is to deny >> unneeded options and a default allow. Yet a third option is to >> allow for end-to-end semantics by ignoring options and treating >> packets as unoptioned while in transit. The current state tends >> to support the first or third approaches as more realistic. >> --->8--- > > I've added this (verbatim) to the intro, and have also added a pointer > to Medina's paper. > Ack -- Thanks! > >>>> 2. It assumes that devices (i.e., routers) have the capability to filter >>>> IP optioned packets with the per-option-value granularity. This might >>>> not generally be the case. >> >> I think this point should also be clarified. > > Done in the intro (right bellow the text you suggested above): > > --- cut here --- > We also note that while this document provides advice on a "per IP > option type", not all devices may provide functionality to filter IP > packets on a "per IP option type". Additionally, even in cases in which > such functionality is provided, the operator might want to specify a > filtering policy with a coarser granularity (rather than on a "per IP > option type" granularity), as indicated above. > ---- cut here --- > Thanks. > >>> I disagree with this assessment. The document assesses the impact of >>> filtering different options. If you're fine with the impact of filtering >>> all ip-optioned packets, then you don't need to filter at the >>> granularity of per-option-type. >> >> I guess what I was thinking is that an operator could think "what do I >> lose if I block this option" and do that exercise for every option, or >> "what do I gain by allowing", and this is where the (apparent) current >> practice has a role in deciding this. > > I think this is addressed by the text that you've provided? > I think so, I will re-read it too. > >>>> Additionally, >>>> >>>> 4. There may be more than "filter" versus "not-filter" options. Some >>>> platforms support ignoring IP options (i.e., acting as if an IP Optioned >>>> packet did not have options), and that is a potential recommendation. >>> >>> IIRC, this is already mentioned in the document. >>> >> >> I could not find it. Could you please point to the specific para? >> >> I think this is quite important because I think this is another practice >> often seen as the best option. > > You were right -- it wasn't there. I have added this to the intro: > > ---- cut here ---- > Finally, in scenarios in which processing of IP options by intermediate > systems is not required, a widespread approach is to simply ignore IP > options, and processs the corresponding packets as if they do not > contain any IP options. > --- cut here --- > Thanks -- note a typo, s/processs/process/; > >>>> The first sentence of Section 3, "Router manufacturers tend to do IP >>>> option processing on the main processor, rather than on line cards", >>>> speaks to specific router distributed architecture, and I think it might >>>> be oversimplifying the current state. >>> >>> Proposed change? >> >> http://tools.ietf.org/html/rfc6192#section-1 >> >> Modern router architecture design maintains a strict separation of >> forwarding and router control plane hardware and software. The >> >> There are possible things like ICMP generation and IP option processing >> on general use processors in Line Cards, as opposed to LC forwarding >> ASICs. It is a punt to a slower path. But not necessarily a punt to the >> RP -- there may not be "main processor" but "main processors" depending >> on the context, and abstracting from actual architectures helps the >> document be more time invariant. > > How about changing the text to: > "Router manufacturers tend to do IP option processing in slower path. ^"a" > Unless special care is taken, this represents Denial of Service (DoS) ^ "a potential" > risk, as there is potential for overwhelming the router with option ^^^^^^^^^^^^^^^^^^^^^^^ I'd remove this and add "if protective measures are not taken". > processing." > ? > Looks good, modulo quick comments. > >>>> For EOO and NOOP, the advise is to: >>>> >>>> No security issues are known for this option, other than the general >>>> security implications of IP options discussed in Section 2. >>>> >>>> But I think that the general implications are the most important part of >>>> this document but are minimal. >>> >>> hence? >> >> Well, Section 2 is the default gateway for general implications >> applicable to all options but IMHO inadequately covers that subject. To >> be more precise, it does not cover it. > > Can you specify what (exactly) you're referring to, so that I can > improve the document in this respect? > The text says "general security implications of IP options discussed in Section 2", but there are no security implications discussed in S2. > > >> Section 2 does not have general security implications of IP options. It >> seems to contain a guide as to what options are (semantics and syntax) >> but not security implications. > > I've changed the ref to the one about the processing requirements. > Things can be improved from there. > > P.S.: I've submitted a rev of the document, since it had expired. It is > available at: > . > Please take a look and see if any of the issues raised in this e-mail > still needs to be addressed. (It still need to work on other feedback > you provided in other e-mails). > > Thanks! > > Best regards, Sounds good. Thanks, -- Carlos. From fernando.gont.netbook.win@gmail.com Mon Jan 23 12:27:17 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 229B821F852E for ; Mon, 23 Jan 2012 12:27:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.747 X-Spam-Level: X-Spam-Status: No, score=-0.747 tagged_above=-999 required=5 tests=[AWL=-2.100, BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_SORBS_HTTP=0.001, RCVD_IN_SORBS_MISC=0.353, RCVD_IN_SORBS_SOCKS=0.801] 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 pFMsJmfgCC9u for ; Mon, 23 Jan 2012 12:27:16 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id F343821F84B8 for ; Mon, 23 Jan 2012 12:27:15 -0800 (PST) Received: by yenm3 with SMTP id m3so1578224yen.31 for ; Mon, 23 Jan 2012 12:27:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=1aUsr+4ZGxEHn+/ggX9DnO+941y4O6yEo6GBDcmTJd4=; b=WJGNmzPODrCKZ0YvS26duvlfh1PywjCSS7+R2iI07CQZoa1sMcp8BrhRQ2KiUhVsL3 JEBEvWfAUtYhtrEfQ+NYi+EtbxMiIRe5GUuPLwU40mbfXQlN5oJjs3dKe60KkBmuoHE3 Lqp9qLv+c4cjwHhDkwT3W3lR5SR7wZYekMCf0= Received: by 10.236.131.38 with SMTP id l26mr14043153yhi.70.1327350434389; Mon, 23 Jan 2012 12:27:14 -0800 (PST) Received: from [192.168.0.45] ([190.48.228.56]) by mx.google.com with ESMTPS id o16sm37832694ank.14.2012.01.23.12.27.11 (version=SSLv3 cipher=OTHER); Mon, 23 Jan 2012 12:27:13 -0800 (PST) Sender: Fernando Gont Message-ID: <4F1DC29D.5050209@gont.com.ar> Date: Mon, 23 Jan 2012 17:27:09 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Carlos Pignataro References: <4DB74CBD.2050003@gont.com.ar> <4DCCA138.2000908@cisco.com> <4DD5F510.5060405@gont.com.ar> <4DF8D73F.7020803@cisco.com> <4EEC00AD.8020702@gont.com.ar> <4F1DA31E.5080608@cisco.com> In-Reply-To: <4F1DA31E.5080608@cisco.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] Fwd: New Version Notification for draft-gont-opsec-ip-options-filtering-01 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, 23 Jan 2012 20:27:17 -0000 Hi, Carlos, Is there anything that still need to be addressed in the document? (modulo nits and the quick fixes you highlighted in your last e-mail)? Thanks, Fernando On 01/23/2012 03:12 PM, Carlos Pignataro wrote: > On 12/16/2011 9:38 PM, Fernando Gont wrote: >> Hi, Carlos, >> >> My apologies for the delay in my response. Please find my comments inline... >> >> On 06/15/2011 01:01 PM, Carlos Pignataro wrote: >>> In a way, the comment behind my comment was that if today optioned >>> packets are already mostly blocked/filtered out, the value of a >>> per-option analysis decreases. >>> >>> Dan Wing was kind enough to run his experiment with existing options (as >>> opposed to unknown options), with these results: >>> >>> Without any IP options: >>> # grep open normal-nop.out | wc >>> 486 2430 29901 >> >> Sorry, what does each of the columns stand for? >> > > This is the standard output of `wc` (word count), where the columns are > number of lines, words, and characters, respectively. Only the first > column is meaningful here (wc -l), and the important piece was that you > get only a 3.29% success when using known options. > > Without any IP options: > # grep open normal-nop.out | wc > 486 2430 29901 > ^^^ > with just NOP, NOP, NOP, EOL: // --ip-options \x01\x01\x01\x00 > # grep open ip-options-nop.out | wc > 16 80 1099 > ^^ > And 16 is a 3.29% of 486. > > [BTW: the script is at ] > >> >> >>> I am not aware of papers with more scientific analysis of success rates >>> with existing options. But: >>> >>> --->8--- >>> Data seems to indicate that there is a current widespread >>> practice of blocking IPv4 optioned packets. There are various >>> plausible approaches to minimize the potential negative effects >>> of IPv4 optioned packets while allowing some options semantics. >>> One approach is to allow for specific options that are expected >>> or needed, and a default deny. A different approach is to deny >>> unneeded options and a default allow. Yet a third option is to >>> allow for end-to-end semantics by ignoring options and treating >>> packets as unoptioned while in transit. The current state tends >>> to support the first or third approaches as more realistic. >>> --->8--- >> >> I've added this (verbatim) to the intro, and have also added a pointer >> to Medina's paper. >> > > Ack -- Thanks! > >> >>>>> 2. It assumes that devices (i.e., routers) have the capability to filter >>>>> IP optioned packets with the per-option-value granularity. This might >>>>> not generally be the case. >>> >>> I think this point should also be clarified. >> >> Done in the intro (right bellow the text you suggested above): >> >> --- cut here --- >> We also note that while this document provides advice on a "per IP >> option type", not all devices may provide functionality to filter IP >> packets on a "per IP option type". Additionally, even in cases in which >> such functionality is provided, the operator might want to specify a >> filtering policy with a coarser granularity (rather than on a "per IP >> option type" granularity), as indicated above. >> ---- cut here --- >> > > Thanks. > >> >>>> I disagree with this assessment. The document assesses the impact of >>>> filtering different options. If you're fine with the impact of filtering >>>> all ip-optioned packets, then you don't need to filter at the >>>> granularity of per-option-type. >>> >>> I guess what I was thinking is that an operator could think "what do I >>> lose if I block this option" and do that exercise for every option, or >>> "what do I gain by allowing", and this is where the (apparent) current >>> practice has a role in deciding this. >> >> I think this is addressed by the text that you've provided? >> > > I think so, I will re-read it too. > >> >>>>> Additionally, >>>>> >>>>> 4. There may be more than "filter" versus "not-filter" options. Some >>>>> platforms support ignoring IP options (i.e., acting as if an IP Optioned >>>>> packet did not have options), and that is a potential recommendation. >>>> >>>> IIRC, this is already mentioned in the document. >>>> >>> >>> I could not find it. Could you please point to the specific para? >>> >>> I think this is quite important because I think this is another practice >>> often seen as the best option. >> >> You were right -- it wasn't there. I have added this to the intro: >> >> ---- cut here ---- >> Finally, in scenarios in which processing of IP options by intermediate >> systems is not required, a widespread approach is to simply ignore IP >> options, and processs the corresponding packets as if they do not >> contain any IP options. >> --- cut here --- >> > > Thanks -- note a typo, s/processs/process/; > >> >>>>> The first sentence of Section 3, "Router manufacturers tend to do IP >>>>> option processing on the main processor, rather than on line cards", >>>>> speaks to specific router distributed architecture, and I think it might >>>>> be oversimplifying the current state. >>>> >>>> Proposed change? >>> >>> http://tools.ietf.org/html/rfc6192#section-1 >>> >>> Modern router architecture design maintains a strict separation of >>> forwarding and router control plane hardware and software. The >>> >>> There are possible things like ICMP generation and IP option processing >>> on general use processors in Line Cards, as opposed to LC forwarding >>> ASICs. It is a punt to a slower path. But not necessarily a punt to the >>> RP -- there may not be "main processor" but "main processors" depending >>> on the context, and abstracting from actual architectures helps the >>> document be more time invariant. >> >> How about changing the text to: >> "Router manufacturers tend to do IP option processing in slower path. > ^"a" >> Unless special care is taken, this represents Denial of Service (DoS) > ^ "a potential" >> risk, as there is potential for overwhelming the router with option > ^^^^^^^^^^^^^^^^^^^^^^^ > I'd remove this and add "if protective measures are not taken". >> processing." >> ? >> > > Looks good, modulo quick comments. > >> >>>>> For EOO and NOOP, the advise is to: >>>>> >>>>> No security issues are known for this option, other than the general >>>>> security implications of IP options discussed in Section 2. >>>>> >>>>> But I think that the general implications are the most important part of >>>>> this document but are minimal. >>>> >>>> hence? >>> >>> Well, Section 2 is the default gateway for general implications >>> applicable to all options but IMHO inadequately covers that subject. To >>> be more precise, it does not cover it. >> >> Can you specify what (exactly) you're referring to, so that I can >> improve the document in this respect? >> > > The text says "general security implications of IP options discussed in > Section 2", but there are no security implications discussed in S2. > >> >> >>> Section 2 does not have general security implications of IP options. It >>> seems to contain a guide as to what options are (semantics and syntax) >>> but not security implications. >> >> I've changed the ref to the one about the processing requirements. >> Things can be improved from there. >> >> P.S.: I've submitted a rev of the document, since it had expired. It is >> available at: >> . >> Please take a look and see if any of the issues raised in this e-mail >> still needs to be addressed. (It still need to work on other feedback >> you provided in other e-mails). >> >> Thanks! >> >> Best regards, > > Sounds good. > > Thanks, > > -- Carlos. > -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From cpignata@cisco.com Mon Jan 23 12:37: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 A137021F85D2 for ; Mon, 23 Jan 2012 12:37:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.218 X-Spam-Level: X-Spam-Status: No, score=-109.218 tagged_above=-999 required=5 tests=[AWL=-0.773, BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQU-qaNIFlFY for ; Mon, 23 Jan 2012 12:37:53 -0800 (PST) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id B5B8021F8525 for ; Mon, 23 Jan 2012 12:37:53 -0800 (PST) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q0NKbrBc028897 for ; Mon, 23 Jan 2012 15:37:53 -0500 (EST) Received: from [64.102.157.104] (dhcp-64-102-157-104.cisco.com [64.102.157.104]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q0NKbqEk024682; Mon, 23 Jan 2012 15:37:52 -0500 (EST) Message-ID: <4F1DC51F.8020901@cisco.com> Date: Mon, 23 Jan 2012 15:37:51 -0500 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Fernando Gont References: <4DB74CBD.2050003@gont.com.ar> <4DCCA138.2000908@cisco.com> <4DD5F510.5060405@gont.com.ar> <4DF8D73F.7020803@cisco.com> <4EEC00AD.8020702@gont.com.ar> <4F1DA31E.5080608@cisco.com> <4F1DC29D.5050209@gont.com.ar> In-Reply-To: <4F1DC29D.5050209@gont.com.ar> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] Fwd: New Version Notification for draft-gont-opsec-ip-options-filtering-01 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, 23 Jan 2012 20:37:56 -0000 Hi, Fernando, >From my perspective, without re-reading the document end-to-end just yet (since June 2011), I think that there's potentially a couple of things (besides the additions below): 1. You mentioned there were generic security requirements for all options irrespective of the per-option-value considerations, but I am not sure where that is -- is that S2, S3, or a new section? 2. Checking there seem to be some options not covered. Somewhat editorial, but really speaking to readability and ease to access of info in the document, how are the sections sorted (not by option Value, seems also not by option Number). Thanks, -- Carlos. On 1/23/2012 3:27 PM, Fernando Gont wrote: > Hi, Carlos, > > Is there anything that still need to be addressed in the document? > (modulo nits and the quick fixes you highlighted in your last e-mail)? > > Thanks, > Fernando > > > > > On 01/23/2012 03:12 PM, Carlos Pignataro wrote: > >> On 12/16/2011 9:38 PM, Fernando Gont wrote: >>> Hi, Carlos, >>> >>> My apologies for the delay in my response. Please find my comments inline... >>> >>> On 06/15/2011 01:01 PM, Carlos Pignataro wrote: >>>> In a way, the comment behind my comment was that if today optioned >>>> packets are already mostly blocked/filtered out, the value of a >>>> per-option analysis decreases. >>>> >>>> Dan Wing was kind enough to run his experiment with existing options (as >>>> opposed to unknown options), with these results: >>>> >>>> Without any IP options: >>>> # grep open normal-nop.out | wc >>>> 486 2430 29901 >>> >>> Sorry, what does each of the columns stand for? >>> >> >> This is the standard output of `wc` (word count), where the columns are >> number of lines, words, and characters, respectively. Only the first >> column is meaningful here (wc -l), and the important piece was that you >> get only a 3.29% success when using known options. >> >> Without any IP options: >> # grep open normal-nop.out | wc >> 486 2430 29901 >> ^^^ >> with just NOP, NOP, NOP, EOL: // --ip-options \x01\x01\x01\x00 >> # grep open ip-options-nop.out | wc >> 16 80 1099 >> ^^ >> And 16 is a 3.29% of 486. >> >> [BTW: the script is at ] >> >>> >>> >>>> I am not aware of papers with more scientific analysis of success rates >>>> with existing options. But: >>>> >>>> --->8--- >>>> Data seems to indicate that there is a current widespread >>>> practice of blocking IPv4 optioned packets. There are various >>>> plausible approaches to minimize the potential negative effects >>>> of IPv4 optioned packets while allowing some options semantics. >>>> One approach is to allow for specific options that are expected >>>> or needed, and a default deny. A different approach is to deny >>>> unneeded options and a default allow. Yet a third option is to >>>> allow for end-to-end semantics by ignoring options and treating >>>> packets as unoptioned while in transit. The current state tends >>>> to support the first or third approaches as more realistic. >>>> --->8--- >>> >>> I've added this (verbatim) to the intro, and have also added a pointer >>> to Medina's paper. >>> >> >> Ack -- Thanks! >> >>> >>>>>> 2. It assumes that devices (i.e., routers) have the capability to filter >>>>>> IP optioned packets with the per-option-value granularity. This might >>>>>> not generally be the case. >>>> >>>> I think this point should also be clarified. >>> >>> Done in the intro (right bellow the text you suggested above): >>> >>> --- cut here --- >>> We also note that while this document provides advice on a "per IP >>> option type", not all devices may provide functionality to filter IP >>> packets on a "per IP option type". Additionally, even in cases in which >>> such functionality is provided, the operator might want to specify a >>> filtering policy with a coarser granularity (rather than on a "per IP >>> option type" granularity), as indicated above. >>> ---- cut here --- >>> >> >> Thanks. >> >>> >>>>> I disagree with this assessment. The document assesses the impact of >>>>> filtering different options. If you're fine with the impact of filtering >>>>> all ip-optioned packets, then you don't need to filter at the >>>>> granularity of per-option-type. >>>> >>>> I guess what I was thinking is that an operator could think "what do I >>>> lose if I block this option" and do that exercise for every option, or >>>> "what do I gain by allowing", and this is where the (apparent) current >>>> practice has a role in deciding this. >>> >>> I think this is addressed by the text that you've provided? >>> >> >> I think so, I will re-read it too. >> >>> >>>>>> Additionally, >>>>>> >>>>>> 4. There may be more than "filter" versus "not-filter" options. Some >>>>>> platforms support ignoring IP options (i.e., acting as if an IP Optioned >>>>>> packet did not have options), and that is a potential recommendation. >>>>> >>>>> IIRC, this is already mentioned in the document. >>>>> >>>> >>>> I could not find it. Could you please point to the specific para? >>>> >>>> I think this is quite important because I think this is another practice >>>> often seen as the best option. >>> >>> You were right -- it wasn't there. I have added this to the intro: >>> >>> ---- cut here ---- >>> Finally, in scenarios in which processing of IP options by intermediate >>> systems is not required, a widespread approach is to simply ignore IP >>> options, and processs the corresponding packets as if they do not >>> contain any IP options. >>> --- cut here --- >>> >> >> Thanks -- note a typo, s/processs/process/; >> >>> >>>>>> The first sentence of Section 3, "Router manufacturers tend to do IP >>>>>> option processing on the main processor, rather than on line cards", >>>>>> speaks to specific router distributed architecture, and I think it might >>>>>> be oversimplifying the current state. >>>>> >>>>> Proposed change? >>>> >>>> http://tools.ietf.org/html/rfc6192#section-1 >>>> >>>> Modern router architecture design maintains a strict separation of >>>> forwarding and router control plane hardware and software. The >>>> >>>> There are possible things like ICMP generation and IP option processing >>>> on general use processors in Line Cards, as opposed to LC forwarding >>>> ASICs. It is a punt to a slower path. But not necessarily a punt to the >>>> RP -- there may not be "main processor" but "main processors" depending >>>> on the context, and abstracting from actual architectures helps the >>>> document be more time invariant. >>> >>> How about changing the text to: >>> "Router manufacturers tend to do IP option processing in slower path. >> ^"a" >>> Unless special care is taken, this represents Denial of Service (DoS) >> ^ "a potential" >>> risk, as there is potential for overwhelming the router with option >> ^^^^^^^^^^^^^^^^^^^^^^^ >> I'd remove this and add "if protective measures are not taken". >>> processing." >>> ? >>> >> >> Looks good, modulo quick comments. >> >>> >>>>>> For EOO and NOOP, the advise is to: >>>>>> >>>>>> No security issues are known for this option, other than the general >>>>>> security implications of IP options discussed in Section 2. >>>>>> >>>>>> But I think that the general implications are the most important part of >>>>>> this document but are minimal. >>>>> >>>>> hence? >>>> >>>> Well, Section 2 is the default gateway for general implications >>>> applicable to all options but IMHO inadequately covers that subject. To >>>> be more precise, it does not cover it. >>> >>> Can you specify what (exactly) you're referring to, so that I can >>> improve the document in this respect? >>> >> >> The text says "general security implications of IP options discussed in >> Section 2", but there are no security implications discussed in S2. >> >>> >>> >>>> Section 2 does not have general security implications of IP options. It >>>> seems to contain a guide as to what options are (semantics and syntax) >>>> but not security implications. >>> >>> I've changed the ref to the one about the processing requirements. >>> Things can be improved from there. >>> >>> P.S.: I've submitted a rev of the document, since it had expired. It is >>> available at: >>> . >>> Please take a look and see if any of the issues raised in this e-mail >>> still needs to be addressed. (It still need to work on other feedback >>> you provided in other e-mails). >>> >>> Thanks! >>> >>> Best regards, >> >> Sounds good. >> >> Thanks, >> >> -- Carlos. >> > >