From cpignata@cisco.com Wed Jun 15 09:01:08 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 4DA1F11E8081 for ; Wed, 15 Jun 2011 09:01:08 -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=[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 8b8ig3UynbLX for ; Wed, 15 Jun 2011 09:01:07 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 55E2911E811F for ; Wed, 15 Jun 2011 09:01:07 -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 p5FG14NP006630; Wed, 15 Jun 2011 12:01:04 -0400 (EDT) Received: from [10.117.115.57] (rtp-cpignata-8918.cisco.com [10.117.115.57]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p5FG14Y7001570; Wed, 15 Jun 2011 12:01:04 -0400 (EDT) Message-ID: <4DF8D73F.7020803@cisco.com> Date: Wed, 15 Jun 2011 12:01:03 -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> <4DCCA138.2000908@cisco.com> <4DD5F510.5060405@gont.com.ar> In-Reply-To: <4DD5F510.5060405@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: Wed, 15 Jun 2011 16:01:08 -0000 Hi, Fernando, Thank you again for your responses and apologies for the delay, please see inline. On 5/20/2011 12:58 AM, Fernando Gont wrote: > 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. > In a way, the comment behind my comment was that if today optioned packets are already mostly blocked/filtered out, the value of a per-option analysis decreases. Dan Wing was kind enough to run his experiment with existing options (as opposed to unknown options), with these results: Without any IP options: # grep open normal-nop.out | wc 486 2430 29901 with just NOP, NOP, NOP, EOL: // --ip-options \x01\x01\x01\x00 # grep open ip-options-nop.out | wc 16 80 1099 Which is ~ 3.29 %. In a way, I sense that a potential good approach could be to explain that the current state might be that optioned packets are already blocked, and also (coupled with my comment #3) a way to interpret the detailed guideance is to either decide what to block or (much more likely) block everything and decide what, if anything, to allow. I am not aware of papers with more scientific analysis of success rates with existing options. But: --->8--- Data seems to indicate that there is a current widespread practice of blocking IPv4 optioned packets. There are various plausible approaches to minimize the potential negative effects of IPv4 optioned packets while allowing some options semantics. One approach is to allow for specific options that are expected or needed, and a default deny. A different approach is to deny unneeded options and a default allow. Yet a third option is to allow for end-to-end semantics by ignoring options and treating packets as unoptioned while in transit. The current state tends to support the first or third approaches as more realistic. --->8--- > >> 2. It assumes that devices (i.e., routers) have the capability to filter >> IP optioned packets with the per-option-value granularity. This might >> not generally be the case. I think this point should also be clarified. >> >> 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. > Note there is a lateral mention to this in RFC 6192: o Similarly, some deployments may choose to drop all IP optioned packets. Others may need to loosen the constraint to allow for protocols that require IP optioned packets such as the Resource Reservation Protocol (RSVP). The design trade-off is that dropping all IP optioned packets protects the router from attacks that leverage malformed options, as well as attacks that rely on the slow-path processing (i.e., software processing path) of IP optioned packets. For network deployments where the protocols do not use IP options, the filter is simpler to design in that it can drop all packets with any IP option set. However, for networks utilizing protocols relying on IP options, the filter to identify the legitimate packets is more complex. If the filter is not designed correctly, it could result in the inadvertent blackholing of traffic for those protocols. This document does not include filter configurations for IP optioned packets; additional explanations regarding the filtering of packets based on the IP options they contain can be found in [IP-OPTIONS-FILTER]. > I disagree with this assessment. The document assesses the impact of > filtering different options. If you're fine with the impact of filtering > all ip-optioned packets, then you don't need to filter at the > granularity of per-option-type. > > I guess what I was thinking is that an operator could think "what do I lose if I block this option" and do that exercise for every option, or "what do I gain by allowing", and this is where the (apparent) current practice has a role in deciding this. > >> Additionally, >> >> 4. There may be more than "filter" versus "not-filter" options. Some >> platforms support ignoring IP options (i.e., acting as if an IP Optioned >> packet did not have options), and that is a potential recommendation. > > IIRC, this is already mentioned in the document. > I could not find it. Could you please point to the specific para? I think this is quite important because I think this is another practice often seen as the best option. > > [....] >> 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. > See text I crafted above. Very rough, but hopefully a good enough starting point. > > >> 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? > http://tools.ietf.org/html/rfc6192#section-1 Modern router architecture design maintains a strict separation of forwarding and router control plane hardware and software. The There are possible things like ICMP generation and IP option processing on general use processors in Line Cards, as opposed to LC forwarding ASICs. It is a punt to a slower path. But not necessarily a punt to the RP -- there may not be "main processor" but "main processors" depending on the context, and abstracting from actual architectures helps the document be more time invariant. > > >> For EOO and NOOP, the advise is to: >> >> No security issues are known for this option, other than the general >> security implications of IP options discussed in Section 2. >> >> But I think that the general implications are the most important part of >> this document but are minimal. > > hence? > Well, Section 2 is the default gateway for general implications applicable to all options but IMHO inadequately covers that subject. To be more precise, it does not cover it. Section 2 does not have general security implications of IP options. It seems to contain a guide as to what options are (semantics and syntax) but not security implications. Hence are missing but are one of the main topics of this I-D. > > >> The document does not describe what the resulting disposition of a >> packet with many options should be. > > Will fix this. > > Thanks. > >> 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, -- Carlos. > Thanks! > > Best regards, From cpignata@cisco.com Wed Jun 15 10:43:42 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 BEFBB21F85FE for ; Wed, 15 Jun 2011 10:43:42 -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=[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 j+ce6NN3nv8k for ; Wed, 15 Jun 2011 10:43:37 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 7AEE421F85FC for ; Wed, 15 Jun 2011 10:43:37 -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 p5FHhWKc016367; Wed, 15 Jun 2011 13:43:32 -0400 (EDT) Received: from [10.117.115.57] (rtp-cpignata-8918.cisco.com [10.117.115.57]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p5FHhWHv000895; Wed, 15 Jun 2011 13:43:32 -0400 (EDT) Message-ID: <4DF8EF43.7040601@cisco.com> Date: Wed, 15 Jun 2011 13:43:31 -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> <4DCCA138.2000908@cisco.com> <4DD5F510.5060405@gont.com.ar> In-Reply-To: <4DD5F510.5060405@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: Wed, 15 Jun 2011 17:43:42 -0000 Fernando, Please find some comments, prefaced with "CP:", on the detailed option handling part of this document. Hopefully this is clear and useful: 4. Advice on handling of specific IP Options CP: It is not clear what is the order of the options listed in this doc. It is not that of RFC791, not that of IANA's ip-parameters, not increasing option numbers. Consequently it is a bit hard to follow or to see if how complete or extensive the list is, at least to me. CP: I also think that a table summarizing the points here would be priceless. Finally, a nit: I'd keep the TOC to two levels only (4.x and not 4.x.y), for clarity. 4.1. End of Option List (Type = 0) 4.1.4. Operational/interoperability impact if blocked Packets containing any IP options are likely to include an End of Option List. Therefore, if packets containing this option are filtered, it is very likely that legitimate traffic is filtered. CP: I am not sure that IP optioned packets are "likely" to include EOOL, it depends on alignment. Also "very likely that legitimate traffic is filtered" can be proved. Finally see below. 4.1.5. Advice Do not filter packets containing this option. CP: I would say "Do not filter packets because of they containing this option". The current advise reads as "if this option is present, do not filter" as opposed to "do not filter because of this one". Because this advice can conflict with other "do filter" advise. This is a NOOP from a filtering standpoint, other than the generic treatment of optioned packets. 4.2.3. Threats No security issues are known for this option, other than the general security implications of IP options discussed in Section 2. CP: It may make sense to have a Section dedicated only to these general security implications. 4.3. Loose Source and Record Route (LSRR) (Type = 131) Additionally, packets containing a combination of LSRR and SSRR options should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). CP: Is the intent to list variations of malformed IP Options packet as well? Like no options after EOOL, and such? If so, a single statement as a security consideration should catch-all for that. CP: Should that send a parameter problem, and is that also an attack vector? 4.5. Record Route (Type = 7) 4.5.1. Uses This option provides a means to record the route that a given packet follows. CP: This option is also often used by NOCs to force a packet to take a slow forwarding path to debug and troubleshoot. Many traceroute versions allow for RR, and that's why it is used in this manner. 4.12. DoD Basic Security Option (Type = 130) CP: Note how this name from (Historic) RFC 1108 differs from that of RFC 791 and ip-parameters. Some options from are missing. By way of summary, I think that the change to most possitively impact this document would be to have generic assessment and advise followed by a table summarizing all of Section 4. Thanks, -- Carlos.