From opsec-bounces@ietf.org Tue Apr 1 14:33:42 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 919FE3A6D78; Tue, 1 Apr 2008 14:33:42 -0700 (PDT) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40B103A6B80 for ; Tue, 1 Apr 2008 14:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImwJ3YB87jZB for ; Tue, 1 Apr 2008 14:33:36 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 6508E28C695 for ; Tue, 1 Apr 2008 14:32:56 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id DE1675A899E; Tue, 1 Apr 2008 18:32:57 -0300 (ART) Received: from notebook.gont.com.ar (host253.190-139-181.telecom.net.ar [190.139.181.253]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id m31LWeiB028762; Tue, 1 Apr 2008 18:32:45 -0300 Message-Id: <200804012132.m31LWeiB028762@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 01 Apr 2008 18:30:34 -0300 To: Ron Bonica From: Fernando Gont In-Reply-To: <47F24DA0.1090209@juniper.net> References: <200803302248.m2UMmhSn014472@venus.xmundo.net> <47F24DA0.1090209@juniper.net> Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Tue, 01 Apr 2008 18:32:56 -0300 (ART) Cc: opsec wg mailing list Subject: Re: [OPSEC] New I-D on ICMP filtering X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Ron, >This is an excellent document and I encourage you to post it. Thanks! >The following are a few comments: > >Section 1: Is your advice directed to ISPs? Enterprise Operators? SOHO >users? I'd say the current document is pretty general, and would apply to ISPs and Enterprise Operators. I was planning to include a section on stateful ICMP filtering, which would only apply to SOHO. >Missing Section: You might want to add a Section up front that includes >two tables. One table represents ICMPv4 and the other ICMPv6. Each table >entry represents a type/code combination. Each table entry also includes >a pointer to the section of the document that addresses the message >type, and a recommendation to pass or filter the message. Makes a lot of sense. Will do. >General: For many message types, the "Threats" and "Impact if blocked" >are identical. So, it is tempting to merge these sections. However, this >is not possible because the "Message Specification" and "Uses" are not >identical. Maybe you can solve the problem by omitting the "Message >Specification" and "Uses" sections and trusting the reader to read the >reference documents. Okay, but... in which section would we include the pointers to reference documents if we omit both the "Message specification" and "Uses" sections? > /individual contributor > Ron > >P.S. I have not met Guillermo Gont. Are the authors brothers? Father and >son? Brothers. Having him co-author the doc has been my intent to get him read RFCs and get his hands dirty. :-) I'm don't think this ICMP-torture is getting him excited, but.... ;-) (Based on past experience, I'm starting to think that at some point I *might* have a kid and end up including him as a co-author of some draft I have active at the IETF... and you know what I am talking about :-) :-( ) Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org 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 From opsec-bounces@ietf.org Wed Apr 2 05:38:53 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 687DB28C340; Wed, 2 Apr 2008 05:38:53 -0700 (PDT) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC8FC28C340 for ; Wed, 2 Apr 2008 05:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzMPZAL0Nm5W for ; Wed, 2 Apr 2008 05:38:52 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id CA39A28C231 for ; Wed, 2 Apr 2008 05:38:46 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Wed, 02 Apr 2008 05:37:27 PDT Received: from proton.jnpr.net ([10.10.2.37]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Apr 2008 05:38:13 -0700 Received: from [172.23.1.71] ([172.23.1.71] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Apr 2008 08:38:11 -0400 Message-ID: <47F37E2D.9010106@juniper.net> Date: Wed, 02 Apr 2008 08:38:05 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fernando Gont References: <200803302248.m2UMmhSn014472@venus.xmundo.net> <47F0CB3B.5090506@mitre.org> <200803311513.m2VFD6i4027619@venus.xmundo.net> In-Reply-To: <200803311513.m2VFD6i4027619@venus.xmundo.net> X-Enigmail-Version: 0.93.0.0 X-OriginalArrivalTime: 02 Apr 2008 12:38:11.0742 (UTC) FILETIME=[69A8B3E0:01C894BE] Cc: opsec wg mailing list Subject: Re: [OPSEC] New I-D on ICMP filtering X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Fernando Gont wrote: > At 08:30 a.m. 31/03/2008, George M Jones wrote: > > > > Our take on providing "detailed pointers" to the specs is that you > know where to look at if you want to make a more informed decision on > whether to block the message or not, Additionally, you know where to > look at if you want to understand the consequences of filtering the > error messages better. I guess one could provide some sort of > table.... but for many messages that would include "RFC1122" and > "RFC792", which wouldn't shed much light? > In the table, you could make the pointer as specific as it needs to be (example: RFC 792, Section 2.1, Paragraph 1). Ron _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Wed Apr 30 15:07:09 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFF683A6DD9; Wed, 30 Apr 2008 15:07:09 -0700 (PDT) X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB0563A68B0 for ; Wed, 30 Apr 2008 15:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+nb7-dsojoL for ; Wed, 30 Apr 2008 15:07:04 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id 43B4A28C3FE for ; Wed, 30 Apr 2008 15:06:56 -0700 (PDT) Received: from suomp60i.qintra.com (suomp60i.qintra.com [151.117.69.27]) by suomp64i.qwest.com (8.14.0/8.14.0) with ESMTP id m3UM6rlM024225; Wed, 30 Apr 2008 17:06:53 -0500 (CDT) Received: from ITDENE2KSM02.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.0/8.14.0) with ESMTP id m3UM6g9D005350; Wed, 30 Apr 2008 17:06:47 -0500 (CDT) Received: from ITDENE2KM02.AD.QINTRA.COM ([10.1.4.66]) by ITDENE2KSM02.AD.QINTRA.COM with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Apr 2008 16:06:42 -0600 X-MessageTextProcessor: DisclaimIt (2.70.270) [Qwest Communications International Inc.] X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Apr 2008 16:05:48 -0600 Message-ID: In-Reply-To: <200804012132.m31LWeiB028762@venus.xmundo.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSEC] New I-D on ICMP filtering thread-index: AciUQCfAEV9/Odq9SQWGTsGcKIk8UwWvvsOg References: <200803302248.m2UMmhSn014472@venus.xmundo.net><47F24DA0.1090209@juniper.net> <200804012132.m31LWeiB028762@venus.xmundo.net> Importance: normal Priority: normal From: "Smith, Donald" To: "Fernando Gont" , "Ron Bonica" X-OriginalArrivalTime: 30 Apr 2008 22:06:42.0827 (UTC) FILETIME=[790435B0:01C8AB0E] Cc: opsec wg mailing list Subject: Re: [OPSEC] New I-D on ICMP filtering X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org RM=for(1) {manage_risk(identify_risk(product[i++]) && (identify_threat[product[i++]))} Donald.Smith@qwest.com giac > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] > On Behalf Of Fernando Gont > Sent: Tuesday, April 01, 2008 3:31 PM > To: Ron Bonica > Cc: opsec wg mailing list > Subject: Re: [OPSEC] New I-D on ICMP filtering > > Ron, > > >This is an excellent document and I encourage you to post it. I also think this document is a very good document and wanted to provide some comments and questions wrt it. > > Thanks! > > > >The following are a few comments: > > > >Section 1: Is your advice directed to ISPs? Enterprise > Operators? SOHO > >users? Operational impact if blocked is a bit vauge. I think there are 6 kinds of "blocking" recommendations we could be making. Blocked towards your device (network element or host). Blocked through your device. Blocked from your device. Ratelimited towards your device. Ratelimited through your device. Ratelimited from your device. > > I'd say the current document is pretty general, and would apply to > ISPs and Enterprise Operators. I was planning to include a section on > stateful ICMP filtering, which would only apply to SOHO. > > > > >Missing Section: You might want to add a Section up front > that includes > >two tables. One table represents ICMPv4 and the other > ICMPv6. Each table > >entry represents a type/code combination. Each table entry > also includes > >a pointer to the section of the document that addresses the message > >type, and a recommendation to pass or filter the message. > > Makes a lot of sense. Will do. Somewhere around 2.1.3.1 (redirect datagrams for the network ) many of the types/codes areas are not filled in. I would be willing to assist there if your interested. These comments are based on the 4/16/2008 version. 2.1.1.1.1 "router can not forward a packet because it has no routes" Does not include the concept of BGP triggered blackhole. In that case the router does have a route but the route leads to /dev/null. A lookup in the cef or forwarding table usually results in 0 being returned so it is a route but it is a null route:) 2.1.1.3.3 Threats Negative scanning. This is how protocol scanning is preformed in nmap. 2.1.1.4.3 Threats Negative scanning. This is how UDP port scanning is preformed in nmap. Spoofed blind resets. 2.1.1.5.3 Threats Negative scanning. This is how UDP port scanning is preformed in nmap. Spoofed blind resets. 2.1.1.6.1 Many ISPs block or ignore source route. As do many enterprises. Most of those that are blocking or ignoring are also not sending source route failed icmp error msgs. If they do the threat becomes one of network mapping and/or network capability mapping. 2.1.1.7 destination netwokr unknown (code 6) (Deprecated). Since this is deprecated do we need to make any suggestions? Is it still acted upon? 2.1.1.8.3 Threats Negative scan. Reflective attack. Network mapping. 2.1.1.10.3 Threats "May reveal filtering policies" seems to be the same as network mapping or prehaps it should be network policy mapping. I would like to see the same text used if possible through the document. 2.1.1.11.3 Threats Negative scan, relective attack, network policy mapping. 2.1.1.12.3 Threats network policy mapping, negative scan, relective attack. 2.1.1.13.3 Threats Network policy mapping, reflective attacks. 2.1.1.14.3 Threats Negative scan, reflective attacks. 2.1.1.14.3 Threats Negative scan, reflective attacks, possibly blind resets? 2.1.1.15.3 Threats Network policy mapping from the inside of the network? I am not sure that is very valid. You could map the policy of an ISPs edge. 2.1.1.16.3 Threats Negative scan, network policy mapping, reflective attack. 2.1.2.2 Uses Tarpitting, slowing aggressive hosts. 2.1.3.1.3 Threats Spoofed redirect could cause multi networked hosts to send traffic in the wrong direction. Consider a WAP with one port going to the broadband uplink and the other going out wireless. If the home system received a spoofed redirect you may be able to get the Internet bound traffic to go out the wap to a local hijacker. 2.1.3.1.4 Impact: This is often blocked at enterprise edges. Routers usually ignore it. 2.1.3.2.4 Impact: This is often blocked at enterprise edges. Routers usually ignore it. 2.1.3.4.3 Threat: Route hijacking, man in the middle attacks. 2.1.3.4.4 This is often blocked at enterprise edges. Routers usually ignore it. 2.1.4.1.3 Threats: Network mapping, reflective attacks, Negative scannings. 2.1.4.1.4 Impact: I agree it breaks traceroute. I don't think it leads to long delays.... 2.1.4.2.3 Threats: Reflective, network mapping. 2.1.5 should have the same uses, threats, and impact as destination unreachable (1,5). 2.2.1.1.3 Threats: An example of icmp-scanning would be natchi. Smurf is a specific example of reflective attacks. Network mapping. 2.2.1.2.3 Threats: Smurf is a specific example of reflective attacks. 2.2.2.2.3 Threats: Route hijack. 2.2.3.1.3 Threats: Can be used to establish time potentially to by pass time based authentication methods. Can be used to establish time potentially to geo map a system. 2.2.4.1.3 Threats: Network mapping, reflective attacks. 2.2.5.1.3 Threats: Reflective attacks. This is as far as I have gotten so far:) > > > >General: For many message types, the "Threats" and "Impact > if blocked" > >are identical. So, it is tempting to merge these sections. > However, this > >is not possible because the "Message Specification" and > "Uses" are not > >identical. Maybe you can solve the problem by omitting the "Message > >Specification" and "Uses" sections and trusting the reader > to read the > >reference documents. I don't think threats and impact will be the same in most cases. Threats should be what a malicious party could do with them such as: Negative scan, network mapping, spoofed reflective attack (w or w/o amp), directed DOS attack. I don't think you should combine them. > > Okay, but... in which section would we include the pointers to > reference documents if we omit both the "Message specification" and > "Uses" sections? > > > > > /individual contributor > > Ron > > > >P.S. I have not met Guillermo Gont. Are the authors > brothers? Father and > >son? > > Brothers. Having him co-author the doc has been my intent to get him > read RFCs and get his hands dirty. :-) I'm don't think this > ICMP-torture is getting him excited, but.... ;-) > > (Based on past experience, I'm starting to think that at some point I > *might* have a kid and end up including him as a co-author of some > draft I have active at the IETF... and you know what I am talking > about :-) :-( ) > > Kindest regards, > > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > 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 Qwest and may contain confidential or privileged information. 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 all copies of the communication and any attachments. _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec