From jabley@hopcount.ca Wed May 11 06:22:53 2011 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 546DCE06D1 for ; Wed, 11 May 2011 06:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdlRtHqq4dCC for ; Wed, 11 May 2011 06:22:53 -0700 (PDT) Received: from monster.hopcount.ca (monster.hopcount.ca [IPv6:2001:4900:1:392:213:20ff:fe1b:3bfe]) by ietfa.amsl.com (Postfix) with ESMTP id 23C04E067E for ; Wed, 11 May 2011 06:22:17 -0700 (PDT) Received: from [2001:4900:1042:100:5a55:caff:feec:96bf] (helo=krill.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QK9Ml-000KLg-1L; Wed, 11 May 2011 13:22:15 +0000 From: Joe Abley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 11 May 2011 09:22:11 -0400 Message-Id: To: "opsec@ietf.org mailing list" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 2001:4900:1042:100:5a55:caff:feec:96bf X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Cc: opsec chairs , rja.lists@gmail.com Subject: [OPSEC] on adoption of draft-gont-opsec-ip-options-filtering X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 13:22:53 -0000 Hi all, Fernando Gont has asked Warren and I whether this working group is = amenable to adopting draft-gont-opsec-ip-options-filtering as a wg = document. http://tools.ietf.org/html/draft-gont-opsec-ip-options-filtering-01 Please send comments to this list in the next week (before 18 May 2011). = Please include some kind of indication of whether you are in favour of = adoption, and indicate whether you might be interested in working on the = document as a contributor or reviewer. Thanks, Joe & Warren= From jabley@hopcount.ca Wed May 11 06:24:56 2011 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 14D59E0682 for ; Wed, 11 May 2011 06:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5D1q-iN-DVR for ; Wed, 11 May 2011 06:24:55 -0700 (PDT) Received: from monster.hopcount.ca (monster.hopcount.ca [IPv6:2001:4900:1:392:213:20ff:fe1b:3bfe]) by ietfa.amsl.com (Postfix) with ESMTP id AF383E067E for ; Wed, 11 May 2011 06:24:55 -0700 (PDT) Received: from [2001:4900:1042:100:5a55:caff:feec:96bf] (helo=krill.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QK9PK-000KNl-AK; Wed, 11 May 2011 13:24:54 +0000 From: Joe Abley Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 11 May 2011 09:24:53 -0400 Message-Id: <447FF10B-8442-4B94-A8B5-A194488D2C77@hopcount.ca> To: "opsec@ietf.org mailing list" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 2001:4900:1042:100:5a55:caff:feec:96bf X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Cc: opsec chairs Subject: [OPSEC] =?iso-8859-1?q?opsec_meeting_at_IETF_81=2C_Qu=E9bec?= X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 13:24:56 -0000 Hi all, The cut-off for requesting a meeting slot in Qu=E9bec is 6 June 2011. = Warren and I have not yet scheduled a meeting. Please let us know by e-mail to this list whether you expect to have = documents (or other issues relevant to the charter) to discuss in Qu=E9bec= so we can judge whether an in-person meeting would be useful. Thanks, Joe & Warren From cpignata@cisco.com Thu May 12 19:38:01 2011 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 AA46AE0696 for ; Thu, 12 May 2011 19:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.136 X-Spam-Level: X-Spam-Status: No, score=-107.136 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iN7NTH5NPf-T for ; Thu, 12 May 2011 19:37:57 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2497EE0593 for ; Thu, 12 May 2011 19:37:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=cpignata@cisco.com; l=1399; q=dns/txt; s=iport; t=1305254277; x=1306463877; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=zduAycHYfzwErRQE3V6FB8L8wOqNN/mR3L8OmckVxdg=; b=D0bgNXeUpOHNKCyDhZp1kHAO3B5BYoE/h6bLWma1vLEvN+UtCjlRiVQH ckvZfCL0W3uU/vAtyDCYaUYPb9K6fpuqUM2nq76IDG+IqgqEWdsTE6+WU AIErbSESKOtVk9CHWKlvDN9+4EXHdK/6B1NxfobsOL7c0JD19/ruvyFkX U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgGAO6YzE2tJV2a/2dsb2JhbAClFGECd4hwoHKeF4YVBI98hDGKVA X-IronPort-AV: E=Sophos;i="4.64,362,1301875200"; d="scan'208";a="446943095" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-1.cisco.com with ESMTP; 13 May 2011 02:37:56 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4D2bur5003188; Fri, 13 May 2011 02:37:56 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 May 2011 21:37:55 -0500 Received: from 72.163.62.205 ([72.163.62.205]) by XMB-RCD-206.cisco.com ([72.163.62.213]) with Microsoft Exchange Server HTTP-DAV ; Fri, 13 May 2011 02:37:55 +0000 References: Content-Transfer-Encoding: quoted-printable From: "Carlos Pignataro (cpignata)" Content-Type: text/plain; charset="us-ascii" Thread-Topic: [OPSEC] on adoption of draft-gont-opsec-ip-options-filtering Thread-Index: AcwRFsNGlGeUxjM2RQCPFOa2xXpcgg== In-Reply-To: Message-ID: <20363BAC-9701-46CB-8ADD-97F8E0E96226@cisco.com> Date: Thu, 12 May 2011 22:38:37 -0400 To: "Joe Abley" MIME-Version: 1.0 (iPad Mail 8J2) X-OriginalArrivalTime: 13 May 2011 02:37:55.0900 (UTC) FILETIME=[C3CF57C0:01CC1116] Cc: opsec@ietf.org, opsec chairs , rja.lists@gmail.com Subject: Re: [OPSEC] on adoption of draft-gont-opsec-ip-options-filtering X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 02:38:01 -0000 Hi Joe, I think that the problem space of IP Optioned packet treatment is most defin= itely worth investing WG time, and I support that. However, I am not quite s= ure that this I-D is vectored in the right direction to be an initial basis f= or that work, or it contains some foundational gaps. At least, I have a set o= f questions and observations. I was meaning to send a review in response to Fernando's earlier message on l= ist, I will try to do that sooner and definitely before the 18th. I am interested in working on the/a document about ip-options-filtering as a= contributor. Carlos P. On May 11, 2011, at 9:23 AM, "Joe Abley" wrote: > Hi all, >=20 > Fernando Gont has asked Warren and I whether this working group is amenabl= e to adopting draft-gont-opsec-ip-options-filtering as a wg document. >=20 > http://tools.ietf.org/html/draft-gont-opsec-ip-options-filtering-01 >=20 > Please send comments to this list in the next week (before 18 May 2011). P= lease include some kind of indication of whether you are in favour of adopti= on, and indicate whether you might be interested in working on the document a= s a contributor or reviewer. >=20 > Thanks, >=20 >=20 > Joe & Warren > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec >=20 From cpignata@cisco.com Thu May 12 20:10:59 2011 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 6C837E06E7 for ; Thu, 12 May 2011 20:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CV8vf4eGbjn for ; Thu, 12 May 2011 20:10:55 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id D996EE0696 for ; Thu, 12 May 2011 20:10:54 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p4D3AoCC020588; Thu, 12 May 2011 23:10:50 -0400 (EDT) Received: from [10.117.115.50] (rtp-cpignata-8911.cisco.com [10.117.115.50]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p4D3AnYv015671; Thu, 12 May 2011 23:10:49 -0400 (EDT) Message-ID: <4DCCA138.2000908@cisco.com> Date: Thu, 12 May 2011 23:10:48 -0400 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Fernando Gont References: <4DB74CBD.2050003@gont.com.ar> In-Reply-To: <4DB74CBD.2050003@gont.com.ar> X-Enigmail-Version: 1.1.1 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] Fwd: New Version Notification for draft-gont-opsec-ip-options-filtering-01 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 03:10:59 -0000 Hi Fernando, I wanted to share some high-level comments on this I-D. I hope this is useful feedback. The great majority of this document as currently structured dives into details about fifteen IPv4 Options, assessing threat model -> impact if blocked -> advise. I think that the threat -> impact -> advise is a good model. However, this flow seems to make some strong underlying assumptions: 1. It may assume that the current state is that options are not blocked. But currently, IP optioned packets do not have unfiltered success in the Internet: http://www.ietf.org/mail-archive/web/int-area/current/msg02334.html http://www.ietf.org/mail-archive/web/int-area/current/msg02360.html 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. 3. It assumes that a desired granularity is to filter at the option level, generally. This might result in increased and unjustified OpEx, and an operator might chose to simply make a blanked determination, even when the capability to filter per-option might exist. 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. 5. Doing an enumeration of all options would either need to be exhaustive (and it appears that the document does not contain all option values from , e.g., 147), or provide a catch-all final else clause in the conditional. This is also solved by providing a non-per-option-value discussion. Based on this, I believe that a document about ip-options-filtering should start at a much higher level discussing coarse granularity (less opex) options, as well as reasons for a perceived current state. There are operational considerations to doing per-option-value filtering versus generic option filtering or ignoring, and I believe those should be discussed early on on the document. Some more specific comments: I suspect that the phrase "IP Options filtering" that is used throughout the doc can be a bit ambiguous. The options are not filtered, the whole optioned datagram is. The intended status listed is BCP, and I wonder if that is what this document is providing. More than a current practice (which arguably is to filter or ignore without looking at the option value, modulo exceptions), it appears to provide Information about impact of filtering particular options. 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. 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. The document does not describe what the resulting disposition of a packet with many options should be. Nits: There seems to be an inconsistency with the timestamp option: The timestamp option has a number of security implications. Among them are: ... No security issues are known for this option, other than the general security implications of IP options discussed in Section 2. The short title is "IPv4 Security Assessment". There I hope these comments are clear, please do let me know anything that does not parse, I hope this is useful. Thanks, -- Carlos. On 4/26/2011 6:52 PM, Fernando Gont wrote: > Folks, > > We have published a revision of our I-D "IP Options Filtering > Recommendations". It is available at: > http://tools.ietf.org/html/draft-gont-opsec-ip-options-filtering-01 > > Publication of this document had been suggested at the Hiroshima IETF. > Version -00 had expired a while ago, and I decided to invest some time > and bring this document back to life. This time with much help from Ran > Atkinson, who is co-authoring this latest rev. > > Any comments will be welcome. > > Thanks! > > Best regards, > Fernando > > > > > -------- Original Message -------- > Subject: New Version Notification for > draft-gont-opsec-ip-options-filtering-01 > Date: Tue, 26 Apr 2011 15:31:13 -0700 (PDT) > From: IETF I-D Submission Tool > To: fernando@gont.com.ar > CC: rja.lists@gmail.com > > > A new version of I-D, draft-gont-opsec-ip-options-filtering-01.txt has > been successfully submitted by Fernando Gont and posted to the IETF > repository. > > Filename: draft-gont-opsec-ip-options-filtering > Revision: 01 > Title: IP Options Filtering Recommendations > Creation_date: 2011-04-27 > WG ID: Independent Submission > Number_of_pages: 26 > > Abstract: > This document document provides advice on the filtering of packets > based on the IP options they contain. Additionally, it discusses the > operational and interoperability implications of such filtering. > > > > > The IETF Secretariat. > > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > From cpignata@cisco.com Fri May 13 09:43:36 2011 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 7C599E07F2 for ; Fri, 13 May 2011 09:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRRAcY-LZb41 for ; Fri, 13 May 2011 09:43:35 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFEAE07EF for ; Fri, 13 May 2011 09:43:34 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p4DGhUIk003244; Fri, 13 May 2011 12:43:30 -0400 (EDT) Received: from [10.117.115.50] (rtp-cpignata-8911.cisco.com [10.117.115.50]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p4DGhUCF008414; Fri, 13 May 2011 12:43:30 -0400 (EDT) Message-ID: <4DCD5FB1.7050204@cisco.com> Date: Fri, 13 May 2011 12:43:29 -0400 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: "Smith, Donald" References: <4DB74CBD.2050003@gont.com.ar> <4DCCA138.2000908@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] Fwd: New Version Notification for draft-gont-opsec-ip-options-filtering-01 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 16:43:36 -0000 Donald, Thanks for the response, some additional follow-ups inline. On 5/13/2011 12:04 PM, Smith, Donald wrote: > General comment this document needs a through spell checking:) > Additional comments in line below. > > > "When packets collide the controllers cease transmission AND wait a random time before retransmission (mostly)!" > Donald.Smith@qwest.com > > >> -----Original Message----- >> From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf >> Of Carlos Pignataro >> Sent: Thursday, May 12, 2011 9:11 PM >> To: Fernando Gont >> Cc: 'opsec@ietf.org' >> Subject: Re: [OPSEC] Fwd: New Version Notification for draft-gont- >> opsec-ip-options-filtering-01 >> >> Hi Fernando, >> >> I wanted to share some high-level comments on this I-D. I hope this is >> useful feedback. >> >> The great majority of this document as currently structured dives into >> details about fifteen IPv4 Options, assessing threat model -> impact if >> blocked -> advise. I think that the threat -> impact -> advise is a >> good >> model. >> >> However, this flow seems to make some strong underlying assumptions: >> 1. It may assume that the current state is that options are not >> blocked. > I didn't read it that way. > I read it to assume that ip options MIGHT not be filtered and therefore MAY arrive unfiltered. > OK, I can see that too. One thing that perhaps would help, as a suggestion, is to specify the scope and instantiation of filtering. Is it through an ISP, to a Large Enterprise datacenter, at the edge, or at some infrastructure? > >> But currently, IP optioned packets do not have unfiltered success in >> the >> Internet: >> http://www.ietf.org/mail-archive/web/int-area/current/msg02334.html >> http://www.ietf.org/mail-archive/web/int-area/current/msg02360.html > This appears to be about NEW IP options not known existing ones. > > Here are the options used in the test. > --ip-options \xc0\x06\xde\xad\xbe\xef\x00\x00 > > Hex C0 = 11000000 binary or 192 in decimal. > I couldn't find an ip options type of 192. > Yes, this test is for new options (which the doc should cover as well as to what to do with "the rest" / unknown. The paper cited at the earlier email, S4.3 of , covers both existing and new options. > > >> >> 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 am familiar with the top carrier class router vendors and their ip options filtering ability. > It certainly isn't complete but most support filtering many of the options identified in this document as potentially needing to be filtered. > I know of routers that do via ACLs and routers that don't. And the ones that do, they support all options either by specifying a name for a well-known one or entering the type number. Some "typical enterprise" might not deploy carrier class routers, at least everywhere. If most support it but some do not, I think the doc could speak to what to do if not. Frankly, I think this is more important in the next point, as operators might choose to not deal with particular options by type but instead with all at once, and differently though versus to the device. > >> >> 3. It assumes that a desired granularity is to filter at the option >> level, generally. This might result in increased and unjustified OpEx, >> and an operator might chose to simply make a blanked determination, >> even >> when the capability to filter per-option might exist. > True enough, however I believe most ISPs are already blocking or ignoring many of the ip options that potentially need to be filtered. > I agree, but in my experience, the way in which they are blocked is often times all at once regardless of type, and differently through the device (ignore options) versus to the device (drop). >> >> 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. > Strongly agree, ignoring an option from a SP perspective is much better then filtering them. > Rate limiting them towards the control plane/RE is probably also a valuable recommendation but is at least partially covered in other rfc's. > I agree with both these statements. > If I can leave your packet unmolested and deny others an attack avenue against the router's RE that is always my first choice. > Any packet I have to modify costs me some amount of processing and impacts our clients ability to generate traffic of their choice. > That matches my experience as well. There is an opex variable as well, so as to ignore all options through and drop all options to is a two-liner. > Should we call out what an ISP should do vs. an enterprise? I think so. > Additionally recommending what a core router, edge router, PE, peering router and cpe should do? I think so to. And the other variable to be explicit about is to vs. through. > > Additionally most of the recommendations say filter but I did see drop in at least one recommendation. > What's the difference in meaning between the two? >> >> 5. Doing an enumeration of all options would either need to be >> exhaustive (and it appears that the document does not contain all >> option >> values from , e.g., >> 147), >> or provide a catch-all final else clause in the conditional. This is >> also solved by providing a non-per-option-value discussion. > Both could be useful. > Agree. >> >> Based on this, I believe that a document about ip-options-filtering >> should start at a much higher level discussing coarse granularity (less >> opex) options, as well as reasons for a perceived current state. There >> are operational considerations to doing per-option-value filtering >> versus generic option filtering or ignoring, and I believe those should >> be discussed early on on the document. > I agree this could provide additional value but am a bit concerned as others have suggested the document is too large:( > I could agree that the document is too large. That was part of my comment in regards to structure. However having: 1. A description of all-or-nothing filtering and ignoring at the beginning, followed by 2. a table summarizing the per-option citations and dispositions Can provide a concise kernel of information, followed by details for completeness. Just a suggestion. >> >> Some more specific comments: >> >> I suspect that the phrase "IP Options filtering" that is used >> throughout >> the doc can be a bit ambiguous. The options are not filtered, the whole >> optioned datagram is. >> >> The intended status listed is BCP, and I wonder if that is what this >> document is providing. More than a current practice (which arguably is >> to filter or ignore without looking at the option value, modulo >> exceptions), it appears to provide Information about impact of >> filtering >> particular options. >> >> 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. > > Again from an SP perspective this is current and correct most large router vendors today use the ASIC forwarder and RE/CPU architecture. > Many have added additional layers so it may be asic for most forwarding, then a shared NP for some other work, then a Routing Engine. > Right, but LCs have processors that perform CP functions often times, and like you say there are layers of forwarding. I agree though with the point that (I understand) is being made here, since there is no hop-by-hop versus end-to-end concept for IPv4 options, there is a different (and more CPU-expensive) processing path for IPv4 Optioned packets than optionless ones. I would just suggest, as an editorial, to make that point explicitly and in a timeless way without delving into routing architectures. Thanks, -- Carlos. > > >> >> 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. >> >> The document does not describe what the resulting disposition of a >> packet with many options should be. >> >> Nits: >> >> There seems to be an inconsistency with the timestamp option: >> >> The timestamp option has a number of security implications. Among >> them are: >> ... >> No security issues are known for this option, other than the general >> security implications of IP options discussed in Section 2. >> >> The short title is "IPv4 Security Assessment". >> >> There >> >> I hope these comments are clear, please do let me know anything that >> does not parse, I hope this is useful. >> >> Thanks, >> >> -- Carlos. >> >> >> On 4/26/2011 6:52 PM, Fernando Gont wrote: >>> Folks, >>> >>> We have published a revision of our I-D "IP Options Filtering >>> Recommendations". It is available at: >>> http://tools.ietf.org/html/draft-gont-opsec-ip-options-filtering-01 >>> >>> Publication of this document had been suggested at the Hiroshima >> IETF. >>> Version -00 had expired a while ago, and I decided to invest some >> time >>> and bring this document back to life. This time with much help from >> Ran >>> Atkinson, who is co-authoring this latest rev. >>> >>> Any comments will be welcome. >>> >>> Thanks! >>> >>> Best regards, >>> Fernando >>> >>> >>> >>> >>> -------- Original Message -------- >>> Subject: New Version Notification for >>> draft-gont-opsec-ip-options-filtering-01 >>> Date: Tue, 26 Apr 2011 15:31:13 -0700 (PDT) >>> From: IETF I-D Submission Tool >>> To: fernando@gont.com.ar >>> CC: rja.lists@gmail.com >>> >>> >>> A new version of I-D, draft-gont-opsec-ip-options-filtering-01.txt >> has >>> been successfully submitted by Fernando Gont and posted to the IETF >>> repository. >>> >>> Filename: draft-gont-opsec-ip-options-filtering >>> Revision: 01 >>> Title: IP Options Filtering Recommendations >>> Creation_date: 2011-04-27 >>> WG ID: Independent Submission >>> Number_of_pages: 26 >>> >>> Abstract: >>> This document document provides advice on the filtering of packets >>> based on the IP options they contain. Additionally, it discusses the >>> operational and interoperability implications of such filtering. >>> >>> >>> >>> >>> The IETF Secretariat. >>> >>> >>> >>> _______________________________________________ >>> 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 > > 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. > From fw@deneb.enyo.de Sat May 14 06:34:50 2011 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 B394CE06E3 for ; Sat, 14 May 2011 06:34:50 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGs6Pu6ZJumy for ; Sat, 14 May 2011 06:34:50 -0700 (PDT) Received: from ka.mail.enyo.de (ka.mail.enyo.de [87.106.162.201]) by ietfa.amsl.com (Postfix) with ESMTP id 1A45CE06DF for ; Sat, 14 May 2011 06:34:49 -0700 (PDT) Received: from [172.17.135.4] (helo=deneb.enyo.de) by ka.mail.enyo.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1QLEzR-0004x3-3v; Sat, 14 May 2011 15:34:41 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.72) (envelope-from ) id 1QLEzQ-0003M1-SL; Sat, 14 May 2011 15:34:40 +0200 From: Florian Weimer To: "Carlos Pignataro \(cpignata\)" References: <20363BAC-9701-46CB-8ADD-97F8E0E96226@cisco.com> Date: Sat, 14 May 2011 15:34:40 +0200 In-Reply-To: <20363BAC-9701-46CB-8ADD-97F8E0E96226@cisco.com> (Carlos Pignataro's message of "Thu, 12 May 2011 22:38:37 -0400") Message-ID: <87boz52yof.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: opsec@ietf.org, rja.lists@gmail.com Subject: Re: [OPSEC] on adoption of draft-gont-opsec-ip-options-filtering X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2011 13:34:50 -0000 * Carlos Pignataro: > I think that the problem space of IP Optioned packet treatment is > most definitely worth investing WG time, and I support that. I agree. I suspect that considering what is deployed today, Internet endpoints must assume that packets carrying IP Options are either forwarded as if the options were not present, or dropped. This is independent of the option type. Options may work on some networks, but operators will undoubtly switch off option processing by any feasible means if the need arises. I suspect that this could happen in the core, too, and applications relying on IP options would then be screwed. (Just as multicast applications were screwed when one large operator switched off multicast support when it threatened to impact unicast service a couple of years ago.) From Donald.Smith@qwest.com Fri May 13 09:05:09 2011 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 C07CFE06DB for ; Fri, 13 May 2011 09:05:09 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsni913-K2XX for ; Fri, 13 May 2011 09:05:08 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 71431E069B for ; Fri, 13 May 2011 09:05:08 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id p4DG4wC1017026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 May 2011 11:04:58 -0500 (CDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 7C76D1E005E; Fri, 13 May 2011 10:04:53 -0600 (MDT) Received: from suomp60i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 515F31E0058; Fri, 13 May 2011 10:04:53 -0600 (MDT) Received: from qtdenexhtm22.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id p4DG4pdL014206; Fri, 13 May 2011 11:04:52 -0500 (CDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Fri, 13 May 2011 10:04:52 -0600 From: "Smith, Donald" To: "'Carlos Pignataro'" , "'Fernando Gont'" Date: Fri, 13 May 2011 10:04:50 -0600 Thread-Topic: [OPSEC] Fwd: New Version Notification for draft-gont-opsec-ip-options-filtering-01 Thread-Index: AcwRG2puf+TV5Y1NSWSPiF96wdCpkAAYaErQ Message-ID: References: <4DB74CBD.2050003@gont.com.ar> <4DCCA138.2000908@cisco.com> In-Reply-To: <4DCCA138.2000908@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Mon, 16 May 2011 12:19:26 -0700 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: Fri, 13 May 2011 17:16:30 -0000 General comment this document needs a through spell checking:) Additional comments in line below. "When packets collide the controllers cease transmission AND wait a random = time before retransmission (mostly)!" Donald.Smith@qwest.com > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf > Of Carlos Pignataro > Sent: Thursday, May 12, 2011 9:11 PM > To: Fernando Gont > Cc: 'opsec@ietf.org' > Subject: Re: [OPSEC] Fwd: New Version Notification for draft-gont- > opsec-ip-options-filtering-01 > > Hi Fernando, > > I wanted to share some high-level comments on this I-D. I hope this is > useful feedback. > > The great majority of this document as currently structured dives into > details about fifteen IPv4 Options, assessing threat model -> impact if > blocked -> advise. I think that the threat -> impact -> advise is a > good > model. > > However, this flow seems to make some strong underlying assumptions: > 1. It may assume that the current state is that options are not > blocked. I didn't read it that way. I read it to assume that ip options MIGHT not be filtered and therefore MAY= arrive unfiltered. > But currently, IP optioned packets do not have unfiltered success in > the > Internet: > http://www.ietf.org/mail-archive/web/int-area/current/msg02334.html > http://www.ietf.org/mail-archive/web/int-area/current/msg02360.html This appears to be about NEW IP options not known existing ones. Here are the options used in the test. --ip-options \xc0\x06\xde\xad\xbe\xef\x00\x00 Hex C0 =3D 11000000 binary or 192 in decimal. I couldn't find an ip options type of 192. > > 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 am familiar with the top carrier class router vendors and their ip option= s filtering ability. It certainly isn't complete but most support filtering many of the options = identified in this document as potentially needing to be filtered. > > 3. It assumes that a desired granularity is to filter at the option > level, generally. This might result in increased and unjustified OpEx, > and an operator might chose to simply make a blanked determination, > even > when the capability to filter per-option might exist. True enough, however I believe most ISPs are already blocking or ignoring m= any of the ip options that potentially need to be filtered. > > 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. Strongly agree, ignoring an option from a SP perspective is much better the= n filtering them. Rate limiting them towards the control plane/RE is probably also a valuable= recommendation but is at least partially covered in other rfc's. If I can leave your packet unmolested and deny others an attack avenue agai= nst the router's RE that is always my first choice. Any packet I have to modify costs me some amount of processing and impacts = our clients ability to generate traffic of their choice. Should we call out what an ISP should do vs. an enterprise? Additionally recommending what a core router, edge router, PE, peering rout= er and cpe should do? Additionally most of the recommendations say filter but I did see drop in a= t least one recommendation. > > 5. Doing an enumeration of all options would either need to be > exhaustive (and it appears that the document does not contain all > option > values from , e.g., > 147), > or provide a catch-all final else clause in the conditional. This is > also solved by providing a non-per-option-value discussion. Both could be useful. > > Based on this, I believe that a document about ip-options-filtering > should start at a much higher level discussing coarse granularity (less > opex) options, as well as reasons for a perceived current state. There > are operational considerations to doing per-option-value filtering > versus generic option filtering or ignoring, and I believe those should > be discussed early on on the document. I agree this could provide additional value but am a bit concerned as other= s have suggested the document is too large:( > > Some more specific comments: > > I suspect that the phrase "IP Options filtering" that is used > throughout > the doc can be a bit ambiguous. The options are not filtered, the whole > optioned datagram is. > > The intended status listed is BCP, and I wonder if that is what this > document is providing. More than a current practice (which arguably is > to filter or ignore without looking at the option value, modulo > exceptions), it appears to provide Information about impact of > filtering > particular options. > > 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. Again from an SP perspective this is current and correct most large router = vendors today use the ASIC forwarder and RE/CPU architecture. Many have added additional layers so it may be asic for most forwarding, th= en a shared NP for some other work, then a Routing Engine. > > 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. > > The document does not describe what the resulting disposition of a > packet with many options should be. > > Nits: > > There seems to be an inconsistency with the timestamp option: > > The timestamp option has a number of security implications. Among > them are: > ... > No security issues are known for this option, other than the general > security implications of IP options discussed in Section 2. > > The short title is "IPv4 Security Assessment". > > There > > I hope these comments are clear, please do let me know anything that > does not parse, I hope this is useful. > > Thanks, > > -- Carlos. > > > On 4/26/2011 6:52 PM, Fernando Gont wrote: > > Folks, > > > > We have published a revision of our I-D "IP Options Filtering > > Recommendations". It is available at: > > http://tools.ietf.org/html/draft-gont-opsec-ip-options-filtering-01 > > > > Publication of this document had been suggested at the Hiroshima > IETF. > > Version -00 had expired a while ago, and I decided to invest some > time > > and bring this document back to life. This time with much help from > Ran > > Atkinson, who is co-authoring this latest rev. > > > > Any comments will be welcome. > > > > Thanks! > > > > Best regards, > > Fernando > > > > > > > > > > -------- Original Message -------- > > Subject: New Version Notification for > > draft-gont-opsec-ip-options-filtering-01 > > Date: Tue, 26 Apr 2011 15:31:13 -0700 (PDT) > > From: IETF I-D Submission Tool > > To: fernando@gont.com.ar > > CC: rja.lists@gmail.com > > > > > > A new version of I-D, draft-gont-opsec-ip-options-filtering-01.txt > has > > been successfully submitted by Fernando Gont and posted to the IETF > > repository. > > > > Filename: draft-gont-opsec-ip-options-filtering > > Revision: 01 > > Title: IP Options Filtering Recommendations > > Creation_date: 2011-04-27 > > WG ID: Independent Submission > > Number_of_pages: 26 > > > > Abstract: > > This document document provides advice on the filtering of packets > > based on the IP options they contain. Additionally, it discusses the > > operational and interoperability implications of such filtering. > > > > > > > > > > The IETF Secretariat. > > > > > > > > _______________________________________________ > > 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 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. From Donald.Smith@qwest.com Fri May 13 12:09:39 2011 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 18F45E0878 for ; Fri, 13 May 2011 12:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyKKsVnZFRqq for ; Fri, 13 May 2011 12:09:37 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 75D63E086F for ; Fri, 13 May 2011 12:09:37 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id p4DJ9Rw5002626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 May 2011 13:09:27 -0600 (MDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 043631E005B; Fri, 13 May 2011 13:09:22 -0600 (MDT) Received: from suomp61i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id CFBCA1E0035; Fri, 13 May 2011 13:09:21 -0600 (MDT) Received: from qtdenexhtm22.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id p4DJ9KUo010838; Fri, 13 May 2011 14:09:20 -0500 (CDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Fri, 13 May 2011 13:09:20 -0600 From: "Smith, Donald" To: "'Carlos Pignataro'" Date: Fri, 13 May 2011 13:09:18 -0600 Thread-Topic: [OPSEC] Fwd: New Version Notification for draft-gont-opsec-ip-options-filtering-01 Thread-Index: AcwRjO55jfvCfI3OQRSMfetiE2DREwAEtlaA Message-ID: References: <4DB74CBD.2050003@gont.com.ar> <4DCCA138.2000908@cisco.com> <4DCD5FB1.7050204@cisco.com> In-Reply-To: <4DCD5FB1.7050204@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Mon, 16 May 2011 12:19:26 -0700 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: Fri, 13 May 2011 19:09:39 -0000 Your welcome! Mostly we are agreeing but a comment or two below. h8Hz Donald.Smith@qwest.com > -----Original Message----- > From: Carlos Pignataro [mailto:cpignata@cisco.com] > Sent: Friday, May 13, 2011 10:43 AM > To: Smith, Donald > Cc: 'Fernando Gont'; 'opsec@ietf.org' > Subject: Re: [OPSEC] Fwd: New Version Notification for draft-gont- > opsec-ip-options-filtering-01 > > Donald, > > Thanks for the response, some additional follow-ups inline. > > On 5/13/2011 12:04 PM, Smith, Donald wrote: > > General comment this document needs a through spell checking:) > > Additional comments in line below. > > > > > > "When packets collide the controllers cease transmission AND wait a > random time before retransmission (mostly)!" > > Donald.Smith@qwest.com > > > > > >> -----Original Message----- > >> From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On > Behalf > >> Of Carlos Pignataro > >> Sent: Thursday, May 12, 2011 9:11 PM > >> To: Fernando Gont > >> Cc: 'opsec@ietf.org' > >> Subject: Re: [OPSEC] Fwd: New Version Notification for draft-gont- > >> opsec-ip-options-filtering-01 > >> > >> Hi Fernando, > >> > >> I wanted to share some high-level comments on this I-D. I hope this > is > >> useful feedback. > >> > >> The great majority of this document as currently structured dives > into > >> details about fifteen IPv4 Options, assessing threat model -> impact > if > >> blocked -> advise. I think that the threat -> impact -> advise is a > >> good > >> model. > >> > >> However, this flow seems to make some strong underlying assumptions: > >> 1. It may assume that the current state is that options are not > >> blocked. > > I didn't read it that way. > > I read it to assume that ip options MIGHT not be filtered and > therefore MAY arrive unfiltered. > > > > OK, I can see that too. > > One thing that perhaps would help, as a suggestion, is to specify the > scope and instantiation of filtering. Is it through an ISP, to a Large > Enterprise datacenter, at the edge, or at some infrastructure? Lots of ways to slice and dice this one but primary function of the router = makes the most sense to me. > > > > >> But currently, IP optioned packets do not have unfiltered success in > >> the > >> Internet: > >> http://www.ietf.org/mail-archive/web/int-area/current/msg02334.html > >> http://www.ietf.org/mail-archive/web/int-area/current/msg02360.html > > This appears to be about NEW IP options not known existing ones. > > > > Here are the options used in the test. > > --ip-options \xc0\x06\xde\xad\xbe\xef\x00\x00 > > > > Hex C0 =3D 11000000 binary or 192 in decimal. > > I couldn't find an ip options type of 192. > > > > Yes, this test is for new options (which the doc should cover as well > as > to what to do with "the rest" / unknown. The paper cited at the earlier > email, S4.3 of > , > covers > both existing and new options. So do we lump all of the "never seen in the wild" values together. Or should we have 'assigned but seldom seen' category vs undefined vs new .= .. ?? > > > > > > >> > >> 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 am familiar with the top carrier class router vendors and their ip > options filtering ability. > > It certainly isn't complete but most support filtering many of the > options identified in this document as potentially needing to be > filtered. > > > > I know of routers that do via ACLs and routers that don't. And the ones > that do, they support all options either by specifying a name for a > well-known one or entering the type number. Agreed. > > Some "typical enterprise" might not deploy carrier class routers, at > least everywhere. > > If most support it but some do not, I think the doc could speak to what > to do if not. > > Frankly, I think this is more important in the next point, as operators > might choose to not deal with particular options by type but instead > with all at once, and differently though versus to the device. Through vs. to is an important distiction but where through also means "hit= s the RE" there is less difference as the effect can be similar. > > > > >> > >> 3. It assumes that a desired granularity is to filter at the option > >> level, generally. This might result in increased and unjustified > OpEx, > >> and an operator might chose to simply make a blanked determination, > >> even > >> when the capability to filter per-option might exist. > > True enough, however I believe most ISPs are already blocking or > ignoring many of the ip options that potentially need to be filtered. > > > > I agree, but in my experience, the way in which they are blocked is > often times all at once regardless of type, and differently through the > device (ignore options) versus to the device (drop). The all ignore has some issues as Fernando points out RSVP for example can = be impacted. Now if you can say "process this type" and ignore the rest that's probably = the best approach. > > >> > >> 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. > > Strongly agree, ignoring an option from a SP perspective is much > better then filtering them. > > Rate limiting them towards the control plane/RE is probably also a > valuable recommendation but is at least partially covered in other > rfc's. > > > > I agree with both these statements. > > > If I can leave your packet unmolested and deny others an attack > avenue against the router's RE that is always my first choice. > > Any packet I have to modify costs me some amount of processing and > impacts our clients ability to generate traffic of their choice. > > > > That matches my experience as well. There is an opex variable as well, > so as to ignore all options through and drop all options to is a two- > liner. > > > Should we call out what an ISP should do vs. an enterprise? > > I think so. > > > Additionally recommending what a core router, edge router, PE, > peering router and cpe should do? > > I think so to. And the other variable to be explicit about is to vs. > through. > > > > > Additionally most of the recommendations say filter but I did see > drop in at least one recommendation. > > > > What's the difference in meaning between the two? I think they are meant to be the same. I was pointing out an inconsistenty. Fernando if you inteded drop to mean something different the filter you may= want to clarify that here. > > > >> > >> 5. Doing an enumeration of all options would either need to be > >> exhaustive (and it appears that the document does not contain all > >> option > >> values from , e.g., > >> 147), > >> or provide a catch-all final else clause in the conditional. This is > >> also solved by providing a non-per-option-value discussion. > > Both could be useful. > > > > Agree. > > >> > >> Based on this, I believe that a document about ip-options-filtering > >> should start at a much higher level discussing coarse granularity > (less > >> opex) options, as well as reasons for a perceived current state. > There > >> are operational considerations to doing per-option-value filtering > >> versus generic option filtering or ignoring, and I believe those > should > >> be discussed early on on the document. > > I agree this could provide additional value but am a bit concerned as > others have suggested the document is too large:( > > > > I could agree that the document is too large. That was part of my > comment in regards to structure. However having: > > 1. A description of all-or-nothing filtering and ignoring at the > beginning, followed by > > 2. a table summarizing the per-option citations and dispositions > > Can provide a concise kernel of information, followed by details for > completeness. > > Just a suggestion. This sounds like a good approach to me. > > >> > >> Some more specific comments: > >> > >> I suspect that the phrase "IP Options filtering" that is used > >> throughout > >> the doc can be a bit ambiguous. The options are not filtered, the > whole > >> optioned datagram is. > >> > >> The intended status listed is BCP, and I wonder if that is what this > >> document is providing. More than a current practice (which arguably > is > >> to filter or ignore without looking at the option value, modulo > >> exceptions), it appears to provide Information about impact of > >> filtering > >> particular options. > >> > >> 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. > > > > Again from an SP perspective this is current and correct most large > router vendors today use the ASIC forwarder and RE/CPU architecture. > > Many have added additional layers so it may be asic for most > forwarding, then a shared NP for some other work, then a Routing > Engine. > > > > Right, but LCs have processors that perform CP functions often times, > and like you say there are layers of forwarding. > > I agree though with the point that (I understand) is being made here, > since there is no hop-by-hop versus end-to-end concept for IPv4 > options, > there is a different (and more CPU-expensive) processing path for IPv4 > Optioned packets than optionless ones. I would just suggest, as an > editorial, to make that point explicitly and in a timeless way without > delving into routing architectures. > > Thanks, > > -- Carlos. > > > > > > >> > >> 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. > >> > >> The document does not describe what the resulting disposition of a > >> packet with many options should be. > >> > >> Nits: > >> > >> There seems to be an inconsistency with the timestamp option: > >> > >> The timestamp option has a number of security implications. > Among > >> them are: > >> ... > >> No security issues are known for this option, other than the > general > >> security implications of IP options discussed in Section 2. > >> > >> The short title is "IPv4 Security Assessment". > >> > >> There > >> > >> I hope these comments are clear, please do let me know anything that > >> does not parse, I hope this is useful. > >> > >> Thanks, > >> > >> -- Carlos. > >> > >> > >> On 4/26/2011 6:52 PM, Fernando Gont wrote: > >>> Folks, > >>> > >>> We have published a revision of our I-D "IP Options Filtering > >>> Recommendations". It is available at: > >>> http://tools.ietf.org/html/draft-gont-opsec-ip-options-filtering-01 > >>> > >>> Publication of this document had been suggested at the Hiroshima > >> IETF. > >>> Version -00 had expired a while ago, and I decided to invest some > >> time > >>> and bring this document back to life. This time with much help from > >> Ran > >>> Atkinson, who is co-authoring this latest rev. > >>> > >>> Any comments will be welcome. > >>> > >>> Thanks! > >>> > >>> Best regards, > >>> Fernando > >>> > >>> > >>> > >>> > >>> -------- Original Message -------- > >>> Subject: New Version Notification for > >>> draft-gont-opsec-ip-options-filtering-01 > >>> Date: Tue, 26 Apr 2011 15:31:13 -0700 (PDT) > >>> From: IETF I-D Submission Tool > >>> To: fernando@gont.com.ar > >>> CC: rja.lists@gmail.com > >>> > >>> > >>> A new version of I-D, draft-gont-opsec-ip-options-filtering-01.txt > >> has > >>> been successfully submitted by Fernando Gont and posted to the IETF > >>> repository. > >>> > >>> Filename: draft-gont-opsec-ip-options-filtering > >>> Revision: 01 > >>> Title: IP Options Filtering Recommendations > >>> Creation_date: 2011-04-27 > >>> WG ID: Independent Submission > >>> Number_of_pages: 26 > >>> > >>> Abstract: > >>> This document document provides advice on the filtering of packets > >>> based on the IP options they contain. Additionally, it discusses > the > >>> operational and interoperability implications of such filtering. > >>> > >>> > >>> > >>> > >>> The IETF Secretariat. > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > > > > 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. > > 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. From fernando.gont.netbook.win@gmail.com Fri May 20 00:23:13 2011 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 0191DE06E3 for ; Fri, 20 May 2011 00:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+dWNr-rQfQB for ; Fri, 20 May 2011 00:23:12 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D5C52E06D7 for ; Fri, 20 May 2011 00:23:11 -0700 (PDT) Received: by vxg33 with SMTP id 33so2946749vxg.31 for ; Fri, 20 May 2011 00:23:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=OEtf3HNjHqobC465rVQjJ4QxwZxXRqjJrXKzkj3wMBE=; b=DLYo3rweyUONAfeFL5XDPGuhnSS+umbYCdiWMWrdtb1Y1cdKXwF7mdFyqgL17W54yc A0PZBAtyPU5w0eurDj52KWvPvkGAv5erJtghRxZcSX7zsdXAzQD1zjLUxQVOz9C6tZ59 K03sHqsTh4C4Oou35/UJcv4oZvIq9vQHorzpo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=OFig11M6EoXi8gEEVBlt0mIKrUkQaayfsXUoiBY40AffoaQRxVXukjn4p5TPN+WlaL Vi0QPI7UQoXP6pICP6tSSIdvtcQJqxc/wYcVZvCf/1hl7zLlU/xz+NZLlKq0VE+8SoPQ /WKqVZuqwLzKV8f8lCvM1fff/CHYM0wuC892k= Received: by 10.52.94.239 with SMTP id df15mr1787190vdb.254.1305876190795; Fri, 20 May 2011 00:23:10 -0700 (PDT) Received: from [192.168.2.108] ([190.81.107.153]) by mx.google.com with ESMTPS id g2sm1530242vbz.0.2011.05.20.00.23.08 (version=SSLv3 cipher=OTHER); Fri, 20 May 2011 00:23:09 -0700 (PDT) Sender: Fernando Gont Message-ID: <4DD5F510.5060405@gont.com.ar> Date: Fri, 20 May 2011 01:58:56 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Carlos Pignataro References: <4DB74CBD.2050003@gont.com.ar> <4DCCA138.2000908@cisco.com> In-Reply-To: <4DCCA138.2000908@cisco.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] Fwd: New Version Notification for draft-gont-opsec-ip-options-filtering-01 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 07:23:13 -0000 Hi, Carlos, Please find my comments inline... On 05/13/2011 12:10 AM, Carlos Pignataro wrote: > However, this flow seems to make some strong underlying assumptions: > 1. It may assume that the current state is that options are not blocked. > But currently, IP optioned packets do not have unfiltered success in the > Internet: > http://www.ietf.org/mail-archive/web/int-area/current/msg02334.html > http://www.ietf.org/mail-archive/web/int-area/current/msg02360.html The document does not assume that options are not filtering in the current Internet, but rather argues what should/could/should not be done with respect to IP options filtering. -- I agree that it would be good to have some text and pointers about the current state of affairs wrt ip options filtering. -- Will craft some text and post it for review. > 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. > > 3. It assumes that a desired granularity is to filter at the option > level, generally. This might result in increased and unjustified OpEx, > and an operator might chose to simply make a blanked determination, even > when the capability to filter per-option might exist. 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. > 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. [....] > Based on this, I believe that a document about ip-options-filtering > should start at a much higher level discussing coarse granularity (less > opex) options, as well as reasons for a perceived current state. There > are operational considerations to doing per-option-value filtering > versus generic option filtering or ignoring, and I believe those should > be discussed early on on the document. I agree with this. If you can craft text for that, that'd be welcome. > Some more specific comments: > > I suspect that the phrase "IP Options filtering" that is used throughout > the doc can be a bit ambiguous. The options are not filtered, the whole > optioned datagram is. Agreed. This was also noted by another participant off-list, and will be fixed in the next rev. > 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? > 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? > The document does not describe what the resulting disposition of a > packet with many options should be. Will fix this. > I hope these comments are clear, please do let me know anything that > does not parse, I hope this is useful. Indeed it is! Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From warren@kumari.net Wed May 25 06:18:07 2011 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 DB8D4E0721 for ; Wed, 25 May 2011 06:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z06F9THwmAxy for ; Wed, 25 May 2011 06:18:06 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 57224E067C for ; Wed, 25 May 2011 06:18:06 -0700 (PDT) Received: from [192.168.0.203] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id DEA901B4003E for ; Wed, 25 May 2011 09:18:04 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Wed, 25 May 2011 09:19:10 -0400 Message-Id: To: opsec@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [OPSEC] ISP BGP filtering draft. X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 13:18:08 -0000 Hi all, Many many moon ago (in Anaheim) I started writing a draft on "some = recommendations and suggestions regarding filtering BGP announcements = from customers." -- I started this with great intentions, but as with = many things, quickly got distracted.... Anyway, as chair I feel it would probably be inappropriate for me to = continue writing it -- so, I have a partially completed draft that is = looking for a good home. Is there anyone here that would be willing to take it over? If so, let = me know and I'll throw the XML at you=85 I never polished it enough to post it, so here it is in all it's glory^w = horror. W = --------------------------------------------------------------------------= -------------------- TBD W. Kumari Internet-Draft Google Intended status: Informational June 1, 2010 Expires: December 3, 2010 Filtering BGP Customers. draft-wkumari-isp-protocol-filtering Abstract This document provides some recommendations and suggestions regarding filtering BGP announcements from customers. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 3, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Kumari Expires December 3, 2010 [Page 1] Internet-Draft Filtering BGP Customers. June = 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 6 5. Other recommendations, probably in a different doc . . . . . . 7 6. Deny versus Warning . . . . . . . . . . . . . . . . . . . . . 8 7. AS Path filtering . . . . . . . . . . . . . . . . . . . . . . 9 7.1. AS Path Uniformity . . . . . . . . . . . . . . . . . . . . 9 7.2. AS Path Length . . . . . . . . . . . . . . . . . . . . . . 9 7.3. Filter your own AS number . . . . . . . . . . . . . . . . 9 7.4. Max-prefixes . . . . . . . . . . . . . . . . . . . . . . . 10 8. Address space filtering . . . . . . . . . . . . . . . . . . . 11 8.1. Deny own IP Space . . . . . . . . . . . . . . . . . . . . 11 8.2. Deny Bogons . . . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 12. Normative References . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 Kumari Expires December 3, 2010 [Page 2] Internet-Draft Filtering BGP Customers. June = 2010 1. Introduction There have been numerous outages and security incidents caused by poor filtering of customers by their providers. This lack of good filtering allows customers to (accidentally or maliciously) announce address space that they are not authorized to, to announce routes from one provider to another (and so transit traffic from one provider to another), to announce a large numbers of prefixes, as well as many other things that could cause issues. While in most instances it appears that the incident was accidental it is worth keeping in mind that anything that can be done accidentally can also be done maliciously, and so it prudent assume a malicious party and act accordingly. While this document contains many suggestions that apply to connections between providers, it is primarily aimed at provider to customer connections. The provider and customer terms are very loosely defined, and mean different things to different people, so we will try to describe how we are using them in this document. A "provider" is entity that is provides access to the Internet. It usually carries "full routes", has multiple customers, is multihomed and is often referred to as an ISP (Internet Service Provider). A customer is an entity that gets access to the Internet through a provider. Its primary business purpose is usually something other than Internet Access, it may or may not be multihomed and usually only announces a few prefixes -- "customers" are often a stub AS. In order to aid with deployment of the described techniques, examples (and the language used by two vendors) are provided in the Appendices. These should be viewed as examples only, and customized before being used. 1.1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Kumari Expires December 3, 2010 [Page 3] Internet-Draft Filtering BGP Customers. June = 2010 2. Terminology WK: TODO: Figure out what terminology I am using. Maybe: Provider, Customer, Bogon?!. Bogon: A prefix that is known to not be used on the Internet, either because it is not allocated, or is a special use address such as described in [RFC5735] Provider: A provider is an entity that provides access to the Internet (often called an ISP). In this document we are assuming that the provider communicates with its customers over BGP. Customer: An entity that gets connectivity from a provider. [TODO(WK): Fix / tighten up this definition. Definitions are hard, lets go shopping.] Hijack: A hijack is when an entity (accidentally or maliciously) announces a resource that they are not authorized to. Examples of this would be a prefix (a prefix hijack) or an autonomous system number (and AS hijack). Warning Community: A community (chosen by that provider) that it will use to mark suspicious announcements. Kumari Expires December 3, 2010 [Page 4] Internet-Draft Filtering BGP Customers. June = 2010 3. Background In recent years the Internet has become a critical resource for a large number of companies. This has led a substantial increase in multi-homing, often by customers that have very little experience with BGP. In many cases the "network engineer" for the company is also responsible for many other aspects of technology and so cannot dedicate as much time and effort to the networking side as it deserves. This can lead to engineers with only very rudimentary knowledge of BGP performing the BGP configuration. Even in organizations with very knowledgeable and experienced engineers, mistakes can (and do) still happen - for this reason, this document suggests a "belt and suspenders" type design, so that mistakes (or intentional attacks against the routing system) can be mitigated / avoided altogether. There are numerous efforts underway to address many of these issues in a much more automated and secure manner, such as the work in the SIDR (Secure Inter-Domain Routing) Working Group. This document exists to provide a solution until these efforts are deployed, and addresses some issues that they do not. (TODO(WK): Consider inserting some examples like YT/Pakistan Tele, AS7007 ?). Kumari Expires December 3, 2010 [Page 5] Internet-Draft Filtering BGP Customers. June = 2010 4. Recommendations [TODO(WK): This is a place holder for all recommendations. For each recommendations, list: Title. Brief description, Pros / Cons, Applicability. 1. Filter to deny your own / infrastructure space. 2. Filter to deny your own AS(s) -- DONE 3. Filter to only permit the customer space. 4. Filter out bogons (TODO(WK): Insert *scary* text re: not keeping bogons up to date. Consider just removing any mention of this!). -- DONE 5. Filter to only allow the customer AS. 6. Implement something like max-prefixes (TODO(WK): Figure out vendor independent name) -- DONE 7. Route-filter to only allow ASPATH of < 10 (TODO(WK): Pick a number) -- Kinda Kumari Expires December 3, 2010 [Page 6] Internet-Draft Filtering BGP Customers. June = 2010 5. Other recommendations, probably in a different doc 1. GTSM / BGP TTL hack. 2. Juniper's "configured neighbors" prefix list thing. 3. MD5's?! Point to KARP? something... Kumari Expires December 3, 2010 [Page 7] Internet-Draft Filtering BGP Customers. June = 2010 6. Deny versus Warning While providers can craft filters that only allow customers to make a very restricted set of announcements, it is sometimes preferable to craft slightly less draconian filters to allow a slightly larger set of announcements and then follow up with the customer to check if what they are announcing is what they intended to announce. [TODO(WK): Add something about nipping problems in the bud and making things tidier.] This can be accomplished by marking announcements that may indicate the existence of an issue with a chosen community (which we will refer to as the "Warning Community") and then monitoring for routes tagged with that community. This can be done with in conjunction with other measures, such as tagging the suspect announcements with NO_ADVERTISE or NO_EXPORT, or placing them into a different routing instance. In order for this technique to be effective a provider should monitor for routes tagged with this warning community and take appropriate action For example, if a provider has a policy that the longest prefix it will accept from a customer is a /24 and it receives an announcement for 192.0.2.0/25 it could accept the announcement and tag it with NO_EXPORT and its Warning Community. A monitoring script would detect these routes and generate an alert so that the provider could contact the customer to determine if this was an error or if the customer intended to make this announcement. This may be preferable to just denying the announcement as it allows the root issue to be resolved. By addressing the root issue (as opposed to just mitigating symptoms) we end up with a cleaner network, which makes future troubleshooting easier. Fixing the problem also decrease the impact if the provider "drops filters" temporarily (for example during troubleshooting). Kumari Expires December 3, 2010 [Page 8] Internet-Draft Filtering BGP Customers. June = 2010 7. AS Path filtering Filtering of customers announcements can be performed in many ways, but the two primary methods are by filtering based upon characteristics of the AS_PATH [TODO(WK): Check capitalization / definition of "AS_PATH"] (AS Path filtering) and on the address space. This section focuses on AS Path filtering. 7.1. AS Path Uniformity In many cases a provider will know that a customer is a stub network and should only be announcing it's own AS number. This can be enforced by applying an AS Path filter that only permits the customer's AS number, possibly repeated multiple times. This provides multiple levels of protections. It protects the provider against the customer competing with the provider by selling transit to other entities (and so violating their contract), it protects against accidental leaks of routes from one provider to another and also protects against accidental leaks of "private" AS numbers[RFC1930]. An example of a filter that only allows the customer AS is provided in Appendix A.1. 7.2. AS Path Length While AS paths that are substantially longer than what is needed to perform traffic engineering are not technically incorrect they may be symptoms of other issues. For example, if Customer A is multihomed to both Provider B and Provider C (both large, well connected providers), then Customer A can achieve traffic engineering by prepending N+1 times, where N is the number of ASs between Provider B and Provider C. If Customer A is prepending many more times than this, it is likely an error, or Customer A needs a little help understanding how prepending works. This is an example of where tagging these routes with a Warning Community may help. 7.3. Filter your own AS number Depending on the size of a customer and how many other networks they peer with, it may be difficult to determine what all AS numbers they may be announcing to you. One thing that you can be certain of though is that they should never be announcing your own AS to you. While the standard BGP loop prevention algorithm *should* protect you from ever accepting an update with your own AS in it, it doesn't hurt Kumari Expires December 3, 2010 [Page 9] Internet-Draft Filtering BGP Customers. June = 2010 to be extra careful (some implementations allow you to relax the rule, and some providers use multiple AS numbers). This can by done by simply crafting an AS_PATH regular expression that macthes your Authonomous System number and denying any update that contains this. 7.4. Max-prefixes The max-prefixes knob allows a provider to set a limit on how many prefixes it will accept over a peering session. This can be a very useful tool and can prevent a large range of issues. If a provider knows that its customer will only announce a single prefix, it can set max-prefix to one or two. If the customer accidenatlly redistributes thier IGP into BGP, the max-prefixes limit will kick in and drop the peerin session. If the customer sends a large number (a few hundred or thousands), it is good practice to monitor how many prefixes the customer sends, and set max-prefixes to be some percentage higher than the current number. Some vendors allow setting of two limits, a lower limit at which the router will log a warning message, and a higher limit at which the session will be shut down. Kumari Expires December 3, 2010 [Page 10] Internet-Draft Filtering BGP Customers. June = 2010 8. Address space filtering 8.1. Deny own IP Space In many cases customers are assigned address space by their provider, which often means that the customer is using address space that is "similar" to space used by the provider. By "similar" we mean that the customer is using a subnet (longer prefix) of the providers space, or that a simple typing mistake could cause the customer to accidentally use the same space as the provider. And example of this would be if the provider assigned 10.0.10.0/24 to the customer and the customer accidentally configured 10.0.10.0/20 or 10.10.0.0/24. It is a good practice to address network (and similar) infrastructure out of blocks set aside for this purpose. This allows the application of access lists (or filters) to protects this infrastructure and only allow access from authorized locations. By applying BGP prefix list filters to prevent learning external routes to ones own infrastructure space, one can avoid learning (and following) hijacked space to devices outsides one's network. 8.2. Deny Bogons This section should be approached with dicipline! Bogons are addresses that you know are not currently valid addresses for use on the Internet. This includes addresses that have not yet been allocated, Special Use Addresses ([RFC5735][RFC5156]), example addresses and similar. It is simple to filter out announcements with these address, but if this is done, one MUST ensure that you keep up to date with this. There have been amlost as many issues with Bogon filters being deployed and not kept up to date as there have been from not having Bogon filters at all. Kumari Expires December 3, 2010 [Page 11] Internet-Draft Filtering BGP Customers. June = 2010 9. Acknowledgements I would like to thank the IETF community for making me feel welcome - some of my best friendships have been a direct result of the IETF. I would like to thank Google for 20% time and allowing me to work in this space. [This space for rent.] Kumari Expires December 3, 2010 [Page 12] Internet-Draft Filtering BGP Customers. June = 2010 10. Security Considerations 10.1. Privacy TODO(WK) -- Fill this in! Kumari Expires December 3, 2010 [Page 13] Internet-Draft Filtering BGP Customers. June = 2010 11. IANA Considerations No action required. Kumari Expires December 3, 2010 [Page 14] Internet-Draft Filtering BGP Customers. June = 2010 12. Normative References [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", BCP 6, RFC 1930, March 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, April 2008. [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010. Kumari Expires December 3, 2010 [Page 15] Internet-Draft Filtering BGP Customers. June = 2010 Author's Address Warren Kumari Google 1600 Amphitheater Parkway Mountain View, CA 94043 US Email: warren@kumari.net Kumari Expires December 3, 2010 [Page 16] From thegameiam@yahoo.com Wed May 25 13:50:49 2011 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 422231300F3 for ; Wed, 25 May 2011 13:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.258 X-Spam-Level: X-Spam-Status: No, score=-1.258 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, MIME_HTML_MOSTLY=0.001, MPART_ALT_DIFF=0.739] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9ZJfTND3rpN for ; Wed, 25 May 2011 13:50:47 -0700 (PDT) Received: from nm12-vm1.bullet.mail.ne1.yahoo.com (nm12-vm1.bullet.mail.ne1.yahoo.com [98.138.91.41]) by ietfa.amsl.com (Postfix) with SMTP id 571E41300F2 for ; Wed, 25 May 2011 13:50:47 -0700 (PDT) Received: from [98.138.90.53] by nm12.bullet.mail.ne1.yahoo.com with NNFMP; 25 May 2011 20:50:46 -0000 Received: from [98.138.86.156] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 25 May 2011 20:50:46 -0000 Received: from [127.0.0.1] by omp1014.mail.ne1.yahoo.com with NNFMP; 25 May 2011 20:50:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 804659.91320.bm@omp1014.mail.ne1.yahoo.com Received: (qmail 86987 invoked by uid 60001); 25 May 2011 20:50:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1306356646; bh=DLV9/dzjySKX3Yvj6axJO99XF3sFfWhDEEkwK/L+CyY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=hVIkepcvnwdQM3NvloUDN0Fhyrg3BRzM63F3vJ3pp8vIKiLl2/b/whN09uoSYwTGL2uXs1U8hfGA38xdjwwtp5v1avgmQdld9nsiy8kqPZlIFjlW07/d+T9uFQo/mRWMGDRENT3m2YGh331Kp1nX02Nt9q2gfDVKzrnJUinOpBw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=eqbngRAtSeH6pUA22OkooHfRs5Bai6efjtkYdYV7L5EWA03bQvMfMwqB9GFarKc9vCaa4v2mgRC700DqQS62kTS9wHmLN8iKdKNj5gswX+Dm/yGA2PtJ7eJtN6SJTFmCySmIfDvlx0+tSaNt5Idpf5iw/pI4S6YhVe5AirX+8Ck=; Message-ID: <243194.37888.qm@web31810.mail.mud.yahoo.com> X-YMail-OSG: re.75AgVM1n7cI3ztxVOEF3mprSx_FHEBOJjkt.VbuChuaG v3KPei7U84HQvCfLSfzfhAyU9NGx_dtFKFi3gqlR4ph4PCaY55oAgkBe3X18 dbFHfPB9zHBb3yhWCY2tnW9_9sKSYd0T9Gh61_sZ.LV2y_hA.BLyQOVtigxj f0EyAfxWN2TxKSLMnuwdZIGo5mVFTVv1STkl_s2MjH6DfRgr3S0btIoMWTnu GQ8Kk77aDKDTILAsbcURbReclfSkTzJC3Fq.QnR1uCVrSBbUXKxqFqZn5GJi a4SYnly8LZsVOMlZim.eCB2ddtKDJ.0wEkVRJywNs.HD5EMR4nKf9pZfMBvZ zHPhBWw6rDejkhVE5oCe4cktpn4R4c8siY.FSwIyokgECasj8ziV4LMse5y8 V1gELXmtGZqS8nP9ytcJ0EkNiebArwZJOC7MUEeA4vzxE7K8jKAgj1GlORAU SxQtm8w-- Received: from [96.231.74.195] by web31810.mail.mud.yahoo.com via HTTP; Wed, 25 May 2011 13:50:46 PDT X-Mailer: YahooMailWebService/0.8.111.304355 Date: Wed, 25 May 2011 13:50:46 -0700 (PDT) From: David Barak To: warren@kumari.net, opsec@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-638482304-1306356646=:37888" Subject: Re: [OPSEC] ISP BGP filtering draft. X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 20:50:49 -0000 --0-638482304-1306356646=:37888 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I'll take a swing at it.=0A=0A-David Barak --0-638482304-1306356646=:37888 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I'll take a swing at it.

-= David Barak
=0A =
=0A
=0A
=0A = =0A =
=0A =0A = From:=0A = =0A Warren Kumari <wa= rren@kumari.net>;
=0A = =0A To:=0A =0A = <opsec@ietf.org>; =
=0A = =0A Subject:=0A =0A = [OPSEC] ISP BGP filtering draft. =
=0A =0A = Sent:=0A = =0A Wed, May 25, 2011 1:19:10 PM =
=0A =0A =
=0A =0A =0A =0A = =0A = =0A
Hi all,

Many = many moon ago (in Anaheim) I started writing a draft on "some recommendatio= ns and suggestions regarding filtering BGP announcements from customers." -= - I started this with great intentions, but as with many things, quickly go= t distracted....

Anyway, as chair I feel it would probably be inapp= ropriate for me to continue writing it -- so, I have a partially completed = draft that is looking for a good home.
Is there anyone here that would b= e willing to take it over? If so, let me know and I'll throw the XML at you= =E2=80=A6


I never polished it enough to post it, so here it is i= n all it's glory^w horror.
W


--------------------------------= --------------------------------------------------------------


<= BR>TBD                   =                                   &nbs= p;     W. Kumari
Internet-Draft        &nb= sp;                     &= nbsp;                    = Google
Intended status: Informational         =                     June= 1, 2010
Expires: December 3, 2010


       = ;                 Filtering BGP Cus= tomers.
                  d= raft-wkumari-isp-protocol-filtering

Abstract

  This doc= ument provides some recommendations and suggestions regarding
  fi= ltering BGP announcements from customers.

Status of this Memo
  This Internet-Draft is submitted in full conformance with the
  provisions of BCP 78 and BCP 79.

  Internet-Dr= afts are working documents of the Internet Engineering
  Task Forc= e (IETF).  Note that other groups may also distribute
  worki= ng documents as Internet-Drafts.  The list of current Internet-
&nb= sp; Drafts is at http://datatracker.ietf.org/drafts/current/.

&nb= sp; Internet-Drafts are draft documents valid for a maximum of six months<= BR>  and may be updated, replaced, or obsoleted by other documents at= any
  time.  It is inappropriate to use Internet-Drafts as r= eference
  material or to cite them other than as "work in progres= s."

  This Internet-Draft will expire on December 3, 2010.
=
Copyright Notice

  Copyright (c) 2010 IETF Trust and the p= ersons identified as the
  document authors.  All rights reserved.

  This document is subject to BCP 78 and the IETF T= rust's Legal
  Provisions Relating to IETF Documents
  (<= a href=3D"http://trustee.ietf.org/license-info" target=3D_blank >http://tru= stee.ietf.org/license-info) in effect on the date of
  publica= tion of this document.  Please review these documents
  caref= ully, as they describe your rights and restrictions with respect
  = to this document.  Code Components extracted from this document must<= BR>  include Simplified BSD License text as described in Section 4.e = of
  the Trust Legal Provisions and are provided without warranty = as
  described in the Simplified BSD License.




<= BR>
Kumari                 = Expires December 3, 2010              &= nbsp; [Page 1]
Internet-Draft         =20 Filtering BGP Customers.              = June 2010


Table of Contents

  1.  Introduction= . . . . . . . . . . . . . . . . . . . . . . . . .  3
   = 1.1.  Requirements notation  . . . . . . . . . . . . . . . . . = .  3
  2.  Terminology  . . . . . . . . . . . . . .= . . . . . . . . . . .  4
  3.  Background . . . . . . .= . . . . . . . . . . . . . . . . . . .  5
  4.  Recommen= dations  . . . . . . . . . . . . . . . . . . . . . . .  6
&nbs= p; 5.  Other recommendations, probably in a different doc . . . . . .=   7
  6.  Deny versus Warning  . . . . . . . . . . = . . . . . . . . . . .  8
  7.  AS Path filtering  .= . . . . . . . . . . . . . . . . . . . . .  9
    7.1.&n= bsp; AS Path Uniformity . . . . . . . . . . . . . . . . . . . .  9
    7.2.  AS Path Length . . . . . . . . . . = . . . . . . . . . . . .  9
    7.3.  Filter your ow= n AS number  . . . . . . . . . . . . . . . .  9
    = 7.4.  Max-prefixes . . . . . . . . . . . . . . . . . . . . . . . 10  8.  Address space filtering  . . . . . . . . . . . . . = . . . . . . 11
    8.1.  Deny own IP Space  . . . .= . . . . . . . . . . . . . . . . 11
    8.2.  Deny Bogon= s  . . . . . . . . . . . . . . . . . . . . . . . 11
  9. = ; Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
&nbs= p; 10. Security Considerations  . . . . . . . . . . . . . . . . . . .= 13
    10.1. Privacy  . . . . . . . . . . . . . . . . .= . . . . . . . . 13
  11. IANA Considerations  . . . . . . . = . . . . . . . . . . . . . . 14
  12. Normative References . . . . . . . . . . . . . . . . . . . . . 15
  Author's Address . .= . . . . . . . . . . . . . . . . . . . . . . . 16























<= BR>


Kumari               = ;   Expires December 3, 2010            =     [Page 2]
Internet-Draft          = Filtering BGP Customers.              = June 2010


1.  Introduction

  There have been n= umerous outages and security incidents caused by
  poor filtering = of customers by their providers.  This lack of good
  filteri= ng allows customers to (accidentally or maliciously) announce
  ad= dress space that they are not authorized to, to announce routes
  = from one provider to another (and so transit traffic from one
  provider to another), to announce a large numbers of prefix= es, as
  well as many other things that could cause issues.  = While in most
  instances it appears that the incident was acciden= tal it is worth
  keeping in mind that anything that can be done a= ccidentally can also
  be done maliciously, and so it prudent assu= me a malicious party and
  act accordingly.

  While t= his document contains many suggestions that apply to
  connections= between providers, it is primarily aimed at provider to
  custome= r connections.  The provider and customer terms are very
  lo= osely defined, and mean different things to different people, so we
&nbs= p; will try to describe how we are using them in this document.  A  "provider" is entity that is provides access to the Internet. = ; It
  usually carries "full routes", has multiple customers, is multihomed
  and is often referred to as an ISP (In= ternet Service Provider).  A
  customer is an entity that get= s access to the Internet through a
  provider.  Its primary b= usiness purpose is usually something other
  than Internet Access,= it may or may not be multihomed and usually
  only announces a fe= w prefixes -- "customers" are often a stub AS.

  In order to a= id with deployment of the described techniques, examples
  (and th= e language used by two vendors) are provided in the
  Appendices.&= nbsp; These should be viewed as examples only, and customized
  be= fore being used.

1.1.  Requirements notation

  The= key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  = "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
&n= bsp; document are to be interpreted as described in [RFC2119].














Kuma= ri                  Expires De= cember 3, 2010                [Page= 3]
Internet-Draft          Filtering BGP Cust= omers.              June 2010

2.  Terminology

  WK: TODO:  Figure out what termi= nology I am using.  Maybe: Provider,
      Customer,= Bogon?!.

  Bogon:  A prefix that is known to not be used= on the Internet, either
      because it is not allocate= d, or is a special use address such as
      described in= [RFC5735]

  Provider:  A provider is an entity that prov= ides access to the
      Internet (often called an ISP).&= nbsp; In this document we are assuming
      that the provider communicates with its customers over BGP.

  Cust= omer:  An entity that gets connectivity from a provider.
  &nb= sp;   [TODO(WK): Fix / tighten up this definition.  Definitions a= re
      hard, lets go shopping.]

  Hijack:&= nbsp; A hijack is when an entity (accidentally or maliciously)
  &n= bsp;   announces a resource that they are not authorized to.  Exa= mples of
      this would be a prefix (a prefix hijack) o= r an autonomous system
      number (and AS hijack).
<= BR>  Warning Community:  A community (chosen by that provider) t= hat it
      will use to mark suspicious announcements.

















<= BR>







Kumari         =         Expires December 3, 2010                [Page 4]
Internet-Draft =         Filtering BGP Customers.      =         June 2010


3.  Background
  In recent years the Internet has become a critical resource for a=
  large number of companies.  This has led a substantial inc= rease in
  multi-homing, often by customers that have very little = experience
  with BGP.  In many cases the "network engineer" = for the company is
  also responsible for many other aspects of te= chnology and so cannot
  dedicate as much time and effort to the n= etworking side as it
  deserves.  This can lead to engineers = with only very rudimentary
  knowledge of BGP performing the BGP c= onfiguration.

  Even in organizations with very knowledgeable = and experienced
  engineers, mistakes can (and do) still happen - for this reason, this
  document suggests a "belt and su= spenders" type design, so that
  mistakes (or intentional attacks = against the routing system) can be
  mitigated / avoided altogethe= r.

  There are numerous efforts underway to address many of th= ese issues
  in a much more automated and secure manner, such as t= he work in the
  SIDR (Secure Inter-Domain Routing) Working Group.=   This document
  exists to provide a solution until these ef= forts are deployed, and
  addresses some issues that they do not.<= BR>
  (TODO(WK): Consider inserting some examples like YT/Pakistan= Tele,
  AS7007 ?).

























Kumari  &= nbsp;               Expires December 3, = 2010                [Page 5]
Internet-Draft          Filtering BGP Cust= omers.              June 2010

4.  Recommendations

  [TODO(WK): This is a place holder= for all recommendations.  For each
  recommendations, list: = Title.  Brief description, Pros / Cons,
  Applicability.
<= BR>  1.  Filter to deny your own / infrastructure space.

=   2.  Filter to deny your own AS(s) -- DONE

  3.&nb= sp; Filter to only permit the customer space.

  4.  Filte= r out bogons (TODO(WK): Insert *scary* text re: not keeping
   = ;   bogons up to date.  Consider just removing any mention of th= is!).
      -- DONE

  5.  Filter to on= ly allow the customer AS.

  6.  Implement something like = max-prefixes (TODO(WK): Figure out
      vendor independent name) -- DONE

  7.  Route-filter to only all= ow ASPATH of < 10 (TODO(WK): Pick a
      number) -- = Kinda



























Kumari      &n= bsp;           Expires December 3, 2010  &nbs= p;             [Page 6]
Internet-Draft&nbs= p;         Filtering BGP Customers.     = ;         June 2010


5.  Other recommen= dations, probably in a different doc

  1.  GTSM / BGP TTL= hack.

  2.  Juniper's "configured neighbors" prefix list= thing.

  3.  MD5's?!  Point to KARP? something...
































<= BR>









Kumari       = ;           Expires December 3, 2010    =             [Page 7]
Internet-Draft  =         Filtering BGP Customers.      &= nbsp;       June 2010


6.  Deny versus Warni= ng

  While providers can craft filters that only allow custome= rs to make a
  very restricted set of announcements, it is sometim= es preferable to
  craft slightly less draconian filters to allow = a slightly larger set
  of announcements and then follow up with t= he customer to check if
  what they are announcing is what they in= tended to announce.
  [TODO(WK): Add something about nipping problems in the bud and making
  things tidier.]

&= nbsp; This can be accomplished by marking announcements that may indicate<= BR>  the existence of an issue with a chosen community (which we will=
  refer to as the "Warning Community") and then monitoring for ro= utes
  tagged with that community.  This can be done with in = conjunction
  with other measures, such as tagging the suspect ann= ouncements with
  NO_ADVERTISE or NO_EXPORT, or placing them into = a different routing
  instance.  In order for this technique = to be effective a provider
  should monitor for routes tagged with= this warning community and take
  appropriate action

 = ; For example, if a provider has a policy that the longest prefix it
&n= bsp; will accept from a customer is a /24 and it receives an announcement<= BR>  for 192.0.2.0/25 it could accept the announcement and tag it with
  NO_EXPORT and its Warning Community.  A monitoring= script would
  detect these routes and generate an alert so that = the provider could
  contact the customer to determine if this was= an error or if the
  customer intended to make this announcement.=   This may be preferable
  to just denying the announcement a= s it allows the root issue to be
  resolved.  By addressing t= he root issue (as opposed to just
  mitigating symptoms) we end up= with a cleaner network, which makes
  future troubleshooting easi= er.  Fixing the problem also decrease the
  impact if the pro= vider "drops filters" temporarily (for example
  during troublesho= oting).
















=

Kumari                 = ; Expires December 3, 2010                [Page 8]
Internet-Draft         = Filtering BGP Customers.              = June 2010


7.  AS Path filtering

  Filtering o= f customers announcements can be performed in many ways,
  but the= two primary methods are by filtering based upon
  characteristics= of the AS_PATH [TODO(WK): Check capitalization /
  definition of = "AS_PATH"] (AS Path filtering) and on the address
  space.  T= his section focuses on AS Path filtering.

7.1.  AS Path Uniform= ity

  In many cases a provider will know that a customer is a = stub network
  and should only be announcing it's own AS number.&n= bsp; This can be
  enforced by applying an AS Path filter that onl= y permits the
  customer's AS number, possibly repeated multiple t= imes.

  This provides multiple levels of protections.  It protects the
  provider against the custome= r competing with the provider by selling
  transit to other entiti= es (and so violating their contract), it
  protects against accide= ntal leaks of routes from one provider to
  another and also prote= cts against accidental leaks of "private" AS
  numbers[RFC1930].
  An example of a filter that only allows the customer AS is pr= ovided
  in Appendix A.1.

7.2.  AS Path Length

=   While AS paths that are substantially longer than what is needed to=
  perform traffic engineering are not technically incorrect they = may be
  symptoms of other issues.  For example, if Customer = A is multihomed
  to both Provider B and Provider C (both large, w= ell connected
  providers), then Customer A can achieve traffic en= gineering by
  prepending N+1 times, where N is the number of ASs between Provider B
  and Provider C. If Customer A is prep= ending many more times than
  this, it is likely an error, or Cust= omer A needs a little help
  understanding how prepending works.
  This is an example of where tagging these routes with a Warni= ng
  Community may help.

7.3.  Filter your own AS numb= er

  Depending on the size of a customer and how many other ne= tworks they
  peer with, it may be difficult to determine what all= AS numbers they
  may be announcing to you.  One thing that = you can be certain of
  though is that they should never be announ= cing your own AS to you.
  While the standard BGP loop prevention = algorithm *should* protect you
  from ever accepting an update wit= h your own AS in it, it doesn't hurt



Kumari    &nb= sp;             Expires December 3, 2010                [Page 9]
In= ternet-Draft          Filtering BGP Customers.&nb= sp;             June 2010


  = to be extra careful (some implementations allow you to relax the
 = rule, and some providers use multiple AS numbers).

  This ca= n by done by simply crafting an AS_PATH regular expression
  that = macthes your Authonomous System number and denying any update
  th= at contains this.

7.4.  Max-prefixes

  The max-pre= fixes knob allows a provider to set a limit on how many
  prefixes= it will accept over a peering session.  This can be a very
  = useful tool and can prevent a large range of issues.  If a provider  knows that its customer will only announce a single prefix, it ca= n
  set max-prefix to one or two.  If the customer accidenatlly
  redistributes thier IGP into BGP, the max-prefixes= limit will kick in
  and drop the peerin session.  If the cu= stomer sends a large number (a
  few hundred or thousands), it is = good practice to monitor how many
  prefixes the customer sends, a= nd set max-prefixes to be some
  percentage higher than the curren= t number.  Some vendors allow
  setting of two limits, a lowe= r limit at which the router will log a
  warning message, and a hi= gher limit at which the session will be shut
  down.




















<= BR>






Kumari          &nb= sp;       Expires December 3, 2010       = ;       [Page 10]
Internet-Draft      &nb= sp;   Filtering BGP Customers.              June 2010


8.  Address space filterin= g

8.1.  Deny own IP Space

  In many cases customer= s are assigned address space by their provider,
  which often mean= s that the customer is using address space that is
  "similar" to = space used by the provider.  By "similar" we mean that
  the = customer is using a subnet (longer prefix) of the providers
  spac= e, or that a simple typing mistake could cause the customer to
  a= ccidentally use the same space as the provider.  And example of this  would be if the provider assigned 10.0.10.0/24 to the customer an= d
  the customer accidentally configured 10.0.10.0/20 or 10.10.0.0= /24.

  It is a good practice to address network (and similar) = infrastructure
  out of blocks set aside for this purpose.  T= his allows the
  application of access lists (or filters) to protects this
  infrastructure and only allow access from auth= orized locations.  By
  applying BGP prefix list filters to p= revent learning external routes
  to ones own infrastructure space= , one can avoid learning (and
  following) hijacked space to devic= es outsides one's network.

8.2.  Deny Bogons

  Thi= s section should be approached with dicipline!  Bogons are
  = addresses that you know are not currently valid addresses for use on
&nb= sp; the Internet.  This includes addresses that have not yet been
=   allocated, Special Use Addresses ([RFC5735][RFC5156]), example
&= nbsp; addresses and similar.  It is simple to filter out announcement= s with
  these address, but if this is done, one MUST ensure that = you keep up
  to date with this.  There have been amlost as m= any issues with Bogon
  filters being deployed and not kept up to date as there have been
  from not having Bogon filters at = all.


















Kumari                &nbs= p; Expires December 3, 2010             = [Page 11]
Internet-Draft          Filtering = BGP Customers.              June 2010

9.  Acknowledgements

  I would like to thank th= e IETF community for making me feel welcome -
  some of my best fr= iendships have been a direct result of the IETF.  I
  would l= ike to thank Google for 20% time and allowing me to work in
  this= space.  [This space for rent.]
















=



























Kumari        =           Expires December 3, 2010    &n= bsp;         [Page 12]
Internet-Draft    =       Filtering BGP Customers.        &= nbsp;     June 2010


10.  Security Considerations=

10.1.  Privacy

  TODO(WK) -- Fill this in!




































<= BR>






Kumari          &nb= sp;       Expires December 3, 2010       = ;       [Page 13]
Internet-Draft          Filtering BGP Customers.        =       June 2010


11.  IANA Considerations
  No action required.













































<= BR>Kumari                  Exp= ires December 3, 2010              [Pag= e 14]
Internet-Draft          Filtering BGP Cu= stomers.              June 2010

=
12.  Normative References

  [RFC1930]  Hawkinson= , J. and T. Bates, "Guidelines for creation,
       =       selection, and registration of an Autonomous System (= AS)",
              BCP 6, RFC 1930, March 1996.

  [RFC2119]  Bradner, S., "Key words f= or use in RFCs to Indicate
            &nb= sp; Requirement Levels", BCP 14, RFC 2119, March 1997.

  [RFC5= 156]  Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156,
  =             April 2008.

  [RFC57= 35]  Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
 =             BCP 153, RFC 5735, January 2010.=



































Kumari                  Expi= res December 3, 2010              [Page= 15]
Internet-Draft          Filtering BGP Cus= tomers.              June 2010


Author's Address

  Warren Kumari
  G= oogle
  1600 Amphitheater Parkway
  Mountain View, CA&nbs= p; 94043
  US

  Email: warren@kumari.net



<= BR>

















=


















Kumari                  E= xpires December 3, 2010              [P= age 16]

_______________________________________________
OPSEC mai= ling list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec
=0A
=0A =
=0A
=0A
=0A --0-638482304-1306356646=:37888-- From warren@kumari.net Thu May 26 10:20:50 2011 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 62E59E06D6 for ; Thu, 26 May 2011 10:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.224 X-Spam-Level: X-Spam-Status: No, score=-102.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7OBIGBtQtqH for ; Thu, 26 May 2011 10:20:45 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id AD792E071F for ; Thu, 26 May 2011 10:20:45 -0700 (PDT) Received: from [172.19.118.214] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id AB0931B40340; Thu, 26 May 2011 13:20:42 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <243194.37888.qm@web31810.mail.mud.yahoo.com> Date: Thu, 26 May 2011 13:20:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5EE940DA-090C-4A54-8EC7-920685177AD0@kumari.net> References: <243194.37888.qm@web31810.mail.mud.yahoo.com> To: David Barak X-Mailer: Apple Mail (2.1084) Cc: opsec@ietf.org Subject: Re: [OPSEC] ISP BGP filtering draft. X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 17:20:50 -0000 On May 25, 2011, at 4:50 PM, David Barak wrote: > I'll take a swing at it. Yay! Thank you.... It's currently living on an SVN server -- the repository is:=20 SVN: https://svn.kumari.net/svn/opsec Username: davidbarak Password: raiL4oP0 Please note: The https:// in the repository URL is important. If you = just do http:// apache will try send you a redirect and SVN will get = grumpy. This repository is configured for anonymous read, but requires a PW for = making changes. I wasn't sure what username you use, so I randomly picked davidbarak, = and pwgen chose the password for you.=20 Feel free to tell me a different username and / or provide a htdigest = style password and I'll update it... W >=20 > -David Barak >=20 > From: Warren Kumari ;=20 > To: ;=20 > Subject: [OPSEC] ISP BGP filtering draft.=20 > Sent: Wed, May 25, 2011 1:19:10 PM=20 >=20 > Hi all, >=20 > Many many moon ago (in Anaheim) I started writing a draft on "some = recommendations and suggestions regarding filtering BGP announcements = from customers." -- I started this with great intentions, but as with = many things, quickly got distracted.... >=20 > Anyway, as chair I feel it would probably be inappropriate for me to = continue writing it -- so, I have a partially completed draft that is = looking for a good home. > Is there anyone here that would be willing to take it over? If so, let = me know and I'll throw the XML at you=85 >=20 >=20 > I never polished it enough to post it, so here it is in all it's = glory^w horror. > W >=20 >=20 > = --------------------------------------------------------------------------= -------------------- >=20 >=20 >=20 > TBD W. = Kumari > Internet-Draft = Google > Intended status: Informational June 1, = 2010 > Expires: December 3, 2010 >=20 >=20 > Filtering BGP Customers. > draft-wkumari-isp-protocol-filtering >=20 > Abstract >=20 > This document provides some recommendations and suggestions = regarding > filtering BGP announcements from customers. >=20 > Status of this Memo >=20 > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. >=20 > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at http://datatracker.ietf.org/drafts/current/. >=20 > Internet-Drafts are draft documents valid for a maximum of six = months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." >=20 > This Internet-Draft will expire on December 3, 2010. >=20 > Copyright Notice >=20 > Copyright (c) 2010 IETF Trust and the persons identified as the > document authors. All rights reserved. >=20 > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with = respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. >=20 >=20 >=20 >=20 >=20 >=20 > Kumari Expires December 3, 2010 [Page = 1] > Internet-Draft Filtering BGP Customers. June = 2010 >=20 >=20 > Table of Contents >=20 > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . = 3 > 1.1. Requirements notation . . . . . . . . . . . . . . . . . . = 3 > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . = 4 > 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . = 5 > 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . = 6 > 5. Other recommendations, probably in a different doc . . . . . . = 7 > 6. Deny versus Warning . . . . . . . . . . . . . . . . . . . . . = 8 > 7. AS Path filtering . . . . . . . . . . . . . . . . . . . . . . = 9 > 7.1. AS Path Uniformity . . . . . . . . . . . . . . . . . . . . = 9 > 7.2. AS Path Length . . . . . . . . . . . . . . . . . . . . . . = 9 > 7.3. Filter your own AS number . . . . . . . . . . . . . . . . = 9 > 7.4. Max-prefixes . . . . . . . . . . . . . . . . . . . . . . . = 10 > 8. Address space filtering . . . . . . . . . . . . . . . . . . . = 11 > 8.1. Deny own IP Space . . . . . . . . . . . . . . . . . . . . = 11 > 8.2. Deny Bogons . . . . . . . . . . . . . . . . . . . . . . . = 11 > 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . = 12 > 10. Security Considerations . . . . . . . . . . . . . . . . . . . = 13 > 10.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . = 13 > 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . = 14 > 12. Normative References . . . . . . . . . . . . . . . . . . . . . = 15 > Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . = 16 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Kumari Expires December 3, 2010 [Page = 2] > Internet-Draft Filtering BGP Customers. June = 2010 >=20 >=20 > 1. Introduction >=20 > There have been numerous outages and security incidents caused by > poor filtering of customers by their providers. This lack of good > filtering allows customers to (accidentally or maliciously) announce > address space that they are not authorized to, to announce routes > from one provider to another (and so transit traffic from one > provider to another), to announce a large numbers of prefixes, as > well as many other things that could cause issues. While in most > instances it appears that the incident was accidental it is worth > keeping in mind that anything that can be done accidentally can also > be done maliciously, and so it prudent assume a malicious party and > act accordingly. >=20 > While this document contains many suggestions that apply to > connections between providers, it is primarily aimed at provider to > customer connections. The provider and customer terms are very > loosely defined, and mean different things to different people, so = we > will try to describe how we are using them in this document. A > "provider" is entity that is provides access to the Internet. It > usually carries "full routes", has multiple customers, is multihomed > and is often referred to as an ISP (Internet Service Provider). A > customer is an entity that gets access to the Internet through a > provider. Its primary business purpose is usually something other > than Internet Access, it may or may not be multihomed and usually > only announces a few prefixes -- "customers" are often a stub AS. >=20 > In order to aid with deployment of the described techniques, = examples > (and the language used by two vendors) are provided in the > Appendices. These should be viewed as examples only, and customized > before being used. >=20 > 1.1. Requirements notation >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Kumari Expires December 3, 2010 [Page = 3] > Internet-Draft Filtering BGP Customers. June = 2010 >=20 >=20 > 2. Terminology >=20 > WK: TODO: Figure out what terminology I am using. Maybe: Provider, > Customer, Bogon?!. >=20 > Bogon: A prefix that is known to not be used on the Internet, = either > because it is not allocated, or is a special use address such as > described in [RFC5735] >=20 > Provider: A provider is an entity that provides access to the > Internet (often called an ISP). In this document we are = assuming > that the provider communicates with its customers over BGP. >=20 > Customer: An entity that gets connectivity from a provider. > [TODO(WK): Fix / tighten up this definition. Definitions are > hard, lets go shopping.] >=20 > Hijack: A hijack is when an entity (accidentally or maliciously) > announces a resource that they are not authorized to. Examples = of > this would be a prefix (a prefix hijack) or an autonomous system > number (and AS hijack). >=20 > Warning Community: A community (chosen by that provider) that it > will use to mark suspicious announcements. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Kumari Expires December 3, 2010 [Page = 4] > Internet-Draft Filtering BGP Customers. June = 2010 >=20 >=20 > 3. Background >=20 > In recent years the Internet has become a critical resource for a > large number of companies. This has led a substantial increase in > multi-homing, often by customers that have very little experience > with BGP. In many cases the "network engineer" for the company is > also responsible for many other aspects of technology and so cannot > dedicate as much time and effort to the networking side as it > deserves. This can lead to engineers with only very rudimentary > knowledge of BGP performing the BGP configuration. >=20 > Even in organizations with very knowledgeable and experienced > engineers, mistakes can (and do) still happen - for this reason, = this > document suggests a "belt and suspenders" type design, so that > mistakes (or intentional attacks against the routing system) can be > mitigated / avoided altogether. >=20 > There are numerous efforts underway to address many of these issues > in a much more automated and secure manner, such as the work in the > SIDR (Secure Inter-Domain Routing) Working Group. This document > exists to provide a solution until these efforts are deployed, and > addresses some issues that they do not. >=20 > (TODO(WK): Consider inserting some examples like YT/Pakistan Tele, > AS7007 ?). >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Kumari Expires December 3, 2010 [Page = 5] > Internet-Draft Filtering BGP Customers. June = 2010 >=20 >=20 > 4. Recommendations >=20 > [TODO(WK): This is a place holder for all recommendations. For each > recommendations, list: Title. Brief description, Pros / Cons, > Applicability. >=20 > 1. Filter to deny your own / infrastructure space. >=20 > 2. Filter to deny your own AS(s) -- DONE >=20 > 3. Filter to only permit the customer space. >=20 > 4. Filter out bogons (TODO(WK): Insert *scary* text re: not keeping > bogons up to date. Consider just removing any mention of = this!). > -- DONE >=20 > 5. Filter to only allow the customer AS. >=20 > 6. Implement something like max-prefixes (TODO(WK): Figure out > vendor independent name) -- DONE >=20 > 7. Route-filter to only allow ASPATH of < 10 (TODO(WK): Pick a > number) -- Kinda >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Kumari Expires December 3, 2010 [Page = 6] > Internet-Draft Filtering BGP Customers. June = 2010 >=20 >=20 > 5. Other recommendations, probably in a different doc >=20 > 1. GTSM / BGP TTL hack. >=20 > 2. Juniper's "configured neighbors" prefix list thing. >=20 > 3. MD5's?! Point to KARP? something... >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Kumari Expires December 3, 2010 [Page = 7] > Internet-Draft Filtering BGP Customers. June = 2010 >=20 >=20 > 6. Deny versus Warning >=20 > While providers can craft filters that only allow customers to make = a > very restricted set of announcements, it is sometimes preferable to > craft slightly less draconian filters to allow a slightly larger set > of announcements and then follow up with the customer to check if > what they are announcing is what they intended to announce. > [TODO(WK): Add something about nipping problems in the bud and = making > things tidier.] >=20 > This can be accomplished by marking announcements that may indicate > the existence of an issue with a chosen community (which we will > refer to as the "Warning Community") and then monitoring for routes > tagged with that community. This can be done with in conjunction > with other measures, such as tagging the suspect announcements with > NO_ADVERTISE or NO_EXPORT, or placing them into a different routing > instance. In order for this technique to be effective a provider > should monitor for routes tagged with this warning community and = take > appropriate action >=20 > For example, if a provider has a policy that the longest prefix it > will accept from a customer is a /24 and it receives an announcement > for 192.0.2.0/25 it could accept the announcement and tag it with > NO_EXPORT and its Warning Community. A monitoring script would > detect these routes and generate an alert so that the provider could > contact the customer to determine if this was an error or if the > customer intended to make this announcement. This may be preferable > to just denying the announcement as it allows the root issue to be > resolved. By addressing the root issue (as opposed to just > mitigating symptoms) we end up with a cleaner network, which makes > future troubleshooting easier. Fixing the problem also decrease the > impact if the provider "drops filters" temporarily (for example > during troubleshooting). >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Kumari Expires December 3, 2010 [Page = 8] > Internet-Draft Filtering BGP Customers. June = 2010 >=20 >=20 > 7. AS Path filtering >=20 > Filtering of customers announcements can be performed in many ways, > but the two primary methods are by filtering based upon > characteristics of the AS_PATH [TODO(WK): Check capitalization / > definition of "AS_PATH"] (AS Path filtering) and on the address > space. This section focuses on AS Path filtering. >=20 > 7.1. AS Path Uniformity >=20 > In many cases a provider will know that a customer is a stub network > and should only be announcing it's own AS number. This can be > enforced by applying an AS Path filter that only permits the > customer's AS number, possibly repeated multiple times. >=20 > This provides multiple levels of protections. It protects the > provider against the customer competing with the provider by selling > transit to other entities (and so violating their contract), it > protects against accidental leaks of routes from one provider to > another and also protects against accidental leaks of "private" AS > numbers[RFC1930]. >=20 > An example of a filter that only allows the customer AS is provided > in Appendix A.1. >=20 > 7.2. AS Path Length >=20 > While AS paths that are substantially longer than what is needed to > perform traffic engineering are not technically incorrect they may = be > symptoms of other issues. For example, if Customer A is multihomed > to both Provider B and Provider C (both large, well connected > providers), then Customer A can achieve traffic engineering by > prepending N+1 times, where N is the number of ASs between Provider = B > and Provider C. If Customer A is prepending many more times than > this, it is likely an error, or Customer A needs a little help > understanding how prepending works. >=20 > This is an example of where tagging these routes with a Warning > Community may help. >=20 > 7.3. Filter your own AS number >=20 > Depending on the size of a customer and how many other networks they > peer with, it may be difficult to determine what all AS numbers they > may be announcing to you. One thing that you can be certain of > though is that they should never be announcing your own AS to you. > While the standard BGP loop prevention algorithm *should* protect = you > from ever accepting an update with your own AS in it, it doesn't = hurt >=20 >=20 >=20 > Kumari Expires December 3, 2010 [Page = 9] > Internet-Draft Filtering BGP Customers. June = 2010 >=20 >=20 > to be extra careful (some implementations allow you to relax the > rule, and some providers use multiple AS numbers). >=20 > This can by done by simply crafting an AS_PATH regular expression > that macthes your Authonomous System number and denying any update > that contains this. >=20 > 7.4. Max-prefixes >=20 > The max-prefixes knob allows a provider to set a limit on how many > prefixes it will accept over a peering session. This can be a very > useful tool and can prevent a large range of issues. If a provider > knows that its customer will only announce a single prefix, it can > set max-prefix to one or two. If the customer accidenatlly > redistributes thier IGP into BGP, the max-prefixes limit will kick = in > and drop the peerin session. If the customer sends a large number = (a > few hundred or thousands), it is good practice to monitor how many > prefixes the customer sends, and set max-prefixes to be some > percentage higher than the current number. Some vendors allow > setting of two limits, a lower limit at which the router will log a > warning message, and a higher limit at which the session will be = shut > down. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Kumari Expires December 3, 2010 [Page = 10] > Internet-Draft Filtering BGP Customers. June = 2010 >=20 >=20 > 8. Address space filtering >=20 > 8.1. Deny own IP Space >=20 > In many cases customers are assigned address space by their = provider, > which often means that the customer is using address space that is > "similar" to space used by the provider. By "similar" we mean that > the customer is using a subnet (longer prefix) of the providers > space, or that a simple typing mistake could cause the customer to > accidentally use the same space as the provider. And example of = this > would be if the provider assigned 10.0.10.0/24 to the customer and > the customer accidentally configured 10.0.10.0/20 or 10.10.0.0/24. >=20 > It is a good practice to address network (and similar) = infrastructure > out of blocks set aside for this purpose. This allows the > application of access lists (or filters) to protects this > infrastructure and only allow access from authorized locations. By > applying BGP prefix list filters to prevent learning external routes > to ones own infrastructure space, one can avoid learning (and > following) hijacked space to devices outsides one's network. >=20 > 8.2. Deny Bogons >=20 > This section should be approached with dicipline! Bogons are > addresses that you know are not currently valid addresses for use on > the Internet. This includes addresses that have not yet been > allocated, Special Use Addresses ([RFC5735][RFC5156]), example > addresses and similar. It is simple to filter out announcements = with > these address, but if this is done, one MUST ensure that you keep up > to date with this. There have been amlost as many issues with Bogon > filters being deployed and not kept up to date as there have been > from not having Bogon filters at all. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Kumari Expires December 3, 2010 [Page = 11] > Internet-Draft Filtering BGP Customers. June = 2010 >=20 >=20 > 9. Acknowledgements >=20 > I would like to thank the IETF community for making me feel welcome = - > some of my best friendships have been a direct result of the IETF. = I > would like to thank Google for 20% time and allowing me to work in > this space. [This space for rent.] >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Kumari Expires December 3, 2010 [Page = 12] > Internet-Draft Filtering BGP Customers. June = 2010 >=20 >=20 > 10. Security Considerations >=20 > 10.1. Privacy >=20 > TODO(WK) -- Fill this in! >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Kumari Expires December 3, 2010 [Page = 13] > Internet-Draft Filtering BGP Customers. June = 2010 >=20 >=20 > 11. IANA Considerations >=20 > No action required. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Kumari Expires December 3, 2010 [Page = 14] > Internet-Draft Filtering BGP Customers. June = 2010 >=20 >=20 > 12. Normative References >=20 > [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, > selection, and registration of an Autonomous System = (AS)", > BCP 6, RFC 1930, March 1996. >=20 > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. >=20 > [RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, > April 2008. >=20 > [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", > BCP 153, RFC 5735, January 2010. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Kumari Expires December 3, 2010 [Page = 15] > Internet-Draft Filtering BGP Customers. June = 2010 >=20 >=20 > Author's Address >=20 > Warren Kumari > Google > 1600 Amphitheater Parkway > Mountain View, CA 94043 > US >=20 > Email: warren@kumari.net >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Kumari Expires December 3, 2010 [Page = 16] >=20 > _______________________________________________ > 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 warren@kumari.net Thu May 26 10:32:07 2011 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 812CAE0734 for ; Thu, 26 May 2011 10:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.179 X-Spam-Level: X-Spam-Status: No, score=-102.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuBE6+qlFhhj for ; Thu, 26 May 2011 10:32:06 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id B5BA9E073F for ; Thu, 26 May 2011 10:32:05 -0700 (PDT) Received: from [172.19.118.214] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 54B341B40340; Thu, 26 May 2011 13:32:04 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <243194.37888.qm@web31810.mail.mud.yahoo.com> Date: Thu, 26 May 2011 13:32:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <05BE8F7E-5203-4BB9-BCDF-F5E688707377@kumari.net> References: <243194.37888.qm@web31810.mail.mud.yahoo.com> To: David Barak X-Mailer: Apple Mail (2.1084) Cc: opsec@ietf.org Subject: Re: [OPSEC] ISP BGP filtering draft. X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 17:32:07 -0000 And, obviously enough I didn't mean to send the credentials to the list = :-) I have some folk doing construction at home today, and was horribly = distracted -- that'll teach me to send mail while not paying = attention.... I have just changed them and will *unicast* them to David.... W On May 25, 2011, at 4:50 PM, David Barak wrote: > I'll take a swing at it. >=20 > -David Barak >=20 > From: Warren Kumari ;=20 > To: ;=20 > Subject: [OPSEC] ISP BGP filtering draft.=20 > Sent: Wed, May 25, 2011 1:19:10 PM=20 >=20 > Hi all, >=20 > Many many moon ago (in Anaheim) I started writing a draft on "some = recommendations and suggestions regarding filtering BGP announcements = from customers." -- I started this with great intentions, but as with = many things, quickly got distracted.... >=20 > Anyway, as chair I feel it would probably be inappropriate for me to = continue writing it -- so, I have a partially completed draft that is = looking for a good home. > Is there anyone here that would be willing to take it over? If so, let = me know and I'll throw the XML at you=85 >=20 >=20 > I never polished it enough to post it, so here it is in all it's = glory^w horror. > W >=20 >=20 > = --------------------------------------------------------------------------= -------------------- >=20 >=20 >=20 > TBD W. = Kumari > Internet-Draft = Google > Intended status: Informational June 1, = 2010 > Expires: December 3, 2010 >=20 >=20 > Filtering BGP Customers. > draft-wkumari-isp-protocol-filtering >=20 > Abstract >=20 > This document provides some recommendations and suggestions = regarding > filtering BGP announcements from customers. >=20 > Status of this Memo >=20 > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. >=20 > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at http://datatracker.ietf.org/drafts/current/. >=20 > Internet-Drafts are draft documents valid for a maximum of six = months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." >=20 > This Internet-Draft will expire on December 3, 2010. >=20 > Copyright Notice >=20 > Copyright (c) 2010 IETF Trust and the persons identified as the > document authors. All rights reserved. >=20 > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with = respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. >=20 >=20 >=20 >=20 >=20 >=20 > Kumari Expires December 3, 2010 [Page = 1] > Internet-Draft Filtering BGP Customers. June = 2010 >=20 >=20 > Table of Contents >=20 > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . = 3 > 1.1. Requirements notation . . . . . . . . . . . . . . . . . . = 3 > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . = 4 > 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . = 5 > 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . = 6 > 5. Other recommendations, probably in a different doc . . . . . . = 7 > 6. Deny versus Warning . . . . . . . . . . . . . . . . . . . . . = 8 > 7. AS Path filtering . . . . . . . . . . . . . . . . . . . . . . = 9 > 7.1. AS Path Uniformity . . . . . . . . . . . . . . . . . . . . = 9 > 7.2. AS Path Length . . . . . . . . . . . . . . . . . . . . . . = 9 > 7.3. Filter your own AS number . . . . . . . . . . . . . . . . = 9 > 7.4. Max-prefixes . . . . . . . . . . . . . . . . . . . . . . . = 10 > 8. Address space filtering . . . . . . . . . . . . . . . . . . . = 11 > 8.1. Deny own IP Space . . . . . . . . . . . . . . . . . . . . = 11 > 8.2. Deny Bogons . . . . . . . . . . . . . . . . . . . . . . . = 11 > 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . = 12 > 10. Security Considerations . . . . . . . . . . . . . . . . . . . = 13 > 10.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . = 13 > 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . = 14 > 12. Normative References . . . . . . . . . . . . . . . . . . . . . = 15 > Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . = 16 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Kumari Expires December 3, 2010 [Page = 2] > Internet-Draft Filtering BGP Customers. June = 2010 >=20 >=20 > 1. Introduction >=20 > There have been numerous outages and security incidents caused by > poor filtering of customers by their providers. This lack of good > filtering allows customers to (accidentally or maliciously) announce > address space that they are not authorized to, to announce routes > from one provider to another (and so transit traffic from one > provider to another), to announce a large numbers of prefixes, as > well as many other things that could cause issues. While in most > instances it appears that the incident was accidental it is worth > keeping in mind that anything that can be done accidentally can also > be done maliciously, and so it prudent assume a malicious party and > act accordingly. >=20 > While this document contains many suggestions that apply to > connections between providers, it is primarily aimed at provider to > customer connections. The provider and customer terms are very > loosely defined, and mean different things to different people, so = we > will try to describe how we are using them in this document. A > "provider" is entity that is provides access to the Internet. It > usually carries "full routes", has multiple customers, is multihomed > and is often referred to as an ISP (Internet Service Provider). A > customer is an entity that gets access to the Internet through a > provider. Its primary business purpose is usually something other > than Internet Access, it may or may not be multihomed and usually > only announces a few prefixes -- "customers" are often a stub AS. >=20 > In order to aid with deployment of the described techniques, = examples > (and the language used by two vendors) are provided in the > Appendices. These should be viewed as examples only, and customized > before being used. >=20 > 1.1. Requirements notation >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Kumari Expires December 3, 2010 [Page = 3] > Internet-Draft Filtering BGP Customers. June = 2010 >=20 >=20 > 2. Terminology >=20 > WK: TODO: Figure out what terminology I am using. Maybe: Provider, > Customer, Bogon?!. >=20 > Bogon: A prefix that is known to not be used on the Internet, = either > because it is not allocated, or is a special use address such as > described in [RFC5735] >=20 > Provider: A provider is an entity that provides access to the > Internet (often called an ISP). In this document we are = assuming > that the provider communicates with its customers over BGP. >=20 > Customer: An entity that gets connectivity from a provider. > [TODO(WK): Fix / tighten up this definition. Definitions are > hard, lets go shopping.] >=20 > Hijack: A hijack is when an entity (accidentally or maliciously) > announces a resource that they are not authorized to. Examples = of > this would be a prefix (a prefix hijack) or an autonomous system > number (and AS hijack). >=20 > Warning Community: A community (chosen by that provider) that it > will use to mark suspicious announcements. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Kumari Expires December 3, 2010 [Page = 4] > Internet-Draft Filtering BGP Customers. June = 2010 >=20 >=20 > 3. Background >=20 > In recent years the Internet has become a critical resource for a > large number of companies. This has led a substantial increase in > multi-homing, often by customers that have very little experience > with BGP. In many cases the "network engineer" for the company is > also responsible for many other aspects of technology and so cannot > dedicate as much time and effort to the networking side as it > deserves. This can lead to engineers with only very rudimentary > knowledge of BGP performing the BGP configuration. >=20 > Even in organizations with very knowledgeable and experienced > engineers, mistakes can (and do) still happen - for this reason, = this > document suggests a "belt and suspenders" type design, so that > mistakes (or intentional attacks against the routing system) can be > mitigated / avoided altogether. >=20 > There are numerous efforts underway to address many of these issues > in a much more automated and secure manner, such as the work in the > SIDR (Secure Inter-Domain Routing) Working Group. This document > exists to provide a solution until these efforts are deployed, and > addresses some issues that they do not. >=20 > (TODO(WK): Consider inserting some examples like YT/Pakistan Tele, > AS7007 ?). >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Kumari Expires December 3, 2010 [Page = 5] > Internet-Draft Filtering BGP Customers. June = 2010 >=20 >=20 > 4. Recommendations >=20 > [TODO(WK): This is a place holder for all recommendations. For each > recommendations, list: Title. Brief description, Pros / Cons, > Applicability. >=20 > 1. Filter to deny your own / infrastructure space. >=20 > 2. Filter to deny your own AS(s) -- DONE >=20 > 3. Filter to only permit the customer space. >=20 > 4. Filter out bogons (TODO(WK): Insert *scary* text re: not keeping > bogons up to date. Consider just removing any mention of = this!). > -- DONE >=20 > 5. Filter to only allow the customer AS. >=20 > 6. Implement something like max-prefixes (TODO(WK): Figure out > vendor independent name) -- DONE >=20 > 7. Route-filter to only allow ASPATH of < 10 (TODO(WK): Pick a > number) -- Kinda >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Kumari Expires December 3, 2010 [Page = 6] > Internet-Draft Filtering BGP Customers. June = 2010 >=20 >=20 > 5. Other recommendations, probably in a different doc >=20 > 1. GTSM / BGP TTL hack. >=20 > 2. Juniper's "configured neighbors" prefix list thing. >=20 > 3. MD5's?! Point to KARP? something... >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Kumari Expires December 3, 2010 [Page = 7] > Internet-Draft Filtering BGP Customers. June = 2010 >=20 >=20 > 6. Deny versus Warning >=20 > While providers can craft filters that only allow customers to make = a > very restricted set of announcements, it is sometimes preferable to > craft slightly less draconian filters to allow a slightly larger set > of announcements and then follow up with the customer to check if > what they are announcing is what they intended to announce. > [TODO(WK): Add something about nipping problems in the bud and = making > things tidier.] >=20 > This can be accomplished by marking announcements that may indicate > the existence of an issue with a chosen community (which we will > refer to as the "Warning Community") and then monitoring for routes > tagged with that community. This can be done with in conjunction > with other measures, such as tagging the suspect announcements with > NO_ADVERTISE or NO_EXPORT, or placing them into a different routing > instance. In order for this technique to be effective a provider > should monitor for routes tagged with this warning community and = take > appropriate action >=20 > For example, if a provider has a policy that the longest prefix it > will accept from a customer is a /24 and it receives an announcement > for 192.0.2.0/25 it could accept the announcement and tag it with > NO_EXPORT and its Warning Community. A monitoring script would > detect these routes and generate an alert so that the provider could > contact the customer to determine if this was an error or if the > customer intended to make this announcement. This may be preferable > to just denying the announcement as it allows the root issue to be > resolved. By addressing the root issue (as opposed to just > mitigating symptoms) we end up with a cleaner network, which makes > future troubleshooting easier. Fixing the problem also decrease the > impact if the provider "drops filters" temporarily (for example > during troubleshooting). >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Kumari Expires December 3, 2010 [Page = 8] > Internet-Draft Filtering BGP Customers. June = 2010 >=20 >=20 > 7. AS Path filtering >=20 > Filtering of customers announcements can be performed in many ways, > but the two primary methods are by filtering based upon > characteristics of the AS_PATH [TODO(WK): Check capitalization / > definition of "AS_PATH"] (AS Path filtering) and on the address > space. This section focuses on AS Path filtering. >=20 > 7.1. AS Path Uniformity >=20 > In many cases a provider will know that a customer is a stub network > and should only be announcing it's own AS number. This can be > enforced by applying an AS Path filter that only permits the > customer's AS number, possibly repeated multiple times. >=20 > This provides multiple levels of protections. It protects the > provider against the customer competing with the provider by selling > transit to other entities (and so violating their contract), it > protects against accidental leaks of routes from one provider to > another and also protects against accidental leaks of "private" AS > numbers[RFC1930]. >=20 > An example of a filter that only allows the customer AS is provided > in Appendix A.1. >=20 > 7.2. AS Path Length >=20 > While AS paths that are substantially longer than what is needed to > perform traffic engineering are not technically incorrect they may = be > symptoms of other issues. For example, if Customer A is multihomed > to both Provider B and Provider C (both large, well connected > providers), then Customer A can achieve traffic engineering by > prepending N+1 times, where N is the number of ASs between Provider = B > and Provider C. If Customer A is prepending many more times than > this, it is likely an error, or Customer A needs a little help > understanding how prepending works. >=20 > This is an example of where tagging these routes with a Warning > Community may help. >=20 > 7.3. Filter your own AS number >=20 > Depending on the size of a customer and how many other networks they > peer with, it may be difficult to determine what all AS numbers they > may be announcing to you. One thing that you can be certain of > though is that they should never be announcing your own AS to you. > While the standard BGP loop prevention algorithm *should* protect = you > from ever accepting an update with your own AS in it, it doesn't = hurt >=20 >=20 >=20 > Kumari Expires December 3, 2010 [Page = 9] > Internet-Draft Filtering BGP Customers. June = 2010 >=20 >=20 > to be extra careful (some implementations allow you to relax the > rule, and some providers use multiple AS numbers). >=20 > This can by done by simply crafting an AS_PATH regular expression > that macthes your Authonomous System number and denying any update > that contains this. >=20 > 7.4. Max-prefixes >=20 > The max-prefixes knob allows a provider to set a limit on how many > prefixes it will accept over a peering session. This can be a very > useful tool and can prevent a large range of issues. If a provider > knows that its customer will only announce a single prefix, it can > set max-prefix to one or two. If the customer accidenatlly > redistributes thier IGP into BGP, the max-prefixes limit will kick = in > and drop the peerin session. If the customer sends a large number = (a > few hundred or thousands), it is good practice to monitor how many > prefixes the customer sends, and set max-prefixes to be some > percentage higher than the current number. Some vendors allow > setting of two limits, a lower limit at which the router will log a > warning message, and a higher limit at which the session will be = shut > down. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Kumari Expires December 3, 2010 [Page = 10] > Internet-Draft Filtering BGP Customers. June = 2010 >=20 >=20 > 8. Address space filtering >=20 > 8.1. Deny own IP Space >=20 > In many cases customers are assigned address space by their = provider, > which often means that the customer is using address space that is > "similar" to space used by the provider. By "similar" we mean that > the customer is using a subnet (longer prefix) of the providers > space, or that a simple typing mistake could cause the customer to > accidentally use the same space as the provider. And example of = this > would be if the provider assigned 10.0.10.0/24 to the customer and > the customer accidentally configured 10.0.10.0/20 or 10.10.0.0/24. >=20 > It is a good practice to address network (and similar) = infrastructure > out of blocks set aside for this purpose. This allows the > application of access lists (or filters) to protects this > infrastructure and only allow access from authorized locations. By > applying BGP prefix list filters to prevent learning external routes > to ones own infrastructure space, one can avoid learning (and > following) hijacked space to devices outsides one's network. >=20 > 8.2. Deny Bogons >=20 > This section should be approached with dicipline! Bogons are > addresses that you know are not currently valid addresses for use on > the Internet. This includes addresses that have not yet been > allocated, Special Use Addresses ([RFC5735][RFC5156]), example > addresses and similar. It is simple to filter out announcements = with > these address, but if this is done, one MUST ensure that you keep up > to date with this. There have been amlost as many issues with Bogon > filters being deployed and not kept up to date as there have been > from not having Bogon filters at all. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Kumari Expires December 3, 2010 [Page = 11] > Internet-Draft Filtering BGP Customers. June = 2010 >=20 >=20 > 9. Acknowledgements >=20 > I would like to thank the IETF community for making me feel welcome = - > some of my best friendships have been a direct result of the IETF. = I > would like to thank Google for 20% time and allowing me to work in > this space. [This space for rent.] >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Kumari Expires December 3, 2010 [Page = 12] > Internet-Draft Filtering BGP Customers. June = 2010 >=20 >=20 > 10. Security Considerations >=20 > 10.1. Privacy >=20 > TODO(WK) -- Fill this in! >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Kumari Expires December 3, 2010 [Page = 13] > Internet-Draft Filtering BGP Customers. June = 2010 >=20 >=20 > 11. IANA Considerations >=20 > No action required. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Kumari Expires December 3, 2010 [Page = 14] > Internet-Draft Filtering BGP Customers. June = 2010 >=20 >=20 > 12. Normative References >=20 > [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, > selection, and registration of an Autonomous System = (AS)", > BCP 6, RFC 1930, March 1996. >=20 > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. >=20 > [RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, > April 2008. >=20 > [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", > BCP 153, RFC 5735, January 2010. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Kumari Expires December 3, 2010 [Page = 15] > Internet-Draft Filtering BGP Customers. June = 2010 >=20 >=20 > Author's Address >=20 > Warren Kumari > Google > 1600 Amphitheater Parkway > Mountain View, CA 94043 > US >=20 > Email: warren@kumari.net >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Kumari Expires December 3, 2010 [Page = 16] >=20 > _______________________________________________ > 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