From joelja@bogus.com Mon Jun 1 10:27:18 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 5074B3A6A5D for ; Mon, 1 Jun 2009 10:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRJFTo7zjQh8 for ; Mon, 1 Jun 2009 10:27:17 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 573D03A71D3 for ; Mon, 1 Jun 2009 10:26:08 -0700 (PDT) Received: from [209.97.124.84] ([209.97.124.84]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id n51HPK2d084379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Jun 2009 17:26:02 GMT (envelope-from joelja@bogus.com) Message-ID: <4A240EFB.9080700@bogus.com> Date: Mon, 01 Jun 2009 10:25:15 -0700 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: "'opsec@ietf.org'" , Joe Abley References: <4A0E9D88.4050001@bogus.com> In-Reply-To: <4A0E9D88.4050001@bogus.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94.2/9411/Mon Jun 1 14:35:19 2009 on nagasaki.bogus.com X-Virus-Status: Clean Subject: [OPSEC] FYI 75th IETF 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: Mon, 01 Jun 2009 17:27:18 -0000 FYI, as we have no new business we have not asked for a WG time slot for IETF 75. It is my intention to be there so I will be available for an informal meeting if there is work to discuss. joel Joel Jaeggli wrote: > Note, we're operating under the following timeline for scheduling for > IETF 75: > > May 25, Monday - Cutoff date for requests to schedule Working > Group meetings and for preliminary BOF proposals to ADs at 17:00 > PDT (24:00 UTC/GMT). > > June 19, Friday - Preliminary agenda published for comment. > > July 1, Wednesday - Cutoff date for requests to reschedule > Working Group and BOF meetings 17:00 PDT (24:00 UTC/GMT). > > July 6, Monday - Final agenda to be published. > > July 15, Wednesday - Draft Working Group agendas due by 17:00 PT > (24:00 UTC/GMT). > > July 20, Monday - Revised Working Group agendas due by 17:00 PT > (24:00 UTC/GMT). > > At present there's little point in scheduling a meeting as we have > neither iterations of news drafts nor newwork to bring to the meeting. > I'm open to suggestions however. most recent document action was > draft-ietf-opsec-blackhole-urpf was put in the queue with our AD for > IESG review. > > Thanks > Joel > > From fernando.gont.netbook.win@gmail.com Mon Jun 1 23:13:29 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 834263A6876; Mon, 1 Jun 2009 23:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.53 X-Spam-Level: X-Spam-Status: No, score=-1.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] 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 GurYTANP-dkt; Mon, 1 Jun 2009 23:13:28 -0700 (PDT) Received: from mail-qy0-f114.google.com (mail-qy0-f114.google.com [209.85.221.114]) by core3.amsl.com (Postfix) with ESMTP id 61F073A679F; Mon, 1 Jun 2009 23:13:28 -0700 (PDT) Received: by qyk12 with SMTP id 12so928026qyk.29 for ; Mon, 01 Jun 2009 23:13:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=DC4uBODSWbZI0f6Fjw5Cqb+e3ekhs5he0uRVFq0BPyY=; b=KoB4uUz65nEld3+Is62lCe8XHm+aWK3RXoC3cNn/lDPXmsESu9mt5YE5Mu5X0yRk/B kT+H7zOsUkzFwOJibGgj4xLw4w7sV59eVGmoVw9n3cJ0GY1YyrdtyLEz7rJZUxTpvXfI jtWlEUGnERPWLyf7Zp0wfOatvWM9MZdHd3jAM= 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:openpgp:content-type :content-transfer-encoding; b=QVZQS4qb62NL6da+cCwMAcZFe6EGYDnsNOuAVjPICrJ2sal7rc15GBvVTzqC/LlZQ4 GNOoNZm0SgSjsen1RUZTXAQDCC5D5JGAyAwxyKAkcRhSa+Lm75Ic6EQU9AMQ4usFyoZZ YOPw3L9+EWzGViPXgJtj+PcCFuisoqmcEhNg4= Received: by 10.224.2.199 with SMTP id 7mr6481398qak.336.1243923205390; Mon, 01 Jun 2009 23:13:25 -0700 (PDT) Received: from ?192.168.0.151? (129-130-17-190.fibertel.com.ar [190.17.130.129]) by mx.google.com with ESMTPS id 2sm713559qwi.33.2009.06.01.23.13.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 01 Jun 2009 23:13:23 -0700 (PDT) Sender: Fernando Gont Message-ID: <4A24626E.90805@gont.com.ar> Date: Mon, 01 Jun 2009 20:21:18 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Lars Eggert References: <49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu> <49E39119.1060902@gont.com.ar> <49E3A88F.9060301@gont.com.ar> <49E3ABC0.1050601@isi.edu> <49E3B9BF.1060901@gont.com.ar> <49E3BED9.1030701@isi.edu> <49E4D257.40504@gont.com.ar> <49E4E233.9040609@earthlink.net> <49E5F36D.7020808@earthlink.net> <49EE1873.1090907@gont.com.ar> <88ACD16A-1137-4E55-871F-8F0C992D7A63@nokia.com> In-Reply-To: <88ACD16A-1137-4E55-871F-8F0C992D7A63@nokia.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: opsec@ietf.org, tcpm@ietf.org Subject: Re: [OPSEC] [tcpm] draft-gont-tcp-security 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: Tue, 02 Jun 2009 06:13:29 -0000 Lars Eggert wrote: >> P.S.: Is there any specific proposal/advice to pursue this effort? >> There's has been some talk about tcpm vs opsec, but so far it is not >> clear to me how to proceed here. > > if the IETF decides to work on this, I believe TCPM would be the most > appropriate group, given that that's where the TCP expertise is. I'm > fully OK with doing this in cooperation with OPSEC, maybe via a joint WG > last call or other means, if they desire this. Any plans on how to proceed? So far we have version -00 of the individual submission, but it's not clear to me how to proceed.... > One question: If the IETF decides to publish a document in this space, > and if you decide to offer draft-gont-tcp-security as a starting point > for this work, are the UK CNPI and you as the author OK with the IETF WG > obtaining change control? The WG consensus process would likely lead to > changes compared to the current version, probably even significant changes. Both UK CPNI and me are OK with the document being modified to reflect IETF consensus. However, we do expect me to continue as the document author, and UK CPNI to continue as the author's affiliation (there's nothing unusual with this... but considering that strictly speaking once a document is accepted by a WG the author may be changed, I'm just clarifying that while neither UK CPNI nor me have problems with the document reflecting WG consensus, we do expect the author (Fernando Gont) and the author's affiliation (UK CPNI) to remain "as is"). 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 joelja@bogus.com Wed Jun 3 13:49:02 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 C51003A6782; Wed, 3 Jun 2009 13:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHgZqch8mqR5; Wed, 3 Jun 2009 13:49:01 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id C68633A6AA8; Wed, 3 Jun 2009 13:48:40 -0700 (PDT) Received: from [209.97.124.84] ([209.97.124.84]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id n53KlqTT049645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Jun 2009 20:48:34 GMT (envelope-from joelja@bogus.com) Message-ID: <4A26E173.6040802@bogus.com> Date: Wed, 03 Jun 2009 13:47:47 -0700 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Fernando Gont References: <49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu> <49E39119.1060902@gont.com.ar> <49E3A88F.9060301@gont.com.ar> <49E3ABC0.1050601@isi.edu> <49E3B9BF.1060901@gont.com.ar> <49E3BED9.1030701@isi.edu> <49E4D257.40504@gont.com.ar> <49E4E233.9040609@earthlink.net> <49E5F36D.7020808@earthlink.net> <49EE1873.1090907@gont.com.ar> <88ACD16A-1137-4E55-871F-8F0C992D7A63@nokia.com> <4A24626E.90805@gont.com.ar> In-Reply-To: <4A24626E.90805@gont.com.ar> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94.2/9418/Wed Jun 3 12:18:15 2009 on nagasaki.bogus.com X-Virus-Status: Clean Cc: opsec@ietf.org, tcpm@ietf.org, Lars Eggert Subject: Re: [OPSEC] [tcpm] draft-gont-tcp-security 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, 03 Jun 2009 20:49:02 -0000 It's a tough question. In part I think the answer is up to you, I think there's some understanding on the part of tcpm that if this work were to progress on a standards track that tcpm (no opsec) is the place for that to happen. That said there's also some question as what sort of general recommendations about hardening tcp would actually be consider acceptable (in narrow use cases a lot more of them may well be). The diligent blacksmith knows that hardening a tool also makes it more brittle... The result of any such effort is likely to be greatly different than what you have today. An alternative track would have the document headed for informational status either as a working group document or as indivdual submission with an understanding of what sort of advice is provided and who should consider it and the limitations of implmentation based on it's recomendations. It still think exposure to a working group is very important and useful in this context, as a purely independant submission it's simply documentary evidence of the uk cpni's effort's at documenting some percieved flaws in tcp and recomned mitigation strategy which is useful but not dramatically better than putting it on a website. Fernando Gont wrote: > Lars Eggert wrote: > >>> P.S.: Is there any specific proposal/advice to pursue this effort? >>> There's has been some talk about tcpm vs opsec, but so far it is not >>> clear to me how to proceed here. >> if the IETF decides to work on this, I believe TCPM would be the most >> appropriate group, given that that's where the TCP expertise is. I'm >> fully OK with doing this in cooperation with OPSEC, maybe via a joint WG >> last call or other means, if they desire this. > > Any plans on how to proceed? So far we have version -00 of the > individual submission, but it's not clear to me how to proceed.... > > > >> One question: If the IETF decides to publish a document in this space, >> and if you decide to offer draft-gont-tcp-security as a starting point >> for this work, are the UK CNPI and you as the author OK with the IETF WG >> obtaining change control? The WG consensus process would likely lead to >> changes compared to the current version, probably even significant changes. > > Both UK CPNI and me are OK with the document being modified to reflect > IETF consensus. However, we do expect me to continue as the document > author, and UK CPNI to continue as the author's affiliation (there's > nothing unusual with this... but considering that strictly speaking once > a document is accepted by a WG the author may be changed, I'm just > clarifying that while neither UK CPNI nor me have problems with the > document reflecting WG consensus, we do expect the author (Fernando > Gont) and the author's affiliation (UK CPNI) to remain "as is"). > > Thanks! > > Kind regards, From root@core3.amsl.com Fri Jun 5 09:45: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 5C9523A6B2B; Fri, 5 Jun 2009 09:45: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: <20090605164501.5C9523A6B2B@core3.amsl.com> Date: Fri, 5 Jun 2009 09:45:01 -0700 (PDT) Cc: opsec@ietf.org Subject: [OPSEC] I-D Action:draft-ietf-opsec-blackhole-urpf-04.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: Fri, 05 Jun 2009 16:45: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 : Remote Triggered Black Hole filtering with uRPF Author(s) : W. Kumari, D. McPherson Filename : draft-ietf-opsec-blackhole-urpf-04.txt Pages : 18 Date : 2009-06-05 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsec-blackhole-urpf-04.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-blackhole-urpf-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-06-05094449.I-D@ietf.org> --NextPart-- From joelja@bogus.com Mon Jun 8 21:34:05 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 20EAF3A68F4 for ; Mon, 8 Jun 2009 21:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[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 5UcvmpWjfirL for ; Mon, 8 Jun 2009 21:34:04 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 190713A6768 for ; Mon, 8 Jun 2009 21:34:03 -0700 (PDT) Received: from [192.168.1.233] (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 n594Y6YX071714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 9 Jun 2009 04:34:07 GMT (envelope-from joelja@bogus.com) Message-ID: <4A2DE63B.5070300@bogus.com> Date: Mon, 08 Jun 2009 21:34:03 -0700 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: "'opsec@ietf.org'" X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94.2/9440/Mon Jun 8 19:30:04 2009 on nagasaki.bogus.com X-Virus-Status: Clean Subject: [OPSEC] FYI draft-ietf-opsec-blackhole-urpf-04 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: Tue, 09 Jun 2009 04:34:05 -0000 Another iteration of this draft after last call has been posted. you many peruse it at your leisure. The diff located here: http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-opsec-blackhole-urpf-04.txt shows the changes which are minor for the most part, except for the very strong disclaimer now in 4.0... Before enabling uRPF (in any mode), it is vital that you fully understand the implications of doing so: - Strict mode will cause the router to drop all ingress traffic if the best path back to the source address of the traffic is not the interface from which the traffic was received. Asymetric routing will cause strict mode uRPF to drop legitimate traffic. - Loose mode causes the router to check if a route for the source address of the traffic exists. This may also cause legitimate traffic to be discarded. It is hoped that in the future, vendors will implement a "DoS- mitigation" mode in addition to the Loose and Strict modes -- in this mode, the uRPF check will only fail if the next-hop for the source of the packet is a discard interface. From fernando.gont.netbook.win@gmail.com Tue Jun 9 00:32:35 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 309D23A698D; Tue, 9 Jun 2009 00:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHJWI50KU+gn; Tue, 9 Jun 2009 00:32:34 -0700 (PDT) Received: from mail-qy0-f111.google.com (mail-qy0-f111.google.com [209.85.221.111]) by core3.amsl.com (Postfix) with ESMTP id 0CB093A68EC; Tue, 9 Jun 2009 00:32:33 -0700 (PDT) Received: by qyk9 with SMTP id 9so233716qyk.29 for ; Tue, 09 Jun 2009 00:32:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=KYEMqfOea6pUREOtZo7Sx1JsCkUqwlLkzlHqvfj+RbY=; b=OZZuIn6VmzqGfJ0SKgqk2xzaEq4pomIIwYqXF13Ioq7m/E1IiOD2qMB7by5SZSPiSn o0BVJ1a89QWSZYuA1ajJ9X7fjlaPStDx/YowHLxqTjctDpGJg7PXI7+8JBuPd6Yvb8uf 3cFFEMJlPPUPaKnddzszFqiPaLYA8niilFOE8= 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:openpgp:content-type :content-transfer-encoding; b=Z9/GzxmVLFxTvyxhd/Z2AnLfgfgYRmw5vlh1Ko1zSrLMyWphgn+1TuoU+7GZmlPb9R ykIzokCVXvct99h8s/+WF5+66CLlvDL39cKwDuMqYzda3vDpcXXWpbSWo9X+0jxXD5oZ PG5tyqcaOK5Xe2OP21e9/NJfijPb2KZqYQo80= Received: by 10.224.60.203 with SMTP id q11mr7718504qah.245.1244532756811; Tue, 09 Jun 2009 00:32:36 -0700 (PDT) Received: from ?192.168.0.151? (148-82-231-201.fibertel.com.ar [201.231.82.148]) by mx.google.com with ESMTPS id 8sm981208qwj.34.2009.06.09.00.32.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Jun 2009 00:32:34 -0700 (PDT) Sender: Fernando Gont Message-ID: <4A2E1008.4060303@gont.com.ar> Date: Tue, 09 Jun 2009 04:32:24 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Joel Jaeggli References: <49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu> <49E39119.1060902@gont.com.ar> <49E3A88F.9060301@gont.com.ar> <49E3ABC0.1050601@isi.edu> <49E3B9BF.1060901@gont.com.ar> <49E3BED9.1030701@isi.edu> <49E4D257.40504@gont.com.ar> <49E4E233.9040609@earthlink.net> <49E5F36D.7020808@earthlink.net> <49EE1873.1090907@gont.com.ar> <88ACD16A-1137-4E55-871F-8F0C992D7A63@nokia.com> <4A24626E.90805@gont.com.ar> <4A26E173.6040802@bogus.com> In-Reply-To: <4A26E173.6040802@bogus.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: opsec@ietf.org, tcpm@ietf.org Subject: Re: [OPSEC] [tcpm] draft-gont-tcp-security 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: Tue, 09 Jun 2009 07:32:35 -0000 Hello, Joel, Comments in-line... > It's a tough question. In part I think the answer is up to you, I think > there's some understanding on the part of tcpm that if this work were to > progress on a standards track that tcpm (no opsec) is the place for that > to happen. Ok. My proposal is, that unless there's any alternative proposal, I'd like this document to be pursued as "Informational" within opsec. > That said there's also some question as what sort of general > recommendations about hardening tcp would actually be consider > acceptable (in narrow use cases a lot more of them may well be). > > The diligent blacksmith knows that hardening a tool also > makes it more brittle... This is a nice quote, but... I'd like examples. e.g., start discussing about which specific hardening proposal makes TCP more brittle. > The result of any such effort is likely to be greatly different than > what you have today. That's not a problem. > An alternative track would have the document headed for informational > status either as a working group document or as indivdual submission > with an understanding of what sort of advice is provided and who should > consider it and the limitations of implmentation based on it's > recomendations. It still think exposure to a working group is very > important and useful in this context, Ok. Good. As I mentioned, unless somebody else comes up with an alternative proposal, I'd like the document to target "Informational" at opsec. I guess that at some point tcpm may want to work on some of the stuff in the document on a piecemeal basis. > as a purely independant submission > it's simply documentary evidence of the uk cpni's effort's at > documenting some percieved flaws in tcp and recomned mitigation strategy > which is useful but not dramatically better than putting it on a website. -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@ISI.EDU Tue Jun 9 06:43:25 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 A6FD13A6912; Tue, 9 Jun 2009 06:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=0.435, 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 reyBbxFSvylM; Tue, 9 Jun 2009 06:43:24 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id ACB553A659B; Tue, 9 Jun 2009 06:43:24 -0700 (PDT) Received: from [192.168.1.46] (pool-71-105-84-152.lsanca.dsl-w.verizon.net [71.105.84.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n59DgSiA014546; Tue, 9 Jun 2009 06:42:29 -0700 (PDT) Message-ID: <4A2E66C3.6040701@isi.edu> Date: Tue, 09 Jun 2009 06:42:27 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Fernando Gont References: <49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu> <49E39119.1060902@gont.com.ar> <49E3A88F.9060301@gont.com.ar> <49E3ABC0.1050601@isi.edu> <49E3B9BF.1060901@gont.com.ar> <49E3BED9.1030701@isi.edu> <49E4D257.40504@gont.com.ar> <49E4E233.9040609@earthlink.net> <49E5F36D.7020808@earthlink.net> <49EE1873.1090907@gont.com.ar> <88ACD16A-1137-4E55-871F-8F0C992D7A63@nokia.com> <4A24626E.90805@gont.com.ar> <4A26E173.6040802@bogus.com> <4A2E1008.4060303@gont.com.ar> In-Reply-To: <4A2E1008.4060303@gont.com.ar> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: opsec@ietf.org, tcpm@ietf.org Subject: Re: [OPSEC] [tcpm] draft-gont-tcp-security 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: Tue, 09 Jun 2009 13:43:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: ... >> That said there's also some question as what sort of general >> recommendations about hardening tcp would actually be consider >> acceptable (in narrow use cases a lot more of them may well be). >> >> The diligent blacksmith knows that hardening a tool also >> makes it more brittle... > > This is a nice quote, but... I'd like examples. e.g., start discussing > about which specific hardening proposal makes TCP more brittle. 1) any security mechanism that increases complexity - of actions, state, or message exchanges - any of which increases the potential for implementation error 2) any security mechanism that has false positives, i.e., that discards messages deemed a security threat when they were sent for legitimate reasons #1 includes basically everything, from TCP MD5 (and TCP-AO) to tcpsecure and ICMP filtering #2 includes anything with nonzero false positives, such as tcpsecure and ICMP filtering I.e., AFAICT, *everything* that makes TCP more secure also makes it brittle, by definition (ditto for metal hardening, FWIW). The key issue is "when/where is the benefit worth the cost". Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkouZsMACgkQE5f5cImnZruBvACeIsbA4PwpE4xyp22+fGzH/5j2 9DYAoOCTLsrjZU7QcfCXsYq5TERlxcYY =ycUl -----END PGP SIGNATURE----- From Donald.Smith@qwest.com Tue Jun 9 08:03:23 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 3ECEF3A6C0C for ; Tue, 9 Jun 2009 08:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[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 61YFEeqs8J1I for ; Tue, 9 Jun 2009 08:03:22 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by core3.amsl.com (Postfix) with ESMTP id 590E83A6B2F for ; Tue, 9 Jun 2009 08:03:22 -0700 (PDT) Received: from suomp60i.qintra.com (suomp60i.qintra.com [151.117.69.27]) by sudnp799.qwest.com (8.14.0/8.14.0) with ESMTP id n59F35FI001102; Tue, 9 Jun 2009 09:03:05 -0600 (MDT) Received: from qtdenexhtm22.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.0/8.14.0) with ESMTP id n59F2wrk021383; Tue, 9 Jun 2009 10:02:59 -0500 (CDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Tue, 9 Jun 2009 09:02:52 -0600 From: "Smith, Donald" To: "'Joel Jaeggli'" , "'opsec@ietf.org'" Date: Tue, 9 Jun 2009 09:02:51 -0600 Thread-Topic: [OPSEC] FYI draft-ietf-opsec-blackhole-urpf-04 Thread-Index: Acnou4uCVB3O87oURwmIAwQtKZoWvAAVvDyg Message-ID: References: <4A2DE63B.5070300@bogus.com> In-Reply-To: <4A2DE63B.5070300@bogus.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 Subject: Re: [OPSEC] FYI draft-ietf-opsec-blackhole-urpf-04 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: Tue, 09 Jun 2009 15:03:23 -0000 (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com gcia =20 > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org]=20 > On Behalf Of Joel Jaeggli > Sent: Monday, June 08, 2009 10:34 PM > To: 'opsec@ietf.org' > Subject: [OPSEC] FYI draft-ietf-opsec-blackhole-urpf-04 >=20 > Another iteration of this draft after last call has been posted. >=20 > you many peruse it at your leisure. The diff located here: >=20 > http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-iet > f-opsec-blackhole-urpf-04.txt >=20 >=20 > shows the changes which are minor for the most part, except=20 > for the very > strong disclaimer now in 4.0... >=20 > Before enabling uRPF (in any mode), it is vital that you > fully understand the implications of doing so: >=20 > - Strict mode will cause the router to drop all ingress traffic > if the best path back to the source address of the traffic is > not the interface from which the traffic was received. > Asymetric routing will cause strict mode uRPF to drop > legitimate traffic. This completely ignores Junipers feasible-paths which allows for a urpf che= ck to "pass" the packet if a feasible path exists via the interface the packet arrived on. We should request all vendors implement feasible-path and active-paths too = since that would remove most of the danger in strict mode! >=20 > - Loose mode causes the router to check if a route for the source > address of the traffic exists. This may also cause legitimate > traffic to be discarded. >=20 > It is hoped that in the future, vendors will implement a "DoS- > mitigation" mode in addition to the Loose and Strict modes=20 > -- in this > mode, the uRPF check will only fail if the next-hop for=20 > the source of > the packet is a discard interface. > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > = From warren@kumari.net Tue Jun 9 08:44:34 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 59CFE3A6A85 for ; Tue, 9 Jun 2009 08:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.362 X-Spam-Level: X-Spam-Status: No, score=0.362 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, 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 boMNhW2taoU3 for ; Tue, 9 Jun 2009 08:44:33 -0700 (PDT) Received: from lisa.kumari.net (unknown [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 5F54B3A69D1 for ; Tue, 9 Jun 2009 08:44:33 -0700 (PDT) Received: by lisa.kumari.net (Postfix, from userid 5001) id 30F812284725; Tue, 9 Jun 2009 11:38:16 -0400 (EDT) Received: from dot.her.corp.google.com (unknown [208.253.108.65]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by lisa.kumari.net (Postfix) with ESMTPSA id B2608228468D; Tue, 9 Jun 2009 11:38:15 -0400 (EDT) Message-Id: From: Warren Kumari To: "Smith, Donald" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 9 Jun 2009 11:44:37 -0400 References: <4A2DE63B.5070300@bogus.com> X-Mailer: Apple Mail (2.935.3) Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] FYI draft-ietf-opsec-blackhole-urpf-04 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: Tue, 09 Jun 2009 15:44:34 -0000 On Jun 9, 2009, at 11:02 AM, Smith, Donald wrote: > > > (coffee != sleep) & (!coffee == sleep) > Donald.Smith@qwest.com gcia > >> -----Original Message----- >> From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] >> On Behalf Of Joel Jaeggli >> Sent: Monday, June 08, 2009 10:34 PM >> To: 'opsec@ietf.org' >> Subject: [OPSEC] FYI draft-ietf-opsec-blackhole-urpf-04 >> >> Another iteration of this draft after last call has been posted. >> >> you many peruse it at your leisure. The diff located here: >> >> http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-iet >> f-opsec-blackhole-urpf-04.txt >> >> >> shows the changes which are minor for the most part, except >> for the very >> strong disclaimer now in 4.0... >> >> Before enabling uRPF (in any mode), it is vital that you >> fully understand the implications of doing so: >> >> - Strict mode will cause the router to drop all ingress traffic >> if the best path back to the source address of the traffic is >> not the interface from which the traffic was received. >> Asymetric routing will cause strict mode uRPF to drop >> legitimate traffic. > This completely ignores Junipers feasible-paths which allows for a > urpf check to "pass" the packet if > a feasible path exists via the interface the packet arrived on. > > We should request all vendors implement feasible-path and active- > paths too since that would remove most of the danger in strict mode! Yes, you are completely correct, it *does* ignore the Juniper features and only outlines the lowest common denominator (I also didn't mention the optional ACL that you can use as well, etc). The text is meant as a warning to implementers and not a comprehensive guide to uRPF with all of its knobs and whistles. If y'all feel that the operation of feasible / active path should be included, I'd really appreciate some text, as I found writing the current text tricky -- for some reason I find explaining uRPF in a clean and concise manner difficult without a whieboard... > > >> >> - Loose mode causes the router to check if a route for the source >> address of the traffic exists. This may also cause legitimate >> traffic to be discarded. >> >> It is hoped that in the future, vendors will implement a "DoS- >> mitigation" mode in addition to the Loose and Strict modes >> -- in this >> mode, the uRPF check will only fail if the next-hop for >> the source of >> the packet is a discard interface. If this gets implemented (gentle reminder / poke), this will decrease the risk of enabling uRPF even further... >> >> _______________________________________________ >> 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 -- "Being the Fun-Police in the global Internet is a thankless - and probably futile - task." -- R. Whittle ("draft-whittle-sram-ip-forwarding-01.txt") From joelja@bogus.com Tue Jun 9 11:17: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 F047D3A6C9D for ; Tue, 9 Jun 2009 11:17:31 -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.400, 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 sATafIbm02Ii for ; Tue, 9 Jun 2009 11:17:31 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id CA2B53A6C70 for ; Tue, 9 Jun 2009 11:17:30 -0700 (PDT) Received: from [209.97.124.84] ([209.97.124.84]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id n59IGq2A016965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 Jun 2009 18:17:33 GMT (envelope-from joelja@bogus.com) Message-ID: <4A2EA70B.5020405@bogus.com> Date: Tue, 09 Jun 2009 11:16:43 -0700 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: "Smith, Donald" References: <4A2DE63B.5070300@bogus.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94.2/9445/Tue Jun 9 14:42:26 2009 on nagasaki.bogus.com X-Virus-Status: Clean Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] FYI draft-ietf-opsec-blackhole-urpf-04 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: Tue, 09 Jun 2009 18:17:32 -0000 I agree that feasible path is nice... ;) RFE's should be out of scope for this document. draft-smith-feasible-path-considered-benificial-00 will probably get a sympathetic ear in opsec, probably also idr. joelja Smith, Donald wrote: > > (coffee != sleep) & (!coffee == sleep) > Donald.Smith@qwest.com gcia > >> -----Original Message----- >> From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] >> On Behalf Of Joel Jaeggli >> Sent: Monday, June 08, 2009 10:34 PM >> To: 'opsec@ietf.org' >> Subject: [OPSEC] FYI draft-ietf-opsec-blackhole-urpf-04 >> >> Another iteration of this draft after last call has been posted. >> >> you many peruse it at your leisure. The diff located here: >> >> http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-iet >> f-opsec-blackhole-urpf-04.txt >> >> >> shows the changes which are minor for the most part, except >> for the very >> strong disclaimer now in 4.0... >> >> Before enabling uRPF (in any mode), it is vital that you >> fully understand the implications of doing so: >> >> - Strict mode will cause the router to drop all ingress traffic >> if the best path back to the source address of the traffic is >> not the interface from which the traffic was received. >> Asymetric routing will cause strict mode uRPF to drop >> legitimate traffic. > This completely ignores Junipers feasible-paths which allows for a urpf check to "pass" the packet if > a feasible path exists via the interface the packet arrived on. > > We should request all vendors implement feasible-path and active-paths too since that would remove most of the danger in strict mode! > >> - Loose mode causes the router to check if a route for the source >> address of the traffic exists. This may also cause legitimate >> traffic to be discarded. >> >> It is hoped that in the future, vendors will implement a "DoS- >> mitigation" mode in addition to the Loose and Strict modes >> -- in this >> mode, the uRPF check will only fail if the next-hop for >> the source of >> the packet is a discard interface. >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec >> From Donald.Smith@qwest.com Tue Jun 9 11:38:12 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 B8A5528C1BD for ; Tue, 9 Jun 2009 11:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[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 5JrS7a6lRW5A for ; Tue, 9 Jun 2009 11:38:12 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by core3.amsl.com (Postfix) with ESMTP id D8DB63A67DF for ; Tue, 9 Jun 2009 11:38:11 -0700 (PDT) Received: from suomp61i.qintra.com (suomp61i.qintra.com [151.117.69.28]) by sudnp799.qwest.com (8.14.0/8.14.0) with ESMTP id n59Ic9Yn012912; Tue, 9 Jun 2009 12:38:09 -0600 (MDT) Received: from qtdenexhtm22.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.0/8.14.0) with ESMTP id n59Ic3QA004835; Tue, 9 Jun 2009 13:38:03 -0500 (CDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Tue, 9 Jun 2009 12:38:03 -0600 From: "Smith, Donald" To: "'Joel Jaeggli'" Date: Tue, 9 Jun 2009 12:38:03 -0600 Thread-Topic: [OPSEC] FYI draft-ietf-opsec-blackhole-urpf-04 Thread-Index: AcnpLqDPJePlCtlqT6+b6+8s0lHNMgAAW3xQ Message-ID: References: <4A2DE63B.5070300@bogus.com> <4A2EA70B.5020405@bogus.com> In-Reply-To: <4A2EA70B.5020405@bogus.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 Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] FYI draft-ietf-opsec-blackhole-urpf-04 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: Tue, 09 Jun 2009 18:38:12 -0000 Then isn't the "it is hoped ... ddos-urpf" recommendation out of scope also= ? Feasible path is nice and there are a couple of other urpf recommendations = I could make to make it easier for other ISPs to start using strict mode ur= pf. Let me gather together recommendations and try to write them into a rfc. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com gcia =20 > -----Original Message----- > From: Joel Jaeggli [mailto:joelja@bogus.com]=20 > Sent: Tuesday, June 09, 2009 12:17 PM > To: Smith, Donald > Cc: 'opsec@ietf.org' > Subject: Re: [OPSEC] FYI draft-ietf-opsec-blackhole-urpf-04 >=20 > I agree that feasible path is nice... >=20 > ;) >=20 > RFE's should be out of scope for this document. >=20 > draft-smith-feasible-path-considered-benificial-00 will probably get a > sympathetic ear in opsec, probably also idr. >=20 > joelja >=20 > Smith, Donald wrote: > >=20 > > (coffee !=3D sleep) & (!coffee =3D=3D sleep) > > Donald.Smith@qwest.com gcia =20 > >=20 > >> -----Original Message----- > >> From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org]=20 > >> On Behalf Of Joel Jaeggli > >> Sent: Monday, June 08, 2009 10:34 PM > >> To: 'opsec@ietf.org' > >> Subject: [OPSEC] FYI draft-ietf-opsec-blackhole-urpf-04 > >> > >> Another iteration of this draft after last call has been posted. > >> > >> you many peruse it at your leisure. The diff located here: > >> > >> http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-iet > >> f-opsec-blackhole-urpf-04.txt > >> > >> > >> shows the changes which are minor for the most part, except=20 > >> for the very > >> strong disclaimer now in 4.0... > >> > >> Before enabling uRPF (in any mode), it is vital that you > >> fully understand the implications of doing so: > >> > >> - Strict mode will cause the router to drop all=20 > ingress traffic > >> if the best path back to the source address of the=20 > traffic is > >> not the interface from which the traffic was received. > >> Asymetric routing will cause strict mode uRPF to drop > >> legitimate traffic. > > This completely ignores Junipers feasible-paths which=20 > allows for a urpf check to "pass" the packet if > > a feasible path exists via the interface the packet arrived on. > >=20 > > We should request all vendors implement feasible-path and=20 > active-paths too since that would remove most of the danger=20 > in strict mode! > >=20 > >> - Loose mode causes the router to check if a route for=20 > the source > >> address of the traffic exists. This may also cause legitimate > >> traffic to be discarded. > >> > >> It is hoped that in the future, vendors will implement a "DoS- > >> mitigation" mode in addition to the Loose and Strict modes=20 > >> -- in this > >> mode, the uRPF check will only fail if the next-hop for=20 > >> the source of > >> the packet is a discard interface. > >> _______________________________________________ > >> OPSEC mailing list > >> OPSEC@ietf.org > >> https://www.ietf.org/mailman/listinfo/opsec > >> > = From joelja@bogus.com Tue Jun 9 12:15:50 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 C51A028C1B5 for ; Tue, 9 Jun 2009 12:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=-0.266, 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 FN5P6FqDCUm2 for ; Tue, 9 Jun 2009 12:15:50 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 7CF0A3A6D8F for ; Tue, 9 Jun 2009 12:15:49 -0700 (PDT) Received: from [209.97.124.84] ([209.97.124.84]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id n59JFB8n020456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 Jun 2009 19:15:53 GMT (envelope-from joelja@bogus.com) Message-ID: <4A2EB4B7.8050708@bogus.com> Date: Tue, 09 Jun 2009 12:15:03 -0700 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: "Smith, Donald" References: <4A2DE63B.5070300@bogus.com> <4A2EA70B.5020405@bogus.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94.2/9445/Tue Jun 9 14:42:26 2009 on nagasaki.bogus.com X-Virus-Status: Clean Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] FYI draft-ietf-opsec-blackhole-urpf-04 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: Tue, 09 Jun 2009 19:15:50 -0000 Smith, Donald wrote: > Then isn't the "it is hoped ... ddos-urpf" recommendation out of scope also? I think there's a distinction between describing a gap that is not yet adressed and asking for feature parity between two or N implmentations. I don't think that it's necessarily a detraction that a BCP doesn't cover all the details of a vendor specific implementation. Though to contrast I do think the implmentation examples are useful to get the point across. we (the royal we) just need to address this in another document. that > Feasible path is nice and there are a couple of other urpf recommendations I could make to make it easier for other ISPs to start using strict mode urpf. There beyond feasbile path there's the question of whether bcp 38 needs an update to reflect our experience with it. > Let me gather together recommendations and try to write them into a rfc. > > > (coffee != sleep) & (!coffee == sleep) > Donald.Smith@qwest.com gcia > >> -----Original Message----- >> From: Joel Jaeggli [mailto:joelja@bogus.com] >> Sent: Tuesday, June 09, 2009 12:17 PM >> To: Smith, Donald >> Cc: 'opsec@ietf.org' >> Subject: Re: [OPSEC] FYI draft-ietf-opsec-blackhole-urpf-04 >> >> I agree that feasible path is nice... >> >> ;) >> >> RFE's should be out of scope for this document. >> >> draft-smith-feasible-path-considered-benificial-00 will probably get a >> sympathetic ear in opsec, probably also idr. >> >> joelja >> >> Smith, Donald wrote: >>> (coffee != sleep) & (!coffee == sleep) >>> Donald.Smith@qwest.com gcia >>> >>>> -----Original Message----- >>>> From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] >>>> On Behalf Of Joel Jaeggli >>>> Sent: Monday, June 08, 2009 10:34 PM >>>> To: 'opsec@ietf.org' >>>> Subject: [OPSEC] FYI draft-ietf-opsec-blackhole-urpf-04 >>>> >>>> Another iteration of this draft after last call has been posted. >>>> >>>> you many peruse it at your leisure. The diff located here: >>>> >>>> http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-iet >>>> f-opsec-blackhole-urpf-04.txt >>>> >>>> >>>> shows the changes which are minor for the most part, except >>>> for the very >>>> strong disclaimer now in 4.0... >>>> >>>> Before enabling uRPF (in any mode), it is vital that you >>>> fully understand the implications of doing so: >>>> >>>> - Strict mode will cause the router to drop all >> ingress traffic >>>> if the best path back to the source address of the >> traffic is >>>> not the interface from which the traffic was received. >>>> Asymetric routing will cause strict mode uRPF to drop >>>> legitimate traffic. >>> This completely ignores Junipers feasible-paths which >> allows for a urpf check to "pass" the packet if >>> a feasible path exists via the interface the packet arrived on. >>> >>> We should request all vendors implement feasible-path and >> active-paths too since that would remove most of the danger >> in strict mode! >>>> - Loose mode causes the router to check if a route for >> the source >>>> address of the traffic exists. This may also cause legitimate >>>> traffic to be discarded. >>>> >>>> It is hoped that in the future, vendors will implement a "DoS- >>>> mitigation" mode in addition to the Loose and Strict modes >>>> -- in this >>>> mode, the uRPF check will only fail if the next-hop for >>>> the source of >>>> the packet is a discard interface. >>>> _______________________________________________ >>>> OPSEC mailing list >>>> OPSEC@ietf.org >>>> https://www.ietf.org/mailman/listinfo/opsec >>>> From fernando.gont.netbook.win@gmail.com Tue Jun 9 12:36:27 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 6966A3A6D92; Tue, 9 Jun 2009 12:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYdiwOeAJAyb; Tue, 9 Jun 2009 12:36:26 -0700 (PDT) Received: from mail-qy0-f111.google.com (mail-qy0-f111.google.com [209.85.221.111]) by core3.amsl.com (Postfix) with ESMTP id 4690A3A69E7; Tue, 9 Jun 2009 12:36:26 -0700 (PDT) Received: by qyk9 with SMTP id 9so15608qyk.29 for ; Tue, 09 Jun 2009 12:36:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=NJI+QIbrhFAwiVLpynQOjRx9LwceLecje5X6C5SY1tQ=; b=b7UardYZaLtBEji2MbmiA18fvRZAnmko/xlBcSY06NhjyM03iF4lsFI6opzY+elkqp otdSEFmtTkIDdmZ0lS5LQHKFfbsPJwCe//62WmlrXGqrDIcvHIlu0I+p89iSSBsUMKNS oqty53ZbclfNZgSZfswrYWs+nSIoDnAqfmEGA= 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:openpgp:content-type :content-transfer-encoding; b=NMsA4sucpbglw/2ltxdTIj7ETqPqcEuMTTxPMTDWQgfokLRVT5969fY3n9H7+4e0/y pWuLM/ztkKI+Sok7U3kimRmlb33RYO/UrziE3a/Oitj4vKRFp90owE4pb7w898vSPJ0f 4z7j4XWKWqQOlnqSZw+ebNSKAMFjZ3nPY+55Q= Received: by 10.220.100.5 with SMTP id w5mr679252vcn.62.1244576189828; Tue, 09 Jun 2009 12:36:29 -0700 (PDT) Received: from ?190.48.216.129? ([190.48.216.129]) by mx.google.com with ESMTPS id 8sm90027ywg.53.2009.06.09.12.36.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Jun 2009 12:36:28 -0700 (PDT) Sender: Fernando Gont Message-ID: <4A2EB9B7.80907@gont.com.ar> Date: Tue, 09 Jun 2009 16:36:23 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Joe Touch References: <49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu> <49E39119.1060902@gont.com.ar> <49E3A88F.9060301@gont.com.ar> <49E3ABC0.1050601@isi.edu> <49E3B9BF.1060901@gont.com.ar> <49E3BED9.1030701@isi.edu> <49E4D257.40504@gont.com.ar> <49E4E233.9040609@earthlink.net> <49E5F36D.7020808@earthlink.net> <49EE1873.1090907@gont.com.ar> <88ACD16A-1137-4E55-871F-8F0C992D7A63@nokia.com> <4A24626E.90805@gont.com.ar> <4A26E173.6040802@bogus.com> <4A2E1008.4060303@gont.com.ar> <4A2E66C3.6040701@isi.edu> In-Reply-To: <4A2E66C3.6040701@isi.edu> X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: opsec@ietf.org, tcpm@ietf.org Subject: Re: [OPSEC] [tcpm] draft-gont-tcp-security 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: Tue, 09 Jun 2009 19:36:27 -0000 Joe Touch wrote: >>> The diligent blacksmith knows that hardening a tool also >>> makes it more brittle... >> This is a nice quote, but... I'd like examples. e.g., start discussing >> about which specific hardening proposal makes TCP more brittle. > > 1) any security mechanism that increases complexity - of actions, state, > or message exchanges - any of which increases the potential for > implementation error Agreed. > 2) any security mechanism that has false positives, i.e., that discards > messages deemed a security threat when they were sent for legitimate reasons Why would this make e.g., TCP more brittle? In any case, the actual response to such packets may vary (e.g., in the case of ICMP hard errors, discard vs. process as soft errors). I believe that no matter what the recommended response is, it is important to discuss these issues, and try to get consensus on what's the right thing to do in each case. > #1 includes basically everything, from TCP MD5 (and TCP-AO) to tcpsecure > and ICMP filtering ICMP filtering actually decreases complexity. > I.e., AFAICT, *everything* that makes TCP more secure also makes it > brittle, by definition (ditto for metal hardening, FWIW). The key issue > is "when/where is the benefit worth the cost". As I said before, I'd like to have concrete examples from the tcp security i-d that are deemed to make TCP more brittle. 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 touch@ISI.EDU Tue Jun 9 13:07:22 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 DE2293A6847; Tue, 9 Jun 2009 13:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HK3bRp46oSKg; Tue, 9 Jun 2009 13:07:22 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 980123A6841; Tue, 9 Jun 2009 13:07:10 -0700 (PDT) Received: from [128.9.168.63] (bet.isi.edu [128.9.168.63]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n59K6bob014863; Tue, 9 Jun 2009 13:06:38 -0700 (PDT) Message-ID: <4A2EC0CD.3020505@isi.edu> Date: Tue, 09 Jun 2009 13:06:37 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Fernando Gont References: <49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu> <49E39119.1060902@gont.com.ar> <49E3A88F.9060301@gont.com.ar> <49E3ABC0.1050601@isi.edu> <49E3B9BF.1060901@gont.com.ar> <49E3BED9.1030701@isi.edu> <49E4D257.40504@gont.com.ar> <49E4E233.9040609@earthlink.net> <49E5F36D.7020808@earthlink.net> <49EE1873.1090907@gont.com.ar> <88ACD16A-1137-4E55-871F-8F0C992D7A63@nokia.com> <4A24626E.90805@gont.com.ar> <4A26E173.6040802@bogus.com> <4A2E1008.4060303@gont.com.ar> <4A2E66C3.6040701@isi.edu> <4A2EB9B7.80907@gont.com.ar> In-Reply-To: <4A2EB9B7.80907@gont.com.ar> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: opsec@ietf.org, tcpm@ietf.org Subject: Re: [OPSEC] [tcpm] draft-gont-tcp-security 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: Tue, 09 Jun 2009 20:07:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: > Joe Touch wrote: > >>>> The diligent blacksmith knows that hardening a tool also >>>> makes it more brittle... >>> This is a nice quote, but... I'd like examples. e.g., start discussing >>> about which specific hardening proposal makes TCP more brittle. >> 1) any security mechanism that increases complexity - of actions, state, >> or message exchanges - any of which increases the potential for >> implementation error > > Agreed. > > > >> 2) any security mechanism that has false positives, i.e., that discards >> messages deemed a security threat when they were sent for legitimate reasons > > Why would this make e.g., TCP more brittle? It makes a TCP that used to work not work anymore. > In any case, the actual response to such packets may vary (e.g., in the > case of ICMP hard errors, discard vs. process as soft errors). I believe > that no matter what the recommended response is, it is important to > discuss these issues, and try to get consensus on what's the right thing > to do in each case. Agreed. In a document that aimes to describe just what has been implemented, there's no goal of gaining community consensus, though. There is still utility, however, in providing the alternate viewpoint on the potential impacts of implementations. >> #1 includes basically everything, from TCP MD5 (and TCP-AO) to tcpsecure >> and ICMP filtering > > ICMP filtering actually decreases complexity. It requires more code to check that an ICMP is in-window than to not check. Nearly everything requires more code, at least. >> I.e., AFAICT, *everything* that makes TCP more secure also makes it >> brittle, by definition (ditto for metal hardening, FWIW). The key issue >> is "when/where is the benefit worth the cost". > > As I said before, I'd like to have concrete examples from the tcp > security i-d that are deemed to make TCP more brittle. I did above in both cases. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKLsDME5f5cImnZrsRAlGWAKCzYpIm7avI7zCezK/qr6+YOmLzogCg+hQe miDFj33au36GsANaWpxiM4w= =6lOt -----END PGP SIGNATURE----- From pekkas@netcore.fi Tue Jun 9 22:55: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 35C4C3A6887 for ; Tue, 9 Jun 2009 22:55: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 UTkltwBjhgjC for ; Tue, 9 Jun 2009 22:55:42 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 286503A67CF for ; Tue, 9 Jun 2009 22:55:41 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id n5A5tFhX012505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 08:55:15 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id n5A5tEh2012501; Wed, 10 Jun 2009 08:55:14 +0300 Date: Wed, 10 Jun 2009 08:55:14 +0300 (EEST) From: Pekka Savola To: "Smith, Donald" In-Reply-To: Message-ID: References: <4A2DE63B.5070300@bogus.com> <4A2EA70B.5020405@bogus.com> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.95.1 at otso.netcore.fi X-Virus-Status: Clean Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] FYI draft-ietf-opsec-blackhole-urpf-04 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, 10 Jun 2009 05:55:43 -0000 On Tue, 9 Jun 2009, Smith, Donald wrote: > Feasible path is nice and there are a couple of other urpf > recommendations I could make to make it easier for other ISPs to > start using strict mode urpf. > > Let me gather together recommendations and try to write them into a rfc. Seconded. You may already know this but RFC3704 talks a bit about feasible paths on a generic level, and draft-savola-bcp84-urpf-experiences-03 describes experiences with multihomed uRPF using feasible paths. We're using it everywhere but some manual fiddling is required in our case (described in the draft above). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From Donald.Smith@qwest.com Thu Jun 11 14:07:42 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 844143A6A87 for ; Thu, 11 Jun 2009 14:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[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 SZn3p+Y0COqM for ; Thu, 11 Jun 2009 14:07:41 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id AD1873A6ACE for ; Thu, 11 Jun 2009 14:07:41 -0700 (PDT) Received: from suomp60i.qintra.com (suomp60i.qintra.com [151.117.69.27]) by suomp64i.qwest.com (8.14.0/8.14.0) with ESMTP id n5BL7eIi002105; Thu, 11 Jun 2009 16:07:40 -0500 (CDT) Received: from qtdenexhtm21.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.0/8.14.0) with ESMTP id n5BL7Wd9024936; Thu, 11 Jun 2009 16:07:35 -0500 (CDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm21.AD.QINTRA.COM ([151.119.91.230]) with mapi; Thu, 11 Jun 2009 15:07:31 -0600 From: "Smith, Donald" To: Pekka Savola Content-Class: urn:content-classes:message Date: Thu, 11 Jun 2009 15:07:29 -0600 Thread-Topic: [OPSEC] FYI draft-ietf-opsec-blackhole-urpf-04 Thread-Index: AcnpkB1mExHJZ7hmSUuJN8FeK+MuYgBR/QaWAAAj9BY= Message-ID: <978FEEE5-BD74-4A31-9CC3-AECD525530A5@mimectl> References: <4A2DE63B.5070300@bogus.com> <4A2EA70B.5020405@bogus.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-mimectl: Produced By Microsoft Exchange V8.1.348.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] FYI draft-ietf-opsec-blackhole-urpf-04 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, 11 Jun 2009 21:07:42 -0000 Based on this conversation I withdraw my objection. Several members expressed interest in doing a urpf feature recommendations = type rfc aimed at making it easier for ISPs to implement urpf including thi= ngs like feasible paths. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com gcia ________________________________ From: Pekka Savola [pekkas@netcore.fi] Sent: Tuesday, June 09, 2009 11:55 PM To: Smith, Donald Cc: 'Joel Jaeggli'; 'opsec@ietf.org' Subject: Re: [OPSEC] FYI draft-ietf-opsec-blackhole-urpf-04 On Tue, 9 Jun 2009, Smith, Donald wrote: > Feasible path is nice and there are a couple of other urpf > recommendations I could make to make it easier for other ISPs to > start using strict mode urpf. > > Let me gather together recommendations and try to write them into a rfc. Seconded. You may already know this but RFC3704 talks a bit about feasible paths on a generic level, and draft-savola-bcp84-urpf-experiences-03 describes experiences with multihomed uRPF using feasible paths. We're using it everywhere but some manual fiddling is required in our case (described in the draft above). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From joelja@bogus.com Thu Jun 11 14:54:03 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 33F1F3A693A; Thu, 11 Jun 2009 14:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 cqsKLyUWkdpc; Thu, 11 Jun 2009 14:54:02 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 005EA3A6D60; Thu, 11 Jun 2009 14:53:56 -0700 (PDT) Received: from [209.97.124.84] ([209.97.124.84]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id n5BLrKxc083550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Jun 2009 21:54:02 GMT (envelope-from joelja@bogus.com) Message-ID: <4A317CCB.1010301@bogus.com> Date: Thu, 11 Jun 2009 14:53:15 -0700 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Ron Bonica , iesg-secretary@ietf.org, "'opsec@ietf.org'" X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94.2/9456/Thu Jun 11 17:43:13 2009 on nagasaki.bogus.com X-Virus-Status: Clean Subject: [OPSEC] Document Shepherd / Announcement Write-Up for draft-ietf-opsec-blackhole-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, 11 Jun 2009 21:54:03 -0000 Document Shepherd Write-Up for draft-ietf-opsec-blackhole-urpf Questions per RFC 4858 3.1: 1a. Joel Jaeggli is the shepherd for document. The shepherd believes that this document is of sufficient quality to bring to the IESG Ron Bonica is the shepherding AD. 1b. The document has received review in the working group as well as input from the creators of the method and operator community that is the intended audience for this draft. 1c. The reservation of default communities, previously a feature of this draft was removed between 01 and 02 leaving only operational practice. 1d. None 1e. Working group consensus has consistently favored this work item. Community reservation had significant detractors as current practice has operators select their own communities based on what they are willing to support and the use of such signaling requires significant coordination. 1f. No 1g. ID Nits have been passed. There are three examples located in Appendix A and B where RFC 3330 addresses cannot solely be used for the purposes of clarity RFC 1918 addresses are used to supplement them. 1h. There are no downwardly referential normative references. 1i. With the removal of the community reservation there are no IANA considerations. 1j. No such formal validation is required. 1k. included Document Announcement Write-Up for draft-ietf-opsec-blackhole-urpf currently in draft 04 having completed WG last call and AD Evaluation. Technical Summary 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. Working Group Summary The WG last call period for draft-ietf-opsec-blackhole-urpf-03 was completed without opposition. Commentary on the draft in the current and prior revision at IETF 74 and before would indicate that the WG believes that the document is in suitable form to advance. AD Review revealed insufficient warning on the implications of using strict RPF. 04 revision is believed to satisfy both AD concerns and WG participants. Document Quality As it documents existing current practice both in router implementation and in operational practice and expands upon but does not obsolete rfc 3882 we believe that it is suitable to advance towards the goal of BCP status. Personnel Review by both industry peers (NANOG security BOF), and one of the originators of the method (Barry Greene) was solicited, and their input is noted in the contributions section. Joel Jaeggli Shepherded this document through the working group process. AD review was provide by R. Boninca. From fernando@gont.com.ar Wed Jun 24 14:36:08 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 775793A6A4F for ; Wed, 24 Jun 2009 14:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.181 X-Spam-Level: X-Spam-Status: No, score=-1.181 tagged_above=-999 required=5 tests=[AWL=-0.544, BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_SPEEDY_AR=0.808] 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 IAS-wqXqpOBd for ; Wed, 24 Jun 2009 14:36:07 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 3E9503A6B88 for ; Wed, 24 Jun 2009 14:36:06 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 2D5D56B6837 for ; Wed, 24 Jun 2009 18:35:33 -0300 (ART) Received: from [190.48.195.127] (190-48-195-127.speedy.com.ar [190.48.195.127] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n5OLZJWY025986; Wed, 24 Jun 2009 18:35:20 -0300 Message-ID: <4A429C1E.5000109@gont.com.ar> Date: Wed, 24 Jun 2009 18:35:26 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "'opsec@ietf.org'" 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]); Wed, 24 Jun 2009 18:35:32 -0300 (ART) Subject: [OPSEC] Security Assessment of TCP ([Fwd: [tcpm] poll for adopting draft-gont-tcp-security]) 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, 24 Jun 2009 21:36:08 -0000 Hello, folks, Some time ago there had been a thread about the document "Security Assessment of the Transmission Control Protocol (TCP)" pubished by the UK CPNI (available at: http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf). I have already produced an IETF I-D version of this document (draft-gont-tcp-security) on behalf of CPNI, so that the IETF can work on this stuff. FWIW, my personal take (possibly biased, since I am the document author) is that this document has been the result of a lot of work (including the work of the many peple that reviewed the CPNI version of the document), and that the IETF should take this chance to work and publish something on the subject. The TCPM chairs are currently polling the WG for input about this document. It would be great if you could voice your opinion about whether the TCPM should take this document on, and also if we could get detailed reviews of this document. (Bellow you'll find a copy of the TCPM chairs' poll) Please send your comments to tcpm@ietf.org (and please CC me). Thanks! Kind regards, Fernando -------- Original Message -------- Subject: [tcpm] poll for adopting draft-gont-tcp-security Date: Wed, 24 Jun 2009 14:25:04 -0500 From: Eddy, Wesley M. (GRC-MS00)[Verizon] To: tcpm Extensions WG TCPMers, there was a thread a while ago about working on draft-gont-tcp-security in this working group that didn't conclusively give us a feeling one way or other: http://www.ietf.org/mail-archive/web/tcpm/current/msg04489.html Basically, my understanding is that there are at least a handful of people in the WG that think it should be done here as a WG item (more likely for Informational rather than BCP), and there are also some expressed opinions on why it shouldn't. Given the raw size of the document, if the WG intends to take this document on, then we need some people to clearly commit to putting cycles into review and contributions to the document. Since it is quite large, and to my knowledge, there hasn't been a specific technical review of the content on this list, but just discussions about if the idea in general is a good or bad thing, we still need to know if people are willing to invest their time and energy in this. Please let us know if there is traction for this in the near term, and/or we can also discuss it in Stockholm. --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 --------------------------- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1