From opsec-bounces@ietf.org Mon Jun 2 06:43:45 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08E4028C11D; Mon, 2 Jun 2008 06:43:45 -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 9DB543A67D2 for ; Mon, 2 Jun 2008 06:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_LOW=-1] 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 pAX36DQ1HQJN for ; Mon, 2 Jun 2008 06:43:43 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 0845B28C134 for ; Mon, 2 Jun 2008 06:43:42 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 800C46B6581 for ; Mon, 2 Jun 2008 10:43:41 -0300 (ART) Received: from notebook.gont.com.ar (acc-01-30.radio.wavenet.com.br [200.157.23.48]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.13.8) with ESMTP id m52DfV1d002457 for ; Mon, 2 Jun 2008 10:43:31 -0300 Message-Id: <200806021343.m52DfV1d002457@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 01 Jun 2008 22:10:52 -0300 To: opsec wg mailing list From: Fernando Gont 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]); Mon, 02 Jun 2008 10:43:40 -0300 (ART) Subject: [OPSEC] Proposed changes for the ICMP filtering I-D 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 Hello, folks, (sorry if you get this one twice... not sure if it worked on my first try) We are working on a revision of the ICMP filtering draft (http://www.gont.com.ar/drafts/icmp-filtering/draft-gont-opsec-icmp-filtering-00.txt). We'd like to get some input on a few issues relevant to the document structure: 1) Reducing the amount of text about message specifications One of the comments we got on the was that the document provides too many details wrt to the specification of messages. We're planning to reduce the amount of text by simply providing pointers to the specs, without any discussion of the referenced text. For example, the current text in Section 2.1.1.1.1: " Defined in [RFC0792]. Section 4.3.3.1 of [RFC1812] states that if a router cannot forward a packet because it has no routes at all (including no default route) to the destination specified in the packet, then the router MUST generate a Destination Unreachable, Code 0 (Network Unreachable) ICMP message. Section 3.2.2.1 of [RFC1122] states that this message may result from a routing transient, and MUST therefore be interpreted as only a hint, not proof, that the specified destination is unreachable. For example, it MUST NOT be used as proof of a dead gateway. Section 4.2.3.9 of [RFC1122] states that this message indicates a soft error, and therefore TCP MUST NOT abort the connection, and SHOULD make the information available to the application." would become something like: " Specified in [RFC0792], Section 4.3.3.1 of [RFC1812], Section 3.2.2.1 of [RFC1122], and Section 4.2.3.9 of [RFC1122]" We could even completely remove section numbers... although I'd prefer not to (documents like RFC1122 and RFC1812 are simply too large for a loose reference to them being useful). 2) Providing advice on ICMP filtering at end-systems We had originally thought about the draft discussing ICMP filtering in forwarding devices, and not in end-systems. However, some feedback from Donald Smith somehow raised the question (in my head, if you want :-) ) on whether the doc should provide advice on ICMP filtering when ICMP messages are destined to or originated at the router itself. That is, we might provide advice on what to do with ICMP messages at a finer granularity: ICMP messages originating at the device, messages that go through the device, and messages destined to the the device. We'd like to know what's the opinion of the wg about this. 3) "Operational/Interoperability implications if blocked" The current text discusses what you may break if you filter each of the ICMP type/codes. Donald pointed out that this might be a little bit vague. I personally think that this section could be kept "as is". My rationale is that if blocking a message breaks something (e.g., blocking "frag needed" breaks PMTUD), then the implications of rate-limiting, and filtering message to/from/through a router are straightforward. However, input from the wg on this issue would be welcome, so that we agree on the basic structure of the document before committing too many cycles in a wrong direction. 4) Informational vs. BCP The current version of the doc is meant for the Informational track. While talking with Carlos Pignataro, we realized that "BCP" might be a more appropriate track for this draft. We'd like input on this one, too. :-) Thanks! Kind 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 Mon Jun 2 06:43:54 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37BDE28C17B; Mon, 2 Jun 2008 06:43:54 -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 EA40728C16B for ; Mon, 2 Jun 2008 06:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_LOW=-1] 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 ZZtNEb9uxsIT for ; Mon, 2 Jun 2008 06:43:48 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 0783B28C14D for ; Mon, 2 Jun 2008 06:43:46 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 674166B6581; Mon, 2 Jun 2008 10:43:48 -0300 (ART) Received: from notebook.gont.com.ar (acc-01-30.radio.wavenet.com.br [200.157.23.48]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.13.8) with ESMTP id m52DfV1f002457; Mon, 2 Jun 2008 10:43:37 -0300 Message-Id: <200806021343.m52DfV1f002457@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 01 Jun 2008 22:12:24 -0300 To: Joel Jaeggli From: Fernando Gont 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]); Mon, 02 Jun 2008 10:43:48 -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 At 03:34 a.m. 07/05/2008, Joel Jaeggli wrote: >I think, given the commentary over the last month that this is worth >accepting as a working group document. I think it's pretty clear >that there were some comments regarding the structure but relatively >little regarding the content, which is consistent with what we >discussed prior to IETF 71. [catching-up with e-mail... sorry for the delay in my response] Should we resubmit the draft as draft-ietf? Thanks! Kind 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 Mon Jun 2 08:02:54 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D5853A6C91; Mon, 2 Jun 2008 08:02:54 -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 84AAA3A69A9 for ; Mon, 2 Jun 2008 08:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKtnVBdcLMpB for ; Mon, 2 Jun 2008 08:02:45 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id A60B63A6CEE for ; Mon, 2 Jun 2008 08:00:29 -0700 (PDT) Received: from suomp61i.qintra.com (suomp61i.qintra.com [151.117.69.28]) by suomp64i.qwest.com (8.14.0/8.14.0) with ESMTP id m52F0GW2014583; Mon, 2 Jun 2008 10:00:18 -0500 (CDT) Received: from ITDENE2KSM02.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.0/8.14.0) with ESMTP id m52F0A1T023480; Mon, 2 Jun 2008 10:00:11 -0500 (CDT) Received: from ITDENE2KM02.AD.QINTRA.COM ([10.1.4.66]) by ITDENE2KSM02.AD.QINTRA.COM with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jun 2008 09:00:10 -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: Mon, 2 Jun 2008 09:00:09 -0600 Message-ID: In-Reply-To: <200806021343.m52DfV1d002457@venus.xmundo.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSEC] Proposed changes for the ICMP filtering I-D thread-index: AcjEtrwZhkQaa/MnQ1Cr8dtEK2xeZAACI5yg Importance: normal Priority: normal References: <200806021343.m52DfV1d002457@venus.xmundo.net> From: "Smith, Donald" To: "Fernando Gont" , "opsec wg mailing list" X-OriginalArrivalTime: 02 Jun 2008 15:00:10.0598 (UTC) FILETIME=[5A7DB860:01C8C4C1] Subject: Re: [OPSEC] Proposed changes for the ICMP filtering I-D 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 Security through obscurity WORKS against some worms and ssh attacks:) Donald.Smith@qwest.com giac > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] > On Behalf Of Fernando Gont > Sent: Sunday, June 01, 2008 7:11 PM > To: opsec wg mailing list > Subject: [OPSEC] Proposed changes for the ICMP filtering I-D > > Hello, folks, > > (sorry if you get this one twice... not sure if it worked on > my first try) > > We are working on a revision of the ICMP filtering draft > (http://www.gont.com.ar/drafts/icmp-filtering/draft-gont-opsec > -icmp-filtering-00.txt). > We'd like to get some input on a few issues relevant to the > document structure: > > 1) Reducing the amount of text about message specifications > One of the comments we got on the was that the document provides too > many details wrt to the specification of messages. > We're planning to reduce the amount of text by simply providing > pointers to the specs, without any discussion of the referenced text. > For example, the current text in Section 2.1.1.1.1: > " Defined in [RFC0792]. Section 4.3.3.1 of [RFC1812] > states that if a > router cannot forward a packet because it has no routes at all > (including no default route) to the destination specified in the > packet, then the router MUST generate a Destination > Unreachable, Code > 0 (Network Unreachable) ICMP message. Section 3.2.2.1 of > [RFC1122] > states that this message may result from a routing transient, and > MUST therefore be interpreted as only a hint, not proof, that the > specified destination is unreachable. For example, it MUST NOT be > used as proof of a dead gateway. Section 4.2.3.9 of > [RFC1122] states > that this message indicates a soft error, and therefore > TCP MUST NOT > abort the connection, and SHOULD make the information available to > the application." > > would become something like: > " Specified in [RFC0792], Section 4.3.3.1 of [RFC1812], > Section 3.2.2.1 > of [RFC1122], and Section 4.2.3.9 of [RFC1122]" I like the details. It would help others understand and decide on the filtering recommendations in the rfc. Without those details we end up with recommendations without providing the basis for those recommendations. > > We could even completely remove section numbers... although I'd > prefer not to (documents like RFC1122 and RFC1812 are simply too > large for a loose reference to them being useful). > > > 2) Providing advice on ICMP filtering at end-systems > We had originally thought about the draft discussing ICMP filtering > in forwarding devices, and not in end-systems. However, some feedback > from Donald Smith somehow raised the question (in my head, if you > want :-) ) on whether the doc should provide advice on ICMP filtering > when ICMP messages are destined to or originated at the router > itself. That is, we might provide advice on what to do with ICMP > messages at a finer granularity: ICMP messages originating at the > device, messages that go through the device, and messages destined to > the device. I think we should cover the following destinations. To (directed at the device itself) Through (directed through the device) >From (coming from the device) and possibly Behind (behind a device meant to protect a network such as a firewall or router ACL). If we do cover BEHIND that gets into firewalls/router acls but I think that may also have value. > > We'd like to know what's the opinion of the wg about this. > > > 3) "Operational/Interoperability implications if blocked" > The current text discusses what you may break if you filter each of > the ICMP type/codes. Donald pointed out that this might be a little > bit vague. I personally think that this section could be kept "as > is". My rationale is that if blocking a message breaks something > (e.g., blocking "frag needed" breaks PMTUD), then the implications of > rate-limiting, and filtering message to/from/through a router are > straightforward. I don't think it was vague as much as hard to list all things that will break. I am not sure we will be able to develop a complete list of applications and services that break when you filter or rate limit some icmp type. I still think it is worth the effort to list what we know but we may need to add text somewhere saying that those applications are the ones we know will be affected but that the list is not all inclusive. > > However, input from the wg on this issue would be welcome, so that we > agree on the basic structure of the document before committing too > many cycles in a wrong direction. > > > 4) Informational vs. BCP > The current version of the doc is meant for the Informational track. > While talking with Carlos Pignataro, we realized that "BCP" might be > a more appropriate track for this draft. I vote for BCP too:) > > We'd like input on this one, too. :-) > > Thanks! > > Kind 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 From opsec-bounces@ietf.org Mon Jun 2 08:37:15 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DD9C28C17B; Mon, 2 Jun 2008 08:37:15 -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 20FFA3A6909 for ; Mon, 2 Jun 2008 08:37:15 -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 z-ldmBZt8X+Y for ; Mon, 2 Jun 2008 08:37:14 -0700 (PDT) Received: from clifden.donelan.com (clifden.donelan.com [208.72.84.6]) by core3.amsl.com (Postfix) with ESMTP id 1A5D728C1B2 for ; Mon, 2 Jun 2008 08:35:24 -0700 (PDT) Received: from sean (helo=localhost) by clifden.donelan.com with local-esmtp (Exim 4.69) (envelope-from ) id 1K3C4B-0007Fp-Mq; Mon, 02 Jun 2008 11:35:23 -0400 Date: Mon, 2 Jun 2008 11:35:23 -0400 (EDT) From: Sean Donelan To: Fernando Gont In-Reply-To: <200806021343.m52DfV1d002457@venus.xmundo.net> Message-ID: References: <200806021343.m52DfV1d002457@venus.xmundo.net> MIME-Version: 1.0 Cc: opsec wg mailing list Subject: Re: [OPSEC] Proposed changes for the ICMP filtering I-D 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 On Sun, 1 Jun 2008, Fernando Gont wrote: > 2) Providing advice on ICMP filtering at end-systems > We had originally thought about the draft discussing ICMP filtering > in forwarding devices, and not in end-systems. However, some feedback > from Donald Smith somehow raised the question (in my head, if you > want :-) ) on whether the doc should provide advice on ICMP filtering > when ICMP messages are destined to or originated at the router > itself. That is, we might provide advice on what to do with ICMP > messages at a finer granularity: ICMP messages originating at the > device, messages that go through the device, and messages destined to > the the device. > > We'd like to know what's the opinion of the wg about this. I tend to view it as understanding the intended scope of various mesages rather than filtering. The intended scope of some mesages is within a LAN, a single administrative domain, between administrative domains, the Internet. The same messages may be very useful when used within their scope, and very disruptive when used outside of their scope. Of course, when should messages cross between different scopes backs into the filtering question. _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Mon Jun 2 13:49:33 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B3023A6B17; Mon, 2 Jun 2008 13:49:33 -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 688133A6B01 for ; Mon, 2 Jun 2008 13:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 ndc7p-54dycw for ; Mon, 2 Jun 2008 13:49:30 -0700 (PDT) Received: from mail.enyo.de (mail.enyo.de [212.9.189.167]) by core3.amsl.com (Postfix) with ESMTP id 0400B3A6B83 for ; Mon, 2 Jun 2008 13:47:10 -0700 (PDT) Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1K3Gsn-0000M7-4T; Mon, 02 Jun 2008 22:43:57 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1K3Gsm-0000PA-IV; Mon, 02 Jun 2008 22:43:56 +0200 From: Florian Weimer To: Fernando Gont References: <200806021343.m52DfV1d002457@venus.xmundo.net> Date: Mon, 02 Jun 2008 22:43:56 +0200 In-Reply-To: <200806021343.m52DfV1d002457@venus.xmundo.net> (Fernando Gont's message of "Sun, 01 Jun 2008 22:10:52 -0300") Message-ID: <87tzgbin3n.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Cc: opsec wg mailing list Subject: Re: [OPSEC] Proposed changes for the ICMP filtering I-D 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: > 2) Providing advice on ICMP filtering at end-systems > We had originally thought about the draft discussing ICMP filtering > in forwarding devices, and not in end-systems. However, some feedback > from Donald Smith somehow raised the question (in my head, if you > want :-) ) on whether the doc should provide advice on ICMP filtering > when ICMP messages are destined to or originated at the router > itself. That is, we might provide advice on what to do with ICMP > messages at a finer granularity: ICMP messages originating at the > device, messages that go through the device, and messages destined to > the the device. > > We'd like to know what's the opinion of the wg about this. For some devices (primarily hosts, but perhaps also middleboxes), there might be an interaction between ICMP port unreachable messages and source port randomization: the absence of an ICMP message could indicate that a particular source port is being used (even to an attacker who is not party to the conversation). I'm not sure if this merits mention in the draft, though. _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Fri Jun 6 07:48:45 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A5FD28C152; Fri, 6 Jun 2008 07:48:45 -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 8F79E28C152 for ; Fri, 6 Jun 2008 07:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 ZzeRIYIw1L1n for ; Fri, 6 Jun 2008 07:48:43 -0700 (PDT) Received: from aharp.ittns.northwestern.edu (aharp.ittns.northwestern.edu [129.105.153.69]) by core3.amsl.com (Postfix) with ESMTP id B730E28C143 for ; Fri, 6 Jun 2008 07:48:40 -0700 (PDT) Received: from t41-0 (aharp [127.0.0.1]) by aharp.ittns.northwestern.edu (smtpd) with ESMTP id F288A136C82 for ; Fri, 6 Jun 2008 09:48:49 -0500 (CDT) Date: Fri, 6 Jun 2008 09:48:48 -0500 From: John Kristoff To: opsec@ietf.org Message-ID: <20080606094848.71e36596@t41-0> In-Reply-To: <200806021343.m52DfV1d002457@venus.xmundo.net> References: <200806021343.m52DfV1d002457@venus.xmundo.net> X-Mailer: Claws Mail Mime-Version: 1.0 Subject: Re: [OPSEC] Proposed changes for the ICMP filtering I-D 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 On Sun, 01 Jun 2008 22:10:52 -0300 Fernando Gont wrote: > However, input from the wg on this issue would be welcome, so that we > agree on the basic structure of the document before committing too > many cycles in a wrong direction. I've avoided participating in this work since my original comments on this subject in January. I think the scope of your draft turned me off quite frankly. :-) Don't get me wrong, a fine grained examination of ICMP filtering issues and guidelines may be useful, but it looks to me what you're writing is closer to a very detailed update of RFC 792. Not that that would be a bad thing. I'm not sure its possible to make this a BCP. These days filtering is often a local decision, and in some cases rightfully so. John _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Fri Jun 6 07:59:31 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14D793A68C7; Fri, 6 Jun 2008 07:59:31 -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 59CD43A68F4 for ; Fri, 6 Jun 2008 07:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTow-wbehBUO for ; Fri, 6 Jun 2008 07:59:28 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 4707B3A68C7 for ; Fri, 6 Jun 2008 07:59:28 -0700 (PDT) Received: from [172.168.1.130] (adsl-75-36-130-74.dsl.pltn13.sbcglobal.net [75.36.130.74]) (authenticated bits=0) by nagasaki.bogus.com (8.14.2/8.14.2) with ESMTP id m56ExYdU071990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 6 Jun 2008 14:59:35 GMT (envelope-from joelja@bogus.com) Message-ID: <484950D5.3010208@bogus.com> Date: Fri, 06 Jun 2008 07:59:33 -0700 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: John Kristoff References: <200806021343.m52DfV1d002457@venus.xmundo.net> <20080606094848.71e36596@t41-0> In-Reply-To: <20080606094848.71e36596@t41-0> X-Enigmail-Version: 0.95.6 X-Virus-Scanned: ClamAV 0.92.1/7386/Fri Jun 6 12:35:23 2008 on nagasaki.bogus.com X-Virus-Status: Clean Cc: opsec@ietf.org Subject: Re: [OPSEC] Proposed changes for the ICMP filtering I-D 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 John Kristoff wrote: > On Sun, 01 Jun 2008 22:10:52 -0300 > Fernando Gont wrote: > >> However, input from the wg on this issue would be welcome, so that we >> agree on the basic structure of the document before committing too >> many cycles in a wrong direction. > > I've avoided participating in this work since my original comments on > this subject in January. I think the scope of your draft turned me > off quite frankly. :-) > > Don't get me wrong, a fine grained examination of ICMP filtering issues > and guidelines may be useful, but it looks to me what you're writing > is closer to a very detailed update of RFC 792. Not that that would > be a bad thing. > > I'm not sure its possible to make this a BCP. These days filtering is > often a local decision, and in some cases rightfully so. I think it should be clear what functionality you lose when you chose to filter something. desireable vs best is a fine line to walk I guess. > John > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Fri Jun 6 08:31:33 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1E243A6A8B; Fri, 6 Jun 2008 08:31:33 -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 A72543A695B for ; Fri, 6 Jun 2008 08:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijlaDurWDVDh for ; Fri, 6 Jun 2008 08:31:30 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id 48C4B3A6A8B for ; Fri, 6 Jun 2008 08:29:41 -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 m56FToFo019487; Fri, 6 Jun 2008 10:29:50 -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 m56FThe5024128; Fri, 6 Jun 2008 10:29:45 -0500 (CDT) Received: from ITDENE2KM02.AD.QINTRA.COM ([10.1.4.66]) by ITDENE2KSM02.AD.QINTRA.COM with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jun 2008 09:29:45 -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: Fri, 6 Jun 2008 09:29:43 -0600 Message-ID: In-Reply-To: <20080606094848.71e36596@t41-0> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSEC] Proposed changes for the ICMP filtering I-D thread-index: AcjH5HSOLq7N1I7NQ8qCwqQOz2af3AABQSrA Importance: normal Priority: normal References: <200806021343.m52DfV1d002457@venus.xmundo.net> <20080606094848.71e36596@t41-0> From: "Smith, Donald" To: "John Kristoff" , X-OriginalArrivalTime: 06 Jun 2008 15:29:45.0608 (UTC) FILETIME=[2621C080:01C8C7EA] Subject: Re: [OPSEC] Proposed changes for the ICMP filtering I-D 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 Security through obscurity WORKS against some worms and ssh attacks:) Donald.Smith@qwest.com giac > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] > On Behalf Of John Kristoff > Sent: Friday, June 06, 2008 8:49 AM > To: opsec@ietf.org > Subject: Re: [OPSEC] Proposed changes for the ICMP filtering I-D > > On Sun, 01 Jun 2008 22:10:52 -0300 > Fernando Gont wrote: > > > However, input from the wg on this issue would be welcome, > so that we > > agree on the basic structure of the document before committing too > > many cycles in a wrong direction. > > I've avoided participating in this work since my original comments on > this subject in January. I think the scope of your draft turned me > off quite frankly. :-) I don't think the scope is finalized yet. We were discussing it. Do we want to limit the scope to filtering/ratelimiting THROUGH a system. Or should we include to and from a system? > > Don't get me wrong, a fine grained examination of ICMP > filtering issues > and guidelines may be useful, but it looks to me what you're writing > is closer to a very detailed update of RFC 792. Not that that would > be a bad thing. > > I'm not sure its possible to make this a BCP. These days filtering is > often a local decision, and in some cases rightfully so. I agree filtering is a local decision. That is why along with the recommendations I believe it is important to explain what that type/code combination is used for, why filtering should be considered, and what the filtering is likely to impact. > > John > _______________________________________________ > 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 From opsec-bounces@ietf.org Sat Jun 7 00:15:00 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5A763A69F5; Sat, 7 Jun 2008 00:15:00 -0700 (PDT) X-Original-To: opsec@ietf.org Delivered-To: opsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 398C73A6D7B; Fri, 6 Jun 2008 13:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080606203002.398C73A6D7B@core3.amsl.com> Date: Fri, 6 Jun 2008 13:30:02 -0700 (PDT) X-Mailman-Approved-At: Sat, 07 Jun 2008 00:14:59 -0700 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action:draft-ietf-opsec-efforts-08.txt 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: , Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org --NextPart 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 : Security Best Practices Efforts and Documents Author(s) : C. Lonvick, D. Spak Filename : draft-ietf-opsec-efforts-08.txt Pages : 36 Date : 2008-06-06 This document provides a snapshot of the current efforts to define or apply security requirements in various Standards Developing Organizations (SDO). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsec-efforts-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-opsec-efforts-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-06131711.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec --NextPart-- From opsec-bounces@ietf.org Tue Jun 17 11:24:39 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5381C3A6835; Tue, 17 Jun 2008 11:24:39 -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 36E483A6828 for ; Tue, 17 Jun 2008 11:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 5fFQH8zhbfAA for ; Tue, 17 Jun 2008 11:24:17 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 2FB8E3A6781 for ; Tue, 17 Jun 2008 11:24:17 -0700 (PDT) Received: from [192.103.16.227] ([192.103.16.227]) (authenticated bits=0) by nagasaki.bogus.com (8.14.2/8.14.2) with ESMTP id m5HIP0iF072073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 17 Jun 2008 18:25:00 GMT (envelope-from joelja@bogus.com) Message-ID: <4858016C.7080306@bogus.com> Date: Tue, 17 Jun 2008 11:24:44 -0700 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: opsec wg mailing list X-Enigmail-Version: 0.95.6 Content-Type: multipart/mixed; boundary="------------000002020108080808090405" X-Virus-Scanned: ClamAV 0.92.1/7494/Tue Jun 17 04:46:03 2008 on nagasaki.bogus.com X-Virus-Status: Clean Subject: [OPSEC] FYI: OPSEC - Requested session has been scheduled for IETF 72 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: , Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org This is a multi-part message in MIME format. --------------000002020108080808090405 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit we have a slot scheduled... please send agenda items if you have them. thanks --------------000002020108080808090405 Content-Type: message/rfc822; name="OPSEC - Requested session has been scheduled for IETF 72.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="OPSEC - Requested session has been scheduled for IETF 72.eml" Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on nagasaki.bogus.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=4.0 tests=AWL,NO_RELAYS autolearn=disabled version=3.2.4 Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by nagasaki.bogus.com (8.14.2/8.14.2) with ESMTP id m5CLeSnA053842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 12 Jun 2008 21:40:28 GMT (envelope-from wwwrun@core3.amsl.com) Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6uWr-000FXt-Si for joelja@bogus.com; Thu, 12 Jun 2008 21:40:23 +0000 Received: by core3.amsl.com (Postfix, from userid 30) id D2A513A6AF6; Thu, 12 Jun 2008 14:39:50 -0700 (PDT) From: IETF Secretariat To: joelja@bogus.com Cc: jabley@ca.afilias.info, dromasca@avaya.com, rbonica@juniper.net, session-request@ietf.org Subject: OPSEC - Requested session has been scheduled for IETF 72 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20080612213950.D2A513A6AF6@core3.amsl.com> Date: Thu, 12 Jun 2008 14:39:50 -0700 (PDT) X-Virus-Scanned: ClamAV 0.92.1/7455/Thu Jun 12 19:58:45 2008 on nagasaki.bogus.com X-Virus-Status: Clean Dear Joel Jaeggli, The sessions that you have requested have been scheduled. Below is the scheduled session information followed by the information of sessions that you have requested. OPSEC Session 1 (1 hour) Wednesday, Afternoon Session II 1510-1610 Room Name: Conservatory ---------------------------------------------- Requested Information: --------------------------------------------------------- Working Group Name: opsec Area Name: Operations and Management Area Session Requester: Joel Jaeggli Number of Sessions: 1 Length of Session(s): 1 hour Number of Attendees: 20 Conflicts to Avoid: First Priority: v6ops Second Priority: opsarea Third Priority: saag Special Requests: --------------------------------------------------------- --------------000002020108080808090405 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec --------------000002020108080808090405--