From internet-drafts@ietf.org Fri Feb 17 07:58: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 48A5021F84A2; Fri, 17 Feb 2012 07:58:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 pX1s+BJI+Vsr; Fri, 17 Feb 2012 07:58:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA0C21F87E5; Fri, 17 Feb 2012 07:57:54 -0800 (PST) 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: 3.64p2 Message-ID: <20120217155754.14815.93144.idtracker@ietfa.amsl.com> Date: Fri, 17 Feb 2012 07:57:54 -0800 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-icmp-filtering-02.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 15:58:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operational Security Capabilities for= IP Network Infrastructure Working Group of the IETF. Title : Recommendations for filtering ICMP messages Author(s) : Fernando Gont Guillermo Gont Carlos Pignataro Filename : draft-ietf-opsec-icmp-filtering-02.txt Pages : 49 Date : 2012-02-17 This document document provides advice on the filtering of ICMPv4 and ICMPv6 messages. Additionaly, it discusses the operational and interoperability implications of such filtering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsec-icmp-filtering-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-opsec-icmp-filtering-02.txt From Donald.Smith@CenturyLink.com Mon Feb 20 16:14:02 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 4DC0E21F84FC for ; Mon, 20 Feb 2012 16:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.297 X-Spam-Level: X-Spam-Status: No, score=-1.297 tagged_above=-999 required=5 tests=[AWL=-0.852, BAYES_00=-2.599, FRT_BELOW2=2.154] 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 w5i+-pts7cMJ for ; Mon, 20 Feb 2012 16:14:01 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 074E821F84FB for ; Mon, 20 Feb 2012 16:14:00 -0800 (PST) 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 q1L0Du27017176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Feb 2012 17:13:56 -0700 (MST) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 65F321E0065; Mon, 20 Feb 2012 17:13:50 -0700 (MST) Received: from suomp60i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 41F5D1E0068; Mon, 20 Feb 2012 17:13:50 -0700 (MST) Received: from suomp60i.qintra.com (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id q1L0Dn45009715; Mon, 20 Feb 2012 18:13:49 -0600 (CST) Received: from qtdenexhtm20.AD.QINTRA.COM (qtdenexhtm20.ad.qintra.com [151.119.91.229]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id q1L0DnUm009691 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Mon, 20 Feb 2012 18:13:49 -0600 (CST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm20.AD.QINTRA.COM ([151.119.91.229]) with mapi; Mon, 20 Feb 2012 17:13:48 -0700 From: "Smith, Donald" To: Fernando Gont , Carlos Pignataro Content-Class: urn:content-classes:message Date: Mon, 20 Feb 2012 17:13:56 -0700 Thread-Topic: [OPSEC] Fwd: New Version Notification for draft-gont-opsec-ip-options-filtering-01 Thread-Index: AczaDW7hFZelZst1RkyG5asCwDFmbAWGoWb/AAFvpBI= Message-ID: <9501DDFF-BBAD-4812-B08C-C2A98084CB83@mimectl> 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> 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected 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: Tue, 21 Feb 2012 00:14:02 -0000 I have read this in the past but it has changed enough to require that I re= ad it again a few times:) I like the concept and agree with most of what yo= u have. Legend is incomplete, Deny, Permit, Send and N/A are undefined. I realize t= hey are sort of self explanatory but it may help to define them. For exampl= e deny do you mean silent drop or reset or send icmp errors or ...? Deprecated options may still be in use so we may want to think about if we = want to add an "action" to that. Is it apparent that the filtering is for r= outers only or routers and hosts or routers and hosts and firewalls? Firewalls tend to block a lot more then routers. They also incorrect use ic= mp errors to block certain types of packets/protocols etc... For example ip= tables sends port unreachable error msgs for all reject's. That can be modi= fied but that is the default. Also the concept at edge of net, internal net etc... seem to be important b= ut not covered by the table which may be ok just pointing that out. So whil= e we might filter some packets out at the edge of the network we may allow = them internally. For example I wouldn't want a icmp redirect to come from o= utside my network but may allow it internally same for TOS/df bits. I would= n't want someone controlling which queue they get into on my routers but ma= y want to use TOS within my network. I am not sure I agree with all your recommendations in the table but that i= s going to require I read it a few times before making any suggestions. Threats could probably be defined somewhere in full then use a similar abbr= eviation as you have done in the table to refer to them. Something like "redirect =3D Can be used to redirect all or some traffic to= a site to compromise availability, integrity and confidentiality" DOS =3D Resource Exhaustion =3D Can be used to exhaust bandwidth, cpu, io o= r other scarce resources by consuming too much of a resource either by caus= ing the device to generate a lot of msgs or by sending directly towards dev= ice. Operational and interop impact could be done the same way since those are m= ostly the same or come from a small set of impacts. You state in at least one spot that many stacks ignore an type/code pair bu= t some other type/codes commonly ignored don't have that statement. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com ________________________________ From: opsec-bounces@ietf.org [opsec-bounces@ietf.org] On Behalf Of Fernando= Gont [fernando@gont.com.ar] Sent: Monday, January 23, 2012 1:27 PM To: Carlos Pignataro Cc: 'opsec@ietf.org' Subject: Re: [OPSEC] Fwd: New Version Notification for draft-gont-opsec-ip-= options-filtering-01 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 inlin= e... >> >> 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 (a= s >>> 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 fil= ter >>>>> 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 filteri= ng >>>> 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 Optio= ned >>>>> 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 practic= e >>> 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 mi= ght >>>>> 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 gener= al >>>>> 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 _______________________________________________ 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. From Donald.Smith@CenturyLink.com Mon Feb 20 16:21: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 92D4621F8642 for ; Mon, 20 Feb 2012 16:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.013 X-Spam-Level: X-Spam-Status: No, score=-1.013 tagged_above=-999 required=5 tests=[AWL=-0.568, BAYES_00=-2.599, FRT_BELOW2=2.154] 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 DiFMJGa5a9ZA for ; Mon, 20 Feb 2012 16:21:20 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 4345E21F863E for ; Mon, 20 Feb 2012 16:21:20 -0800 (PST) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id q1L0LBUg013725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Feb 2012 18:21:11 -0600 (CST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 0BE111E004D; Mon, 20 Feb 2012 18:21:06 -0600 (CST) Received: from suomp60i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id E20471E0032; Mon, 20 Feb 2012 18:21:05 -0600 (CST) Received: from suomp60i.qintra.com (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id q1L0L5PI015377; Mon, 20 Feb 2012 18:21:05 -0600 (CST) Received: from qtdenexhtm21.AD.QINTRA.COM (qtdenexhtm21.ad.qintra.com [151.119.91.230]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id q1L0L5uP015372 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Mon, 20 Feb 2012 18:21:05 -0600 (CST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm21.AD.QINTRA.COM ([151.119.91.230]) with mapi; Mon, 20 Feb 2012 17:21:04 -0700 From: "Smith, Donald" To: Fernando Gont , Carlos Pignataro Content-Class: urn:content-classes:message Date: Mon, 20 Feb 2012 17:21:12 -0700 Thread-Topic: [OPSEC] Fwd: New Version Notification for draft-gont-opsec-ip-options-filtering-01 Thread-Index: AczaDW7hFZelZst1RkyG5asCwDFmbAWGoWb/AAFvpBIAADSISAAADJle Message-ID: <062CB0F6-E38A-4F70-BC6F-35A6B71DBC3F@mimectl> 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>, <9501DDFF-BBAD-4812-B08C-C2A98084CB83@mimectl> In-Reply-To: <9501DDFF-BBAD-4812-B08C-C2A98084CB83@mimectl> 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected 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: Tue, 21 Feb 2012 00:21:21 -0000 I just noticed you covered that some firewalls use port unreachable under 2= .1.1.3.4 so drop that comment. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com ________________________________ From: opsec-bounces@ietf.org [opsec-bounces@ietf.org] On Behalf Of Smith, D= onald Sent: Monday, February 20, 2012 5:13 PM To: Fernando Gont; Carlos Pignataro Cc: 'opsec@ietf.org' Subject: Re: [OPSEC] Fwd: New Version Notification for draft-gont-opsec-ip-= options-filtering-01 I have read this in the past but it has changed enough to require that I re= ad it again a few times:) I like the concept and agree with most of what yo= u have. Legend is incomplete, Deny, Permit, Send and N/A are undefined. I realize t= hey are sort of self explanatory but it may help to define them. For exampl= e deny do you mean silent drop or reset or send icmp errors or ...? Deprecated options may still be in use so we may want to think about if we = want to add an "action" to that. Is it apparent that the filtering is for r= outers only or routers and hosts or routers and hosts and firewalls? Firewalls tend to block a lot more then routers. They also incorrect use ic= mp errors to block certain types of packets/protocols etc... For example ip= tables sends port unreachable error msgs for all reject's. That can be modi= fied but that is the default. Also the concept at edge of net, internal net etc... seem to be important b= ut not covered by the table which may be ok just pointing that out. So whil= e we might filter some packets out at the edge of the network we may allow = them internally. For example I wouldn't want a icmp redirect to come from o= utside my network but may allow it internally same for TOS/df bits. I would= n't want someone controlling which queue they get into on my routers but ma= y want to use TOS within my network. I am not sure I agree with all your recommendations in the table but that i= s going to require I read it a few times before making any suggestions. Threats could probably be defined somewhere in full then use a similar abbr= eviation as you have done in the table to refer to them. Something like "redirect =3D Can be used to redirect all or some traffic to= a site to compromise availability, integrity and confidentiality" DOS =3D Resource Exhaustion =3D Can be used to exhaust bandwidth, cpu, io o= r other scarce resources by consuming too much of a resource either by caus= ing the device to generate a lot of msgs or by sending directly towards dev= ice. Operational and interop impact could be done the same way since those are m= ostly the same or come from a small set of impacts. You state in at least one spot that many stacks ignore an type/code pair bu= t some other type/codes commonly ignored don't have that statement. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com ________________________________ From: opsec-bounces@ietf.org [opsec-bounces@ietf.org] On Behalf Of Fernando= Gont [fernando@gont.com.ar] Sent: Monday, January 23, 2012 1:27 PM To: Carlos Pignataro Cc: 'opsec@ietf.org' Subject: Re: [OPSEC] Fwd: New Version Notification for draft-gont-opsec-ip-= options-filtering-01 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 inlin= e... >> >> 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 (a= s >>> 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 fil= ter >>>>> 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 filteri= ng >>>> 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 Optio= ned >>>>> 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 practic= e >>> 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 mi= ght >>>>> 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 gener= al >>>>> 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 _______________________________________________ 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. _______________________________________________ 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. From pkampana@cisco.com Mon Feb 20 21:01: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 7EED721E802F for ; Mon, 20 Feb 2012 21:01:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.522 X-Spam-Level: X-Spam-Status: No, score=-7.522 tagged_above=-999 required=5 tests=[AWL=0.923, BAYES_00=-2.599, FRT_BELOW2=2.154, 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 h3KLkFn2e1XB for ; Mon, 20 Feb 2012 21:01:13 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 425E721E8016 for ; Mon, 20 Feb 2012 21:01:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkampana@cisco.com; l=11578; q=dns/txt; s=iport; t=1329800473; x=1331010073; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=XC7FWko6fqCYM+zMi//2xkStb9uDXbCYDWYrMRp53Ko=; b=IUXBzvFOB/XyTjhzYt/K05wTHaZmg7Zi/bIM+YuRQ/oLQS+MWKQ8LZh1 YYUSYCiblaQ17AcyvWu6Ep8Jg2VobpBXzpYG6b1Kbbd/3DgG41o/yF6tf wVZJ1QFJzxqiXq4qNC4PHcDUNQZOUceFiOedXic/Le3vKjNugFzbktNsW E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFANkjQ0+rRDoG/2dsb2JhbABDFqIej2qBB4FzAQEBBAEBAQUKARQBAhAyAggDDAEDAgkPAgEDAQEBJwcZDh8DBggBAQQBEgkCF4dnmWsBnwSJTYIyAwUBAgIBCAQWAQEoBAMRAQGECQgHCoMzBIhPhQeabYE+ X-IronPort-AV: E=Sophos;i="4.73,455,1325462400"; d="scan'208";a="31544969" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 21 Feb 2012 05:01:12 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1L51Cc5004377; Tue, 21 Feb 2012 05:01:12 GMT Received: from xmb-rcd-107.cisco.com ([72.163.62.149]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Feb 2012 23:01:12 -0600 Received: from WIN-ICH1QO6NCS6 ([10.116.63.179]) by xmb-rcd-107.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Feb 2012 23:01:11 -0600 Received: from WINICH1QO6NCS6 by WIN-ICH1QO6NCS6 (PGP Universal service); Tue, 21 Feb 2012 00:00:38 -0500 X-PGP-Universal: processed; by WIN-ICH1QO6NCS6 on Tue, 21 Feb 2012 00:00:38 -0500 From: "Panos Kampanakis" To: "Fernando Gont" , "Carlos Pignataro \(cpignata\)" 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> <4F1DC51F.8020901@cisco.com> In-Reply-To: <4F1DC51F.8020901@cisco.com> Date: Tue, 21 Feb 2012 00:00:35 -0500 Organization: Cisco Systems Inc. Message-ID: <002f01ccf055$bfa352e0$3ee9f8a0$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczaDuXOusKkuAGiQguRPoY4d7/G9wWRsCRw Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us X-OriginalArrivalTime: 21 Feb 2012 05:01:11.0653 (UTC) FILETIME=[D4982950:01CCF055] Cc: opsec@ietf.org Subject: Re: [OPSEC] Fwd: New VersionNotification 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: Tue, 21 Feb 2012 05:01:14 -0000 Hi Fernando, Comments: - In 4.3.4, 4.4.4 and 4.5.4 it is not clear to me what you mean by "Nevertheless, it should be noted that it is virtually impossible to use such techniques due to widespread filtering of the LSRR/SSSR/... option." - In 4.14.5 it states "Because of the design of this option, with variable syntax and variable length, it is not practical to support specialized filtering using the CIPSO information.". If we can block based on type 130 or 131, it is not clear why blocking type 134 is not possible. - "4.18. Other IP Options" says that the unknown options should be ignored. Routing devices and hosts should ignore options that they don't understand. but I believe when we are discussing filtering options, unknown options should be dropped for the sake of security and to prevent exploitations of flaws we are not yet aware of. Suggestions: - In section "2. IP Options" it seems going over the ip iption header would be better exlained with an ascii diagram +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - | Option Type | Opt Data Len | Option Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - In "3.1. Processing Requirements" it seems you are referring to router architectures which could mean any L3 device. But later in the paragraph only routers are mentioned. Maybe it would make more sense to refer to them as network devices, as it could be other L3 devices that are performing the routing function - In "4.12.5 Advice" and 4.13.5 it is stated "Routers and firewalls..." where in other .5 sections the advice was expressed in a different format "Filter...". A minor inconsistency there. Nit: - Paragraph "This is the IPv4-version of the IPv6 amplification attack that was widely publicized in 2007 [Biondi2007]. The only difference is that the maximum length of the IPv4 header (and hence the LSRR option) limits the amplification factor when compared to the IPv6 counter-part." seems to be incorrectly indented. Regards, Panos -----Original Message----- From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of Carlos Pignataro (cpignata) Sent: Monday, January 23, 2012 3:38 PM To: Fernando Gont Cc: 'opsec@ietf.org' Subject: Re: [OPSEC] Fwd: New VersionNotification for draft-gont-opsec-ip-options-filtering-01 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. >> > > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From pkampana@cisco.com Tue Feb 21 13: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 5683821E8061 for ; Tue, 21 Feb 2012 13:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.937 X-Spam-Level: X-Spam-Status: No, score=-8.937 tagged_above=-999 required=5 tests=[AWL=1.663, 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 aK+8NzC5wGlP for ; Tue, 21 Feb 2012 13:36:11 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4079521E804C for ; Tue, 21 Feb 2012 13:36:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkampana@cisco.com; l=4407; q=dns/txt; s=iport; t=1329860171; x=1331069771; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=ZyEeBUiTSDWVbc+WdDWM+XJLXqZmYCvJks/UQzZkL9o=; b=HbG8WL576/C8XxDvmUaqe5btMuMRlY1ClwjUNMchN2yLGQSWyQbh7hzK bFWIsHZ+CdBz7Q4NFyGZbS0oqiPyVK3iJynRWpA6Af+k+fepCXWk+Z59r OgMi5BBrxHzg/GMBWEB1ssAyfSLshmvyh6xQnD1EoY4pYroZuLEU/p+gI A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFACENRE+tJXG9/2dsb2JhbABDok+Pd4EHgXMBAQEEAQEBBQoBFQIQNAsMAQMCCQ8CBAEBKAcZDh8JCAEBBBMJAheHZ6AMAZcziV8BghICAgIKBQEGAgEDBgcCAQIBASgEAxABAQGECQgHCoMzBIhPhQeabYE1AQQ X-IronPort-AV: E=Sophos;i="4.73,459,1325462400"; d="scan'208";a="60750853" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 21 Feb 2012 21:36:10 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1LLaAHl018350; Tue, 21 Feb 2012 21:36:10 GMT Received: from xmb-rcd-107.cisco.com ([72.163.62.149]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Feb 2012 15:36:10 -0600 Received: from WIN-ICH1QO6NCS6 ([64.102.220.197]) by xmb-rcd-107.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Feb 2012 15:36:10 -0600 Received: from WINICH1QO6NCS6 by WIN-ICH1QO6NCS6 (PGP Universal service); Tue, 21 Feb 2012 16:35:37 -0500 X-PGP-Universal: processed; by WIN-ICH1QO6NCS6 on Tue, 21 Feb 2012 16:35:37 -0500 From: "Panos Kampanakis" To: References: <20120217155754.14815.93144.idtracker@ietfa.amsl.com> In-Reply-To: <20120217155754.14815.93144.idtracker@ietfa.amsl.com> Date: Tue, 21 Feb 2012 16:35:35 -0500 Organization: Cisco Systems Inc. Message-ID: <00c901ccf0e0$bf376180$3da62480$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcztjRNR6zk797+fS7G2VelLTXcjuADUu5Fw Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us X-OriginalArrivalTime: 21 Feb 2012 21:36:10.0394 (UTC) FILETIME=[D3D11FA0:01CCF0E0] Cc: "Carlos Pignataro \(cpignata\)" Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-icmp-filtering-02.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 21:36:12 -0000 Hello, Since this was revived (seems significantly changed with plenty of edits to follow), here are my initial comments. - In "2. Internet Control Message Protocol version 4 (ICMP)" maybe it would be worth to clarify the table. That it refers to the actions devices need to take when generating, forwarding or receive such traffic. Also "Depr" keyword is not clear what it means. For traffic generated it means you are not supposed to generate it. But when you are receiving, does it mean you should not allow the packet? Also I am not sure about the "ICMPv4-unreach", "ICMPv4-redirect" and "ICMPv4-parameter" that are shown as N/A. The various codes for each are covered in the sebsequenct options per ICMP type. So, they represent a superset of the various options. So, I am not sure they need to be in the table. Or maybe then can be in there just to group their options together. - There is a difference between Router and Firewall traffic processing. It seems the document mostly speaks about recommendations on how to process ICMP with routers. Maybe you want to clarify if the document addresses just routers of network devices in general. And if the scope includes firewalls, the recommendations especially for ICMP generation will need to be clarified. - In "2.1.1.4.3. Threats" it seems rate limiting doesn't address the "connection-reset attacks". Maybe you want to make it clear or propose other mitigations. You might also want to explicitly say that it should not be rate-limited or blocked. - In 2.1.1.5.4. maybe you want to mention the impact of breaking PMTU, especially in VPN setups. - In 2.1.1.7.3 and 2.1.1.9.3 don't you want to deny the deprecated message and not rate-limit? - In 2.1.1.10.3 and 2.1.1.11.3 "May reveal filtering policies" is not mitigated. You may want to mention the deny for transient traffic. - In 2.1.1.12.3 and 2.1.1.13.2 "May reveal routing policies" is not mitigated. You may want to mention the deny for transient traffic. - In most Threats section rate limiting is mentioned. But blocking transient traffic is not mentioned to mitigate threats even though it is in the tables as deny. - 2.1.3.1.3, 2.1.3.2.3 and 2.1.3.3.3 don't discuss mitigations, rate limiting or blocking - Recommendations like inspection statefully or blocking broadcast destinations (smurf) are not addressed in 2.2.1.1.3 and 3.2.1.2.3 (ICMPv6) - 2.2.4.1 are deprecated messages. Should routers generate them or drop? Depr in the table doesn't show if I receive an information echo request wheat I should do as a router, for example. - Rare ICMPv4 message types 30 and 31 (rfc1475) could be mentioned - IPv6 threats sections don't mention mitigations as in ICMP for IPv4 - Many ICMPv6 messages are missing from the v6 section including ICMPv6 RS, RA, NS, ND. A list is here http://www.iana.org/assignments/icmpv6-parameters Rgs, Panos -----Original Message----- From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Friday, February 17, 2012 10:58 AM To: i-d-announce@ietf.org Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-icmp-filtering-02.txt 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 for filtering ICMP messages Author(s) : Fernando Gont Guillermo Gont Carlos Pignataro Filename : draft-ietf-opsec-icmp-filtering-02.txt Pages : 49 Date : 2012-02-17 This document document provides advice on the filtering of ICMPv4 and ICMPv6 messages. Additionaly, it discusses the operational and interoperability implications of such filtering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsec-icmp-filtering-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-opsec-icmp-filtering-02.txt _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec