From root@core3.amsl.com Thu Aug 20 03:30:01 2009 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4406E3A7009; Thu, 20 Aug 2009 03:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090820103001.4406E3A7009@core3.amsl.com> Date: Thu, 20 Aug 2009 03:30:01 -0700 (PDT) Cc: opsec@ietf.org Subject: [OPSEC] I-D Action:draft-ietf-opsec-ip-security-01.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 10:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF. Title : Security Assessment of the Internet Protocol version 4 Author(s) : F. Gont Filename : draft-ietf-opsec-ip-security-01.txt Pages : 73 Date : 2009-08-20 This document contains a security assessment of the IETF specifications of the Internet Protocol version 4, and of a number of mechanisms and policies in use by popular IPv4 implementations. It is based on the results of a project carried out by the UK's Centre for the Protection of National Infrastructure (CPNI). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsec-ip-security-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-opsec-ip-security-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-20032953.I-D@ietf.org> --NextPart-- From fernando@gont.com.ar Thu Aug 20 03:36:30 2009 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6954C3A7007 for ; Thu, 20 Aug 2009 03:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=1.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hG7GZchGj3io for ; Thu, 20 Aug 2009 03:36:29 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 74E403A7006 for ; Thu, 20 Aug 2009 03:36:28 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 9598B6B660B for ; Thu, 20 Aug 2009 07:36:30 -0300 (ART) Received: from [192.168.0.151] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n7KAaPhS020872; Thu, 20 Aug 2009 07:36:26 -0300 Message-ID: <4A8D272A.6050804@gont.com.ar> Date: Thu, 20 Aug 2009 07:36:26 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "'opsec@ietf.org'" X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Thu, 20 Aug 2009 07:36:29 -0300 (ART) Subject: [OPSEC] [Fwd: New Version Notification for draft-ietf-opsec-ip-security-01] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 10:36:30 -0000 Hello, folks, I have posted a revision of the ip-security I-D which addresses only part of the feedback received from Andrew Yourtchenko. I'm still in the process of tweaking the I-D to address the thorough review of Andrew Yourtchenko and others. It would be great if, in the mean time, I could get more feedback on this document. Thanks! Kind regards, Fernando -------- Original Message -------- Subject: New Version Notification for draft-ietf-opsec-ip-security-01 Date: Thu, 20 Aug 2009 03:29:53 -0700 (PDT) From: IETF I-D Submission Tool To: fernando@gont.com.ar A new version of I-D, draft-ietf-opsec-ip-security-01.txt has been successfuly submitted by Fernando Gont and posted to the IETF repository. Filename: draft-ietf-opsec-ip-security Revision: 01 Title: Security Assessment of the Internet Protocol version 4 Creation_date: 2009-08-20 WG ID: opsec Number_of_pages: 73 Abstract: This document contains a security assessment of the IETF specifications of the Internet Protocol version 4, and of a number of mechanisms and policies in use by popular IPv4 implementations. It is based on the results of a project carried out by the UK's Centre for the Protection of National Infrastructure (CPNI). The IETF Secretariat. -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From joelja@bogus.com Thu Aug 20 15:52:38 2009 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 011823A6B7F for ; Thu, 20 Aug 2009 15:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmr-SYP50i1u for ; Thu, 20 Aug 2009 15:52:37 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id F23A43A6AE4 for ; Thu, 20 Aug 2009 15:52:36 -0700 (PDT) Received: from [209.97.124.250] ([209.97.124.250]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id n7KMqZxW060735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Aug 2009 22:52:36 GMT (envelope-from joelja@bogus.com) Message-ID: <4A8DD3A4.5070508@bogus.com> Date: Thu, 20 Aug 2009 15:52:20 -0700 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.22 (X11/20090804) MIME-Version: 1.0 To: Fernando Gont References: <4A8D272A.6050804@gont.com.ar> In-Reply-To: <4A8D272A.6050804@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Thu, 20 Aug 2009 22:52:37 +0000 (UTC) Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] [Fwd: New Version Notification for draft-ietf-opsec-ip-security-01] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 22:52:38 -0000 Thanks fernando, joel Fernando Gont wrote: > Hello, folks, > > I have posted a revision of the ip-security I-D which addresses only > part of the feedback received from Andrew Yourtchenko. > > I'm still in the process of tweaking the I-D to address the thorough > review of Andrew Yourtchenko and others. > > It would be great if, in the mean time, I could get more feedback on > this document. > > Thanks! > > Kind regards, > Fernando > > > > > -------- Original Message -------- > Subject: New Version Notification for draft-ietf-opsec-ip-security-01 > Date: Thu, 20 Aug 2009 03:29:53 -0700 (PDT) > From: IETF I-D Submission Tool > To: fernando@gont.com.ar > > > A new version of I-D, draft-ietf-opsec-ip-security-01.txt has been > successfuly submitted by Fernando Gont and posted to the IETF repository. > > Filename: draft-ietf-opsec-ip-security > Revision: 01 > Title: Security Assessment of the Internet Protocol version 4 > Creation_date: 2009-08-20 > WG ID: opsec > Number_of_pages: 73 > > Abstract: > This document contains a security assessment of the IETF > specifications of the Internet Protocol version 4, and of a number of > mechanisms and policies in use by popular IPv4 implementations. It > is based on the results of a project carried out by the UK's Centre > for the Protection of National Infrastructure (CPNI). > > > > > The IETF Secretariat. > > > > From fernando@gont.com.ar Fri Aug 21 01:56:40 2009 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A4323A6914 for ; Fri, 21 Aug 2009 01:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.715 X-Spam-Level: X-Spam-Status: No, score=-2.715 tagged_above=-999 required=5 tests=[AWL=0.885, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dC+fleYrEm3T for ; Fri, 21 Aug 2009 01:56:39 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 82B563A67C1 for ; Fri, 21 Aug 2009 01:56:37 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id A2FEE6B65F6; Fri, 21 Aug 2009 05:56:41 -0300 (ART) Received: from [192.168.0.151] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n7L8ubT6027043; Fri, 21 Aug 2009 05:56:38 -0300 Message-ID: <4A8E6144.6040700@gont.com.ar> Date: Fri, 21 Aug 2009 05:56:36 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: ayourtch@cisco.com References: <20090129201501.C10D83A687E@core3.amsl.com> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Fri, 21 Aug 2009 05:56:41 -0300 (ART) Cc: opsec@ietf.org Subject: Re: [OPSEC] review for draft-ietf-opsec-ip-security-01 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 08:56:40 -0000 Hello, Andrew, Thanks so much for the thorough review! (and sorry for the "delay" in my response...) I'll respond to those comments that I think that need some clarification. (the rest of them have been applied ot the last rev of the document). > [Page 8]: > > "3.3. TOS ..." -> RFC1349 is obsoleted by the RFC2474 (DSCP), so this > chapter needs a rewrite. Are you arguing that I should eliminate the TOS discussion? Or that DSCP should be put into the main header, and the discussion of TOS be relegated to a somewhat minor section? > [Page 9]: > > "3.4. Total Length..." > > The section talks about the corner cases with discrepancy of length > value in the header and the actual packet length, but does not discuss > any potential interaction with EMTU_R limitations in case there are any. mmm... not sure what you mean. Could you clarify this one? > 9kb limit - the document should have some specific references to the > stacks that have it. Also, probably the reference to the RFC1122 (at > least for the terminological definition of the EMTU_R?) Rather than stating that there are stacks that *have* this limitation, the I-D states that virtually all stacks *can* reassemble datagrams of at least 9KB. > [Page 11]: > > "3.5.2. Possible security improvements" > > TODO - discussion of a quality of IP ID of being able to provide a > "fingerprint" of the remote host. You mean you could fingerprint the host by "figuring out" the algorithm used to set the IP ID, or what? > [Page 17]: > > "Fingerprinting the physical device from which the packets originate" - > > orphan word sequence. Not sure what you mean.... > [Page 24]: > > "Enforce a limit on the maximum number of options" - to me this looks a > bit of a dangerous recommendation in this form, as it would cause > arbitrary hard limits set by middle devices, resulting in creation of > "IP Option MTU". (Not that anyone is adding a lot of IP options anyway > these days, so it is more a theoretical nitpick :-) Well, just pick a very large limit that will never limit anything, and that's it. > [Page 31]: > > LSRR, SSRR and RR options - can their restrictions be combined as much > as possible ? To me they look largely similar, and the repetition is a > cause for potential mistakes, IMHO. I agree that repetition is a potential source for mistakes, and that conceptually speaking, they *could* be combined. However, I think it's useful to be able to read whatever you need to know about each option in a single section. And that of having "repeated" stuff allows me to use "descriptive "acronyms" for each option ("LSRR.length" vs. "SSRR.length", etc.). Please let me know if you feel strongly about this change. > [Page 42]: > > Man in the middle threat mention for DSCP: is this the only field for > which the MITM attacks are a concern ? I reviewed the DSCP section, but found no discussion of MITM attacks. Could you quote the text you're referring to? > [Page 51]: > > The sequence# check: should here be a reference to the section 3.4.3 of > rfc2406 as a pointer to what constitutes the "valid sequence#" ? Would just a pointer (reference) address your comment? > Step three: should there be more specifics about some randomization for > the process of dropping ? Hints? (Argue something like "it's recommended that fragments are flushed on a random basis" or the like?) > Also - this algorithm omits the frequently used NAT-T (essentially IPSEC > over UDP/4500) Could this really be incorporated in the algorithm? > [Page 52]: > > "virtually impossible" - I'd replace this with "harder" :) And, as the > MITM is mentioned for DSCP, I'd not make the task easier for IPSEC > specifically :) the algorighm which is supposed to protect IPSEC should > be able to resist the on-path attacker. Well, I don't think you could protect IPsec traffic that relies on fragmentation. If a have access to the IPsec fragments, I could simply forge fragments that would lead to a failure in the reassembly process. > [Page 53]: > > "Additionally, given that many middle-boxes such as firewalls create > state according to the contents of the first fragment of a given > packet, it is best that, in the event an end-system receives > overlapping fragments, it honors the information contained in the > fragment that was received first." > > received first if there was a box behind the middlebox that has > reordered the packets afterwards, or if there was no such box ? :-) Not sure what you mean. > If the two received fragments contain conflicting information, we do not > have enough info to discern which of the two is "correct", IMHO. So, we > should mark the corresponding packet as "bad", Isn't this more aggressive than what the existing text recommends? > treat the reassembly as > usual, and then drop it with an auditable event. (not drop immediately > in order to avoid the DoS where colliding fragments would be dropped and > cause the accumulation of the remaining fragments till the max > reassembly timeout occurs). I agree with this "remaining fragments thing". However, obvious question: how long should we wait? This might close one door of attack, but open another one.... > [Page 54]: > > sending with high precedence values: ingress filtering ? ingress-filtering based on the IP addresses, you mean? > (Also, with the DSCP/ToS duality, worth doublechecking on how does it > translate to real forwarding devices?) mmm... not sure what you mean. > [Page 55]: > > Address resolution: the passage about storing the packets for a long > time on the router - isn't it something that should be directly > discouraged, precisely because of its big impact ? What specific behavior would you recommend? > [Page 56]: > > "Dropping packets": > > should be mentioned that all dropped packets should be *counted* > somewhere ? I think I forgot to include the "this should be logged" here. But will do in the next rev. (As you may have seen, I added a "this should be logged" statement in every passage of the I-D that recommends to drop a packet). Thoughts? It would be great if we could converge on all the above items, so that I can address these remaining issues in te next rev of the I-D. Thanks again for your feedback! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From ayourtch@cisco.com Fri Aug 21 07:19:43 2009 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DE8D3A6926 for ; Fri, 21 Aug 2009 07:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-5slSSJgz7m for ; Fri, 21 Aug 2009 07:19:41 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 91B953A68B4 for ; Fri, 21 Aug 2009 07:19:41 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n7LEFu6M027796; Fri, 21 Aug 2009 16:15:56 +0200 (CEST) Received: from dhcp-peg3-vl30-144-254-7-153.cisco.com (dhcp-peg3-vl30-144-254-7-153.cisco.com [144.254.7.153]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n7LEFthq011543; Fri, 21 Aug 2009 16:15:55 +0200 (CEST) Date: Fri, 21 Aug 2009 16:16:01 +0200 (CEST) From: Andrew Yourtchenko X-X-Sender: ayourtch@zippy.stdio.be To: Fernando Gont In-Reply-To: <4A8E6144.6040700@gont.com.ar> Message-ID: References: <20090129201501.C10D83A687E@core3.amsl.com> <4A8E6144.6040700@gont.com.ar> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: opsec@ietf.org Subject: Re: [OPSEC] review for draft-ietf-opsec-ip-security-01 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ayourtch@cisco.com List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 14:19:43 -0000 Hello Fernando, On Fri, 21 Aug 2009, Fernando Gont wrote: > Hello, Andrew, > > Thanks so much for the thorough review! (and sorry for the "delay" in my > response...) > > I'll respond to those comments that I think that need some > clarification. (the rest of them have been applied ot the last rev of > the document). > > > >> [Page 8]: >> >> "3.3. TOS ..." -> RFC1349 is obsoleted by the RFC2474 (DSCP), so this >> chapter needs a rewrite. > > Are you arguing that I should eliminate the TOS discussion? Or that DSCP No, this byte still remains in IP header, so there should be a discussion that touches the security implications of it. > should be put into the main header, and the discussion of TOS be > relegated to a somewhat minor section? > If I understand the relation of the RFCs correctly, we should be discussing the semantics of this byte in terms of RFC2474, not RFC1349. However, from the security point of view, since we do not know how a particular end node interprets it, it may be even a good idea to look at the relationship between both of the semantics. The current text implies the ToS/Precedence is the current standards definition - which is AFAIK not the case. > > >> [Page 9]: >> >> "3.4. Total Length..." >> >> The section talks about the corner cases with discrepancy of length >> value in the header and the actual packet length, but does not discuss >> any potential interaction with EMTU_R limitations in case there are any. > > mmm... not sure what you mean. Could you clarify this one? > It was one long paragraph, so the comment below :) > > >> 9kb limit - the document should have some specific references to the >> stacks that have it. Also, probably the reference to the RFC1122 (at >> least for the terminological definition of the EMTU_R?) > > Rather than stating that there are stacks that *have* this limitation, > the I-D states that virtually all stacks *can* reassemble datagrams of > at least 9KB. Re-reading it, it looks ok - it sounds more like a back-up for the reasoning for a given stack to be prepared to receive the datagrams of 9K that were fragmented by the other side, so it's ok. > > > >> [Page 11]: >> >> "3.5.2. Possible security improvements" >> >> TODO - discussion of a quality of IP ID of being able to provide a >> "fingerprint" of the remote host. > > You mean you could fingerprint the host by "figuring out" the algorithm > used to set the IP ID, or what? > I used this technique several times to understand whether the particular packet was sent by a host, or by someone sending a packet on its behalf. > > > >> [Page 17]: >> >> "Fingerprinting the physical device from which the packets originate" - >> >> orphan word sequence. > > Not sure what you mean.... > Ok, that was just a very long title. Visually it looked as part of the text. > > >> [Page 24]: >> >> "Enforce a limit on the maximum number of options" - to me this looks a >> bit of a dangerous recommendation in this form, as it would cause >> arbitrary hard limits set by middle devices, resulting in creation of >> "IP Option MTU". (Not that anyone is adding a lot of IP options anyway >> these days, so it is more a theoretical nitpick :-) > > Well, just pick a very large limit that will never limit anything, and > that's it. "never limit anything" for a particular environment that I see that I pick for. And if you send me the options you can never be sure whether I am going to process them or I am going to persistently drop them. Rate-limiting alone should be fine - as it allows the options still to be processed when not under load, whereas the upper bound puts a hard-stop. > > > >> [Page 31]: >> >> LSRR, SSRR and RR options - can their restrictions be combined as much >> as possible ? To me they look largely similar, and the repetition is a >> cause for potential mistakes, IMHO. > > I agree that repetition is a potential source for mistakes, and that > conceptually speaking, they *could* be combined. However, I think it's > useful to be able to read whatever you need to know about each option in > a single section. And that of having "repeated" stuff allows me to use > "descriptive "acronyms" for each option ("LSRR.length" vs. > "SSRR.length", etc.). Please let me know if you feel strongly about this > change. > Ok, let's see. Copypasting from the draft. valid LSRR: LSRR.Length >= 3 LSRR.Offset + LSRR.Length < IHL *4 LSRR.Pointer >= 4 LSRR.Pointer % 4 == 0 empty LSRR: LSRR.Pointer > LSRR.Length can write LSRR: LSRR.Length - LSRR.Pointer >= 3 valid SSRR: SSRR.Length >= 3 SSRR.Offset + SSRR.Length < IHL *4 SSRR.Pointer >= 4 SSRR.Pointer % 4 == 0 empty SSRR: SSRR.Pointer > SSRR.Length can write SSRR: SSRR.Length - SSRR.Pointer >=3 valid RR: RR.Length >= 3 RR.Offset + RR_Length < IHL *4 RR.Pointer >= 3 <------------- wrong ? RR.Pointer % 4 == 0 full RR: RR.Pointer > RR.Length additional RR validity check: RR.Pointer - RR.Length >= 3 <---- valid if Pointer is bigger than length + 3 ? The RR ones that I marked with the arrow are interesting: "The pointer field is relative to this option, with the minimum legal value being 4. Therefore, the following check should be performed: RR.Pointer >= 3 " -----> So this looks like a bug, the value should be 4, not 3 ? " The option is full if: RR.Pointer > RR.Length If the option is full, the datagram should be forwarded without further processing of this option. If not, the following check should be performed before writing any route data into the option: RR.Pointer - RR.Length >= 3 If the packet does not pass this check, the packet should be considered in error, and therefore should be silently dropped. " this translates into: if (RR.pointer > RR.length) { // full, forward with no recording } else if (RR.pointer >= 3 + RR.Length) { // never reached. And the pointer beyond the length is wrong anyway. } So, these two should be the case in point :) And, I think if I had to code this, I'd group the first four conditionals for all the RR-like options into: /* Return TRUE if RR-like options (LSRR, SSRR, RR) pass the sanity checks */ bool sane_rrX_option(int ihl, int length, int offset, int pointer) { return (length >= 3) && (offset+length < ihl*4) && (pointer >= 4) && (pointer % 4 == 0); } and then call this from the option processing where needed. Currently the reader has to first spot that the checks are pretty much the same, then write them down close by to verify this = extra cognitive load for the reader. And, appears, for the writer as well :-) So, yes, I'm rather strongly in favour of joining whatever can be joined. > > >> [Page 42]: >> >> Man in the middle threat mention for DSCP: is this the only field for >> which the MITM attacks are a concern ? > > I reviewed the DSCP section, but found no discussion of MITM attacks. > Could you quote the text you're referring to? http://tools.ietf.org/html/draft-ietf-opsec-ip-security-00: " However, if this moderate congestion turned into heavy congestion, routers should switch to drop packets, regardless of whether the packets have the ECT codepoint set or not. A number of other threats could arise if an attacker was a man in the middle (i.e., was in the middle of the path the packets travel to get to the destination host). For a detailed discussion of those cases, we urge the reader to consult Section 16 of RFC 3168. " ^------ ECN/DSCP and ToS (if the ToS is there at all) should definitely sit somewhere together IMHO. > > > >> [Page 51]: >> >> The sequence# check: should here be a reference to the section 3.4.3 of >> rfc2406 as a pointer to what constitutes the "valid sequence#" ? > > Would just a pointer (reference) address your comment? yes, reference is ideal. > > > >> Step three: should there be more specifics about some randomization for >> the process of dropping ? > > Hints? (Argue something like "it's recommended that fragments are > flushed on a random basis" or the like?) > Probably. One question about this algorithm in general - is this something that works and tested in real life with code, or it is something we think may work if implemented ? If the former, there should be references to the implementation, if the latter - maybe this deserves a separate doc, and a a good scrutiny of IPSEC people ? > > > >> Also - this algorithm omits the frequently used NAT-T (essentially IPSEC >> over UDP/4500) > > Could this really be incorporated in the algorithm? > That's what I wonder. :-) I really think now that this piece should be looked at by the IPSEC people, even if to say "We don't need this because we never fragment". Realistically, that's pretty much the case, because if you need to reassemble the fragments before decryption, you're playing in a much lower league performance-wise. So, this text might be redundant altogether. > > > >> [Page 52]: >> >> "virtually impossible" - I'd replace this with "harder" :) And, as the >> MITM is mentioned for DSCP, I'd not make the task easier for IPSEC >> specifically :) the algorighm which is supposed to protect IPSEC should >> be able to resist the on-path attacker. > > Well, I don't think you could protect IPsec traffic that relies on > fragmentation. If a have access to the IPsec fragments, I could simply > forge fragments that would lead to a failure in the reassembly process. > Ok. So I have a growing conclusion that then the more complex reassembly algorithm would be useless then. Either use the system-standard one, or don't fragment, period. Less bugs :) > > >> [Page 53]: >> >> "Additionally, given that many middle-boxes such as firewalls create >> state according to the contents of the first fragment of a given >> packet, it is best that, in the event an end-system receives >> overlapping fragments, it honors the information contained in the >> fragment that was received first." >> >> received first if there was a box behind the middlebox that has >> reordered the packets afterwards, or if there was no such box ? :-) > > Not sure what you mean. > I meant that I do not really see the logic here. You have a middlebox that forwards the "fragmentA", then "fragmentB". On the way to you they get reordered. You keep the "fragment B". But according to your statement the firewall keeps the state according to "fragmentA". So we're doing exactly the opposite of what you intended to say ? > > >> If the two received fragments contain conflicting information, we do not >> have enough info to discern which of the two is "correct", IMHO. So, we >> should mark the corresponding packet as "bad", > > Isn't this more aggressive than what the existing text recommends? > to an extent. But it's also more predictable - you get packet lost, not corrupted. Else if you reassemble, either the upper layer detects the error (so we still have the same problem, but at an upper layer), or it does not - at which point we are unsure whether there is no error because the upper layer check is weak, or because we actually reconstructed the original packet.. OTOH with the "drop if suspicious" idea, there's an easy DoS vector... You're right. Scratch this. > >> treat the reassembly as >> usual, and then drop it with an auditable event. (not drop immediately >> in order to avoid the DoS where colliding fragments would be dropped and >> cause the accumulation of the remaining fragments till the max >> reassembly timeout occurs). > > I agree with this "remaining fragments thing". However, obvious > question: how long should we wait? This might close one door of attack, > but open another one.... same as for regular reassembly. The fact that you have two colliding fragments, does not matter - you could as well receive two spoofed fragments for different IP IDs, and there you can't be sure if they are spoofed or not. So I'd treat these cases functionally the same. > > > > >> [Page 54]: >> >> sending with high precedence values: ingress filtering ? > > ingress-filtering based on the IP addresses, you mean? > Yes, I mean that this is not the business of the host to deal with this - especially that there's no real recommendation: "yeah. They say you should not drop this. but bad stuff is easy to do. So, be bear aware!" > > >> (Also, with the DSCP/ToS duality, worth doublechecking on how does it >> translate to real forwarding devices?) > > mmm... not sure what you mean. > i.e. how much of a problem it really is, and whether it is something that was shown practically possible, or is more a theory. > > >> [Page 55]: >> >> Address resolution: the passage about storing the packets for a long >> time on the router - isn't it something that should be directly >> discouraged, precisely because of its big impact ? > > What specific behavior would you recommend? > This is not about recommending, but rather about the practical behaviour. AFAIK, the router would in practice throw such packets down the drain. Or there exist a real-world routing device that actually holds all the packets for an unresolved L2 adjacency ? > > > >> [Page 56]: >> >> "Dropping packets": >> >> should be mentioned that all dropped packets should be *counted* >> somewhere ? > > I think I forgot to include the "this should be logged" here. But will > do in the next rev. (As you may have seen, I added a "this should be > logged" statement in every passage of the I-D that recommends to drop a > packet). > > Thoughts? > > It would be great if we could converge on all the above items, so that I > can address these remaining issues in te next rev of the I-D. > Sure! Let me know if this reply helps. cheers, andrew From joelja@bogus.com Wed Aug 26 13:55:48 2009 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7590328C158 for ; Wed, 26 Aug 2009 13:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qydb4K2a4p+M for ; Wed, 26 Aug 2009 13:55:47 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 717043A6D2B for ; Wed, 26 Aug 2009 13:55:47 -0700 (PDT) Received: from [209.97.124.176] ([209.97.124.176]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id n7QKtpta013068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 26 Aug 2009 20:55:52 GMT (envelope-from joelja@bogus.com) Message-ID: <4A95A152.9080303@bogus.com> Date: Wed, 26 Aug 2009 13:55:46 -0700 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "'opsec@ietf.org'" X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Wed, 26 Aug 2009 20:55:52 +0000 (UTC) Subject: [OPSEC] ipv6 ingress filtering... X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 20:55:48 -0000 I have been following the thread on ipv6@ietf.org on the subject of routing loop attacks using ipv6 tunnels http://www.ietf.org/mail-archive/web/ipv6/current/threads.html#10800 and it occurs to me that the corpus of knowledge on ipv6 ingress filtering may be somewhat incomplete. There is this document: http://www.cymru.com/Bogons/ipv6.txt that is in a format and with authors that look fairly familiar. there is this document: http://ietfreport.isoc.org/idref/draft-dupont-ipv6-ingress-filtering/ which appears consigned to history rfc 2827 and 3704 are the canonical documents in this space, rfc 3178 deals with some limitations of ingress filters being imposed. threats that become feasible due to the inposition of transition technologies were not a consideration of the later three documents. Thoughts are appreciated. joel From fernando@gont.com.ar Fri Aug 28 19:18:31 2009 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EB923A6864 for ; Fri, 28 Aug 2009 19:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.1 X-Spam-Level: X-Spam-Status: No, score=-3.1 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPKL7kJarVOu for ; Fri, 28 Aug 2009 19:18:29 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id ED0753A6A8F for ; Fri, 28 Aug 2009 19:18:27 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 5C9816B6812; Fri, 28 Aug 2009 23:18:36 -0300 (ART) Received: from [192.168.0.136] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n7T2IHog029201; Fri, 28 Aug 2009 23:18:18 -0300 Message-ID: <4A988FE4.8090909@gont.com.ar> Date: Fri, 28 Aug 2009 23:18:12 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ayourtch@cisco.com References: <20090129201501.C10D83A687E@core3.amsl.com> <4A8E6144.6040700@gont.com.ar> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Fri, 28 Aug 2009 23:18:36 -0300 (ART) Cc: opsec@ietf.org Subject: Re: [OPSEC] review for draft-ietf-opsec-ip-security-01 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2009 02:18:31 -0000 Hello, Andrew, >>> "3.3. TOS ..." -> RFC1349 is obsoleted by the RFC2474 (DSCP), so this >>> chapter needs a rewrite. [....] > If I understand the relation of the RFCs correctly, we should be > discussing the semantics of this byte in terms of RFC2474, not RFC1349. > However, from the security point of view, since we do not know how a > particular end node interprets it, it may be even a good idea to look at > the relationship between both of the semantics. > > The current text implies the ToS/Precedence is the current standards > definition - which is AFAIK not the case. Agreed. I will swap the DSCP and TOS sections... and will think a little bit about the relationship of these two semantics. >>> 9kb limit - the document should have some specific references to the >>> stacks that have it. Also, probably the reference to the RFC1122 (at >>> least for the terminological definition of the EMTU_R?) >> >> Rather than stating that there are stacks that *have* this limitation, >> the I-D states that virtually all stacks *can* reassemble datagrams of >> at least 9KB. > > Re-reading it, it looks ok - it sounds more like a back-up for the > reasoning for a given stack to be prepared to receive the datagrams of > 9K that were fragmented by the other side, so it's ok. Good. No changes here, then. >>> [Page 11]: >>> >>> "3.5.2. Possible security improvements" >>> >>> TODO - discussion of a quality of IP ID of being able to provide a >>> "fingerprint" of the remote host. >> >> You mean you could fingerprint the host by "figuring out" the algorithm >> used to set the IP ID, or what? > > I used this technique several times to understand whether the particular > packet was sent by a host, or by someone sending a packet on its behalf. Isn't this already addressed by the "count number of systems behind a NAT" and "fingerprinting physical devices" stuff? >>> [Page 24]: >>> >>> "Enforce a limit on the maximum number of options" - to me this looks a >>> bit of a dangerous recommendation in this form, as it would cause >>> arbitrary hard limits set by middle devices, resulting in creation of >>> "IP Option MTU". (Not that anyone is adding a lot of IP options anyway >>> these days, so it is more a theoretical nitpick :-) >> >> Well, just pick a very large limit that will never limit anything, and >> that's it. > > "never limit anything" for a particular environment that I see that I > pick for. And if you send me the options you can never be sure whether I > am going to process them or I am going to persistently drop them. Well, this limit is not meant to knock down legitimate uses. e.g., do you see any real traffic with more than four IP options? That aside, this may already be the case with packet scrubbers deployed on the path to destination... > Rate-limiting alone should be fine - as it allows the options still to > be processed when not under load, whereas the upper bound puts a hard-stop. You mean you'd rate limit the processing of packets that contain options? I'm not necessarily arguing against this, but this would sort of open the door to a new attack: just send packets with options to DoS any traffic that carries options. Whereas imposing a limit on the number of options would hurt the traffic that's using a "surprisingly" large number of options. I might argue that one might want to do both. >>> [Page 31]: >>> >>> LSRR, SSRR and RR options - can their restrictions be combined as much >>> as possible ? To me they look largely similar, and the repetition is a >>> cause for potential mistakes, IMHO. >> >> I agree that repetition is a potential source for mistakes, and that >> conceptually speaking, they *could* be combined. However, I think it's >> useful to be able to read whatever you need to know about each option in >> a single section. And that of having "repeated" stuff allows me to use >> "descriptive "acronyms" for each option ("LSRR.length" vs. >> "SSRR.length", etc.). Please let me know if you feel strongly about this >> change. >> > > Ok, let's see. Copypasting from the draft. > > valid LSRR: > LSRR.Length >= 3 > LSRR.Offset + LSRR.Length < IHL *4 > LSRR.Pointer >= 4 > LSRR.Pointer % 4 == 0 > empty LSRR: > LSRR.Pointer > LSRR.Length > can write LSRR: > LSRR.Length - LSRR.Pointer >= 3 > > valid SSRR: > SSRR.Length >= 3 > SSRR.Offset + SSRR.Length < IHL *4 > SSRR.Pointer >= 4 > SSRR.Pointer % 4 == 0 > empty SSRR: > SSRR.Pointer > SSRR.Length > can write SSRR: > SSRR.Length - SSRR.Pointer >=3 > > valid RR: > RR.Length >= 3 > RR.Offset + RR_Length < IHL *4 > RR.Pointer >= 3 <------------- wrong ? Yes, this is a bug. It should be: RR.Pointer >= 4 > RR.Pointer % 4 == 0 > full RR: > RR.Pointer > RR.Length > additional RR validity check: > RR.Pointer - RR.Length >= 3 <---- valid if Pointer is bigger than > length + 3 ? Good grief! It seems I screw up when I converted the nice PDF into the IETF I-D. It should be RR.Length - RR.Pointer >=3 It means that there is room to store a 4-byte IP address. (the check looks ugly because RR.Pointer starts with "1" ("1" when it points to the beginning of the option, and 4 when it points to the beginning of the option area) > The RR ones that I marked with the arrow are interesting: > > "The pointer field is relative to this option, with the minimum legal > value being 4. Therefore, the following check should be performed: > > RR.Pointer >= 3 > " > > -----> So this looks like a bug, the value should be 4, not 3 ? Yes. > and then call this from the option processing where needed. > Currently the reader has to first spot that the checks are pretty much > the same, then write them down close by to verify this = extra cognitive > load for the reader. And, appears, for the writer as well :-) > > So, yes, I'm rather strongly in favour of joining whatever can be joined. Ok. how do you propose to do this? For LSRR and SSRR, this would be easy: just document the checks for one of them, and include a pointer to those checks in the other option. For the RR option, one could say "implement the same checks, but do not enforce the SSRR.Length - SSRR.Pointer >= 3 check". But that would look ugly. (and, if you had to code these, you'd need to indicate whether its a XSRR option or a RR option, because of this last check that applies only to XSRR options). Thoughts? >>> [Page 42]: >>> >>> Man in the middle threat mention for DSCP: is this the only field for >>> which the MITM attacks are a concern ? [....] > http://tools.ietf.org/html/draft-ietf-opsec-ip-security-00: > > " However, if this moderate congestion turned into heavy congestion, > routers should switch to drop packets, regardless of whether the > packets have the ECT codepoint set or not. > > A number of other threats could arise if an attacker was a man in the > middle (i.e., was in the middle of the path the packets travel to get > to the destination host). For a detailed discussion of those cases, > we urge the reader to consult Section 16 of RFC 3168. > " > ^------ > > ECN/DSCP and ToS (if the ToS is there at all) should definitely sit > somewhere together IMHO. The MITM attack is mentioned only for ECN because MITM attacks *are* mentioned in the ECN spec. I'm more of the idea to delete MITM discussions, rather than adding more of it. e.g., we'd have to add stuff on the IP ID discussion (if there's a MITM, an attacker could spoof packets with the same IP ID, and cause reassembly to fail), an attacker could rewrite the contents of the IP source route options, etc. I'd personally avoid getting into this. :-) Thoughts? >>> [Page 51]: >>> >>> The sequence# check: should here be a reference to the section 3.4.3 of >>> rfc2406 as a pointer to what constitutes the "valid sequence#" ? >> >> Would just a pointer (reference) address your comment? > > yes, reference is ideal. Good. Will do. >>> Step three: should there be more specifics about some randomization for >>> the process of dropping ? >> >> Hints? (Argue something like "it's recommended that fragments are >> flushed on a random basis" or the like?) > > Probably. One question about this algorithm in general - is this > something that works and tested in real life with code, or it is > something we think may work if implemented ? If the former, there should > be references to the implementation, if the latter - maybe this deserves > a separate doc, and a a good scrutiny of IPSEC people ? The separation of reassembly into separate protocols has not been implemented, AFAIK. So it would be "the latter". However, this document *has* been reviewed by Ran Atkinson (author of RFC 2401). Further thoughts? >>> Also - this algorithm omits the frequently used NAT-T (essentially IPSEC >>> over UDP/4500) >> >> Could this really be incorporated in the algorithm? > > That's what I wonder. :-) I would argue against this one. You cannot separate this traffic into a different queue, because you might receive a non-first fragment first. And, IIRC, linux sends the last fragment *first*. > I really think now that this piece should be > looked at by the IPSEC people, even if to say "We don't need this > because we never fragment". > > Realistically, that's pretty much the case, because if you need to > reassemble the fragments before decryption, you're playing in a much > lower league performance-wise. So, this text might be redundant altogether. Well, the bottom-line of this document is "you should not rely on fragmentation.... but if you do, here's how you could improve the security of the process". >>> [Page 52]: >>> >>> "virtually impossible" - I'd replace this with "harder" :) And, as the >>> MITM is mentioned for DSCP, I'd not make the task easier for IPSEC >>> specifically :) the algorighm which is supposed to protect IPSEC should >>> be able to resist the on-path attacker. >> >> Well, I don't think you could protect IPsec traffic that relies on >> fragmentation. If a have access to the IPsec fragments, I could simply >> forge fragments that would lead to a failure in the reassembly process. > > Ok. So I have a growing conclusion that then the more complex reassembly > algorithm would be useless then. Either use the system-standard one, or > don't fragment, period. Less bugs :) One might argue that you could allow IPsec traffic from a single host (by means of a fw) and allow non-IPsec traffic from anywhere else. In this case, the algorithm might be of help. >>> [Page 53]: >>> >>> "Additionally, given that many middle-boxes such as firewalls create >>> state according to the contents of the first fragment of a given >>> packet, it is best that, in the event an end-system receives >>> overlapping fragments, it honors the information contained in the >>> fragment that was received first." >>> >>> received first if there was a box behind the middlebox that has >>> reordered the packets afterwards, or if there was no such box ? :-) >> >> Not sure what you mean. >> > > I meant that I do not really see the logic here. You have a middlebox > that forwards the "fragmentA", then "fragmentB". On the way to you they > get reordered. You keep the "fragment B". But according to your > statement the firewall keeps the state according to "fragmentA". So > we're doing exactly the opposite of what you intended to say ? If a host receives fragmentA (first) and fragmentB (second) and they overlap, they should use the contents of fragmentA. (the referenced RFCs should how you could bypass a firewall if the host uses fragmentB instead of fragmentA). Does this make sense now? >>> If the two received fragments contain conflicting information, we do not >>> have enough info to discern which of the two is "correct", IMHO. So, we >>> should mark the corresponding packet as "bad", >> >> Isn't this more aggressive than what the existing text recommends? > > to an extent. But it's also more predictable - you get packet lost, not > corrupted. Else if you reassemble, either the upper layer detects the > error (so we still have the same problem, but at an upper layer), or it > does not - at which point we are unsure whether there is no error > because the upper layer check is weak, or because we actually > reconstructed the original packet.. > > OTOH with the "drop if suspicious" idea, there's an easy DoS vector... > You're right. Scratch this. So... should keep the next "as is"? >>> treat the reassembly as >>> usual, and then drop it with an auditable event. (not drop immediately >>> in order to avoid the DoS where colliding fragments would be dropped and >>> cause the accumulation of the remaining fragments till the max >>> reassembly timeout occurs). >> >> I agree with this "remaining fragments thing". However, obvious >> question: how long should we wait? This might close one door of attack, >> but open another one.... > > same as for regular reassembly. The fact that you have two colliding > fragments, does not matter - you could as well receive two spoofed > fragments for different IP IDs, and there you can't be sure if they are > spoofed or not. So I'd treat these cases functionally the same. Thinking out loud: One might argue that if there are two many incomplete fragments in the queue, one should flush them all (or at least quite a few of them) -- if not, an attacker could simply trash the whole IP ID space. Then legitimate fragmented traffic would complete the reassembly processs with the spoofed fragments, thus leaving a (later arriving) legitimate fragment in the fragment queue, which would keep the IP-ID space trashed. Thoughts? >>> [Page 54]: >>> >>> sending with high precedence values: ingress filtering ? >> >> ingress-filtering based on the IP addresses, you mean? > > Yes, I mean that this is not the business of the host to deal with this > - especially that there's no real recommendation: "yeah. They say you > should not drop this. but bad stuff is easy to do. So, be bear aware!" I will add a note on ingress filtering here. >>> (Also, with the DSCP/ToS duality, worth doublechecking on how does it >>> translate to real forwarding devices?) >> >> mmm... not sure what you mean. > > i.e. how much of a problem it really is, and whether it is something > that was shown practically possible, or is more a theory. Are you referring to TOS (specifically), or TOS+Precedence? >>> [Page 55]: >>> >>> Address resolution: the passage about storing the packets for a long >>> time on the router - isn't it something that should be directly >>> discouraged, precisely because of its big impact ? >> >> What specific behavior would you recommend? > > This is not about recommending, but rather about the practical > behaviour. AFAIK, the router would in practice throw such packets down > the drain. Or there exist a real-world routing device that actually > holds all the packets for an unresolved L2 adjacency ? A unix-like box operating as a router would do this, IIRC. Nevertheless, there are too many devices around. And some might be doing this -- hence the discussion. (it *is* noted that it's a usual implementation approach that the device drop the packet that elicited the address resolution before engaging in arp). Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From rfc-editor@rfc-editor.org Thu Aug 27 15:36:21 2009 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CB9628C383; Thu, 27 Aug 2009 15:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.372 X-Spam-Level: X-Spam-Status: No, score=-16.372 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rX-2Yr+1F9wL; Thu, 27 Aug 2009 15:36:20 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 8A97828C364; Thu, 27 Aug 2009 15:36:20 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 87CEA310E1B; Thu, 27 Aug 2009 15:36:01 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090827223601.87CEA310E1B@bosco.isi.edu> Date: Thu, 27 Aug 2009 15:36:01 -0700 (PDT) X-Mailman-Approved-At: Fri, 28 Aug 2009 20:13:29 -0700 Cc: opsec@ietf.org, rfc-editor@rfc-editor.org Subject: [OPSEC] RFC 5635 on Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 22:36:21 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5635 Title: Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF) Author: W. Kumari, D. McPherson Status: Informational Date: August 2009 Mailbox: warren@kumari.net, danny@arbor.net Pages: 15 Characters: 30232 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-opsec-blackhole-urpf-04.txt URL: http://www.rfc-editor.org/rfc/rfc5635.txt Remote Triggered Black Hole (RTBH) filtering is a popular and effective technique for the mitigation of denial-of-service attacks. This document expands upon destination-based RTBH filtering by outlining a method to enable filtering by source address as well. This memo provides information for the Internet community. This document is a product of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From joelja@bogus.com Fri Aug 28 20:18:43 2009 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40F733A6ACC for ; Fri, 28 Aug 2009 20:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvTQgZVEPKPE for ; Fri, 28 Aug 2009 20:18:42 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 6BE9D28C0E9 for ; Fri, 28 Aug 2009 20:17:53 -0700 (PDT) Received: from [192.168.1.131] (c-98-234-104-156.hsd1.ca.comcast.net [98.234.104.156]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id n7T3Hvvh088358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 29 Aug 2009 03:17:58 GMT (envelope-from joelja@bogus.com) Message-ID: <4A989DE1.7080200@bogus.com> Date: Fri, 28 Aug 2009 20:17:53 -0700 From: joel jaeggli User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: opsec@ietf.org References: <20090827223601.87CEA310E1B@bosco.isi.edu> In-Reply-To: <20090827223601.87CEA310E1B@bosco.isi.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Sat, 29 Aug 2009 03:17:58 +0000 (UTC) Subject: Re: [OPSEC] RFC 5635 on Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2009 03:18:43 -0000 I just wanted to thanks, it took a while but we published our first rfc under the new charter. It's been an educational experience for me, but it couldn't have been done without the contribution and forbearance of the working group participants. joel rfc-editor@rfc-editor.org wrote: > A new Request for Comments is now available in online RFC libraries. > > > RFC 5635 > > Title: Remote Triggered Black Hole Filtering > with Unicast Reverse Path Forwarding (uRPF) > Author: W. Kumari, D. McPherson > Status: Informational > Date: August 2009 > Mailbox: warren@kumari.net, > danny@arbor.net > Pages: 15 > Characters: 30232 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-opsec-blackhole-urpf-04.txt > > URL: http://www.rfc-editor.org/rfc/rfc5635.txt > > Remote Triggered Black Hole (RTBH) filtering is a popular and > effective technique for the mitigation of denial-of-service attacks. > This document expands upon destination-based RTBH filtering by > outlining a method to enable filtering by source address as well. This > memo provides information for the Internet community. > > This document is a product of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF. > > > INFORMATIONAL: This memo provides information for the Internet community. > It does not specify an Internet standard of any kind. Distribution of > this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > USC/Information Sciences Institute > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec >