From joelja@bogus.com Wed Apr 1 22:38:33 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 A07D63A6C65; Wed, 1 Apr 2009 22:38:33 -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 rHnONQzHWmip; Wed, 1 Apr 2009 22:38:33 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id ABF0A3A6C15; Wed, 1 Apr 2009 22:38:32 -0700 (PDT) Received: from [192.168.1.117] (c-98-234-53-212.hsd1.ca.comcast.net [98.234.53.212]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id n325dT8D097439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Apr 2009 05:39:31 GMT (envelope-from joelja@bogus.com) Message-ID: <49D44F8F.1030207@bogus.com> Date: Wed, 01 Apr 2009 22:39:27 -0700 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Internet-Drafts@ietf.org References: <20090330161501.918F03A6AD6@core3.amsl.com> In-Reply-To: <20090330161501.918F03A6AD6@core3.amsl.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/9196/Wed Apr 1 19:38:26 2009 on nagasaki.bogus.com X-Virus-Status: Clean Cc: opsec@ietf.org, i-d-announce@ietf.org Subject: Re: [OPSEC] I-D Action:draft-ietf-opsec-blackhole-urpf-03.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, 02 Apr 2009 05:38:33 -0000 Anyone have any comments on this latest revision of the document? Per the discussion in San Francisco we believe that it's in pretty good shape and is well suited for advancement towards a BCP. Internet-Drafts@ietf.org wrote: > 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-03.txt > Pages : 17 > Date : 2009-03-30 > > 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-03.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. > > > ------------------------------------------------------------------------ > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From joelja@bogus.com Wed Apr 1 22:52:04 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 B1A0B28C1B1 for ; Wed, 1 Apr 2009 22:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 eGVSd4H-7Orv for ; Wed, 1 Apr 2009 22:52:04 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 8C5B73A6CA0 for ; Wed, 1 Apr 2009 22:52:03 -0700 (PDT) Received: from [192.168.1.117] (c-98-234-53-212.hsd1.ca.comcast.net [98.234.53.212]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id n325qvj2098213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Apr 2009 05:52:58 GMT (envelope-from joelja@bogus.com) Message-ID: <49D452B6.7020102@bogus.com> Date: Wed, 01 Apr 2009 22:52:54 -0700 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Christopher Morrow References: <200903302103.XAA18237@TR-Sys.de> <75cb24520903301409t4f9cb6a5w4ff49ae70befcea1@mail.gmail.com> In-Reply-To: <75cb24520903301409t4f9cb6a5w4ff49ae70befcea1@mail.gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.94.2/9196/Wed Apr 1 19:38:26 2009 on nagasaki.bogus.com X-Virus-Status: Clean Cc: =?UTF-8?B?QWxmcmVkIEjDjm5lcw==?= , danny@arbor.net, opsec@ietf.org Subject: Re: [OPSEC] draft-ietf-opsec-blackhole-urpf-03 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, 02 Apr 2009 05:52:04 -0000 Christopher Morrow wrote: > I'd also say push this to LC in the WG... Joe/Joel? agree > -Chris > > On Mon, Mar 30, 2009 at 5:03 PM, Alfred HÎnes wrote: >> Authors, >> thanks for faithfully taking care of my change suggestions, >> leading to draft-ietf-opsec-blackhole-urpf-03 . >> >> Quickly following up to this version, I only got stuck at a minor >> formatting flaw in Section 4.2, where the table in step 7.2 is >> poorly formatted. (This could be deferred to the RFC Editor.) >> >> Otherwise, I have no more 'complaints'. :-) >> >> I now recommend going ahead with this draft for RFC publication. >> >> Kind regards, >> Alfred HÎnes. >> >> -- >> >> +------------------------+--------------------------------------------+ >> | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | >> | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | >> | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | >> +------------------------+--------------------------------------------+ >> >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec >> > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > From joelja@bogus.com Wed Apr 1 23:56: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 6857828C0E6 for ; Wed, 1 Apr 2009 23:56:38 -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 8r8T3Ug4KQO1 for ; Wed, 1 Apr 2009 23:56:37 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 6A5543A683F for ; Wed, 1 Apr 2009 23:56:37 -0700 (PDT) Received: from [192.168.1.117] (c-98-234-53-212.hsd1.ca.comcast.net [98.234.53.212]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id n326vZMn001732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 2 Apr 2009 06:57:36 GMT (envelope-from joelja@bogus.com) Message-ID: <49D461DD.3000101@bogus.com> Date: Wed, 01 Apr 2009 23:57:33 -0700 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: opsec wg mailing list X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94.2/9197/Thu Apr 2 04:05:41 2009 on nagasaki.bogus.com X-Virus-Status: Clean Subject: [OPSEC] Working Group Last Call draft-ietf-opsec-blackhole-urpf-03.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, 02 Apr 2009 06:56:38 -0000 This announcement is for working group last call on: http://tools.ietf.org/html/draft-ietf-opsec-blackhole-urpf-03.txt. Please send your comments to the list by Friday April 17, 2009. Thanks Joel From fernando.gont.netbook.win@gmail.com Mon Apr 13 12:22: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 B69113A68F3; Mon, 13 Apr 2009 12:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, 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 XB0c-BM3U9Xq; Mon, 13 Apr 2009 12:22:21 -0700 (PDT) Received: from mail-gx0-f163.google.com (mail-gx0-f163.google.com [209.85.217.163]) by core3.amsl.com (Postfix) with ESMTP id DB96D3A68D1; Mon, 13 Apr 2009 12:22:16 -0700 (PDT) Received: by gxk7 with SMTP id 7so433315gxk.13 for ; Mon, 13 Apr 2009 12:23:27 -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=yAi6IxUnt0bjyi7ie5/zh3Tc7neo7XV4qkrYVtULmzA=; b=KuBVCODLbazFQiaS6LFhulXACDzpRBEQVr8Hz+Y4XatjzclkoC42mfQC/0KCSTP2oy eOrARURh7F8e6456GiTrMzlPa0Ool8mpF89U5Dq0Vll2+CCLTbXuoQA93MR8zUozzHPl hT+PrT6x7pH8tejE93wxGfJErr3y4lRc4ZzwQ= 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=HG2g3eQGAEtAqMx2+WCZkLUxDJEQ5en5yXFxIhDaJVwJBwqY9+enDqclg/E9K6YXVJ 3ON9OrXM5X1DBPHjrmozLbSi7OSuKz/Op96FQMM5n6zqY+TeYZ1YmJDm5sqWAWye2Kq9 LSO2tCOUPJa/6oiDDX6UlWj2DcyulYOi6ycXs= Received: by 10.100.152.12 with SMTP id z12mr6046866and.96.1239650595208; Mon, 13 Apr 2009 12:23:15 -0700 (PDT) Received: from ?192.168.0.151? (235-131-17-190.fibertel.com.ar [190.17.131.235]) by mx.google.com with ESMTPS id b14sm139539ana.18.2009.04.13.12.23.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 13 Apr 2009 12:23:14 -0700 (PDT) Sender: Fernando Gont Message-ID: <49E39119.1060902@gont.com.ar> Date: Mon, 13 Apr 2009 16:23:05 -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> In-Reply-To: <49E3878C.9080200@isi.edu> X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" , ietf@ietf.org, Joe Abley , opsec@ietf.org, Lars Eggert , "Eddy, Wesley M. \(GRC-RCN0\)\[Verizon\]" 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: Mon, 13 Apr 2009 19:22:22 -0000 Joe Touch wrote: >> So we had tcp-secure in 2004, icmp-attacks in 2005, a claim for a >> trivial attack in 2008 (Outpost24/CERT-FI), and we'll probably continue >> in this line, because we do nothing about it. > > Whether we have this document or not, we will continue to have people > who incorrectly assume that TCP is secure. That's correct. But we also have people that do know it is not mean to be secure, but that it should be resilient enough so that it's still usable. One way or another, most stacks implement counter-measures for SYN-floods (on which tcpm did publish something), timers on the FIN-WAIT-2 state, port randomization (on which tsvwg is working), ICP ISN randomization, etc. The reason for which they did that was to improve TCP's security/resiliency. Would you argue in favour of predictable ISNs, predictable ports, time-less FIN-WAIT-2 state, etc.? -- I hope you wouldn't. >>> It summarizes issues already raised by the WG, >> I believe this statement is unfair with respect to our document. e.g., >> has the issues described in Section 4.3, Section 9.2, or Section 10 been >> brought to tcpm before??? > > I didn't say that's all it does ;-) Agreed that it raises other issues, > many of which are operational. Many of which arise if you expect to use TCP in some other scenario that just two computers in a LAN. If that makes those issues "operational", I agree. >>> TCP itself is not a secure protocol, nor is it intended to be. >> Yeah. But that does not mean that we should not do our best to improve >> it. > > It means we should not try to give the incorrect impression that it > *can* be secured. It's security/resiliency can be improved. After all, if that were not the case, I guess you're wasting your time with TCP-AO. Or is it that you believe the only way to improve a protocol is to throw crypto at it? > Interpreting every unexpected event as an attack makes > a protocol robust but also brittle; TCP is intended to trade flexibility > for security, AFAICT, because it is agnostic about intent, and gives the > benefit of doubt at all times. I would prefer that instead of making this type of broad statement, you would argue against a particular recommendation in draft-gont-tcp-security, and explain how it makes TCP more brittle. > Consider packet drops. That can happen due to loss, non-malicious > corruption, or jamming, e.g. In the last case, it makes sense to blast > copies of packets in the hopes of getting something through, but that's > NOT what we assume. Wasn't this very behavior what lead to the Internet congestion collapse in the 80's, or am I missing something? >> Please talk to vendors. I don't want to reproduce here what seems to >> be the consensus among vendors with respect to the current state of >> affairs in terms of how up-to-date our specs are. > > Vendors misapply our protocols then complain that they don't work. Yes, > there are operational issues, but one severe operational issue is not > using security for some policy, financial, or operation expense and then > complaining that nonsecure TCP is being attacked. Joe, we're talkng about a simple web server being taken down because of a SYN flood, a FIN-WAIT-2 flood, or the like. Even the most stupid web server should survive these types of attacks. 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 Donald.Smith@qwest.com Mon Apr 13 12:54: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 7367928C156; Mon, 13 Apr 2009 12:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n59JO5OSrqrS; Mon, 13 Apr 2009 12:54:35 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by core3.amsl.com (Postfix) with ESMTP id E180728C152; Mon, 13 Apr 2009 12:54:34 -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 n3DJte07020122; Mon, 13 Apr 2009 13:55:40 -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 n3DJtX9g000470; Mon, 13 Apr 2009 14:55:34 -0500 (CDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Mon, 13 Apr 2009 13:55:30 -0600 From: "Smith, Donald" To: "'Fernando Gont'" , "'Joe Touch'" Date: Mon, 13 Apr 2009 13:55:30 -0600 Thread-Topic: [OPSEC] [tcpm] draft-gont-tcp-security Thread-Index: Acm8bWCAc1S4KexUSCS6Tc+o0uRA6wAAO68A Message-ID: References: <49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu> <49E39119.1060902@gont.com.ar> In-Reply-To: <49E39119.1060902@gont.com.ar> 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: "'tcpm@ietf.org'" , "'ietf@ietf.org'" , 'Joe Abley' , "'opsec@ietf.org'" , 'Lars Eggert' , "'Eddy, Wesley M. \(GRC-RCN0\)\[Verizon\]'" 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: Mon, 13 Apr 2009 19:54:48 -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 Fernando Gont > Sent: Monday, April 13, 2009 1:23 PM > To: Joe Touch > Cc: tcpm@ietf.org; ietf@ietf.org; Joe Abley; opsec@ietf.org;=20 > Lars Eggert; Eddy,Wesley M. (GRC-RCN0)[Verizon] > Subject: Re: [OPSEC] [tcpm] draft-gont-tcp-security >=20 > Joe Touch wrote: >=20 > >> So we had tcp-secure in 2004, icmp-attacks in 2005, a claim for a > >> trivial attack in 2008 (Outpost24/CERT-FI), and we'll=20 > probably continue > >> in this line, because we do nothing about it. > >=20 > > Whether we have this document or not, we will continue to=20 > have people > > who incorrectly assume that TCP is secure. Secure is a general term. TCP was intended to address several areas of secu= rity. The classic tenets for computer security is: CIA -> Confidentiality, Integrity and Availability. TCP doesn't attempt to address Confidentiality. However it was designed to address integrity and availability so failures i= n those areas should be documented and addressed in some fashion. >=20 > That's correct. But we also have people that do know it is not mean to > be secure, but that it should be resilient enough so that it's still > usable. One way or another, most stacks implement counter-measures for > SYN-floods (on which tcpm did publish something), timers on the > FIN-WAIT-2 state, port randomization (on which tsvwg is working), ICP > ISN randomization, etc. >=20 > The reason for which they did that was to improve TCP's=20 > security/resiliency. >=20 > Would you argue in favour of predictable ISNs, predictable ports, > time-less FIN-WAIT-2 state, etc.? -- I hope you wouldn't. >=20 >=20 >=20 > >>> It summarizes issues already raised by the WG,=20 > >> I believe this statement is unfair with respect to our=20 > document. e.g., > >> has the issues described in Section 4.3, Section 9.2, or=20 > Section 10 been > >> brought to tcpm before??? > >=20 > > I didn't say that's all it does ;-) Agreed that it raises=20 > other issues, > > many of which are operational. >=20 > Many of which arise if you expect to use TCP in some other=20 > scenario that > just two computers in a LAN. If that makes those issues=20 > "operational", I > agree. >=20 >=20 >=20 > >>> TCP itself is not a secure protocol, nor is it intended to be. Again, it was intended to help ensure integrity and availability. > >> Yeah. But that does not mean that we should not do our=20 > best to improve > >> it. > >=20 > > It means we should not try to give the incorrect impression that it > > *can* be secured.=20 It can be made better that is not an incorrect impression it is a fact. >=20 > It's security/resiliency can be improved. After all, if that were not > the case, I guess you're wasting your time with TCP-AO. Or is it that > you believe the only way to improve a protocol is to throw=20 > crypto at it? Adding crypto improves confidentiality and integrity but is counter product= ive to availability as most=20 crypto engines are prone to fairly low pps resource exhaustion attacks. =20 >=20 > > Interpreting every unexpected event as an attack makes=20 > > a protocol robust but also brittle; TCP is intended to=20 > trade flexibility > > for security, AFAICT, because it is agnostic about intent,=20 > and gives the > > benefit of doubt at all times.=20 >=20 > I would prefer that instead of making this type of broad=20 > statement, you > would argue against a particular recommendation in > draft-gont-tcp-security, and explain how it makes TCP more brittle. >=20 >=20 >=20 > > Consider packet drops. That can happen due to loss, non-malicious > > corruption, or jamming, e.g. In the last case, it makes=20 > sense to blast > > copies of packets in the hopes of getting something=20 > through, but that's > > NOT what we assume. >=20 > Wasn't this very behavior what lead to the Internet=20 > congestion collapse > in the 80's, or am I missing something? >=20 >=20 >=20 > >> Please talk to vendors. I don't want to reproduce here=20 > what seems to > >> be the consensus among vendors with respect to the current state of > >> affairs in terms of how up-to-date our specs are. I talk to vendors a lot. I don't think there is a consensus on the "how up-= to-date our specs are". I can't even get a straight answer on how they addressed the icmp-blind res= ets or the tcp-blind resets from several years ago. There were several poss= ible mitigations with some trade offs on each of them. Yet finding out how = your favorite vendor addressed those is likely to be difficult. > >=20 > > Vendors misapply our protocols then complain that they=20 > don't work. Yes, > > there are operational issues, but one severe operational=20 > issue is not > > using security for some policy, financial, or operation=20 > expense and then > > complaining that nonsecure TCP is being attacked. Again the use of a generic "secure". What do you mean by "nonsecure" here? >=20 > Joe, we're talkng about a simple web server being taken down=20 > because of > a SYN flood, a FIN-WAIT-2 flood, or the like. Even the most stupid web > server should survive these types of attacks. >=20 > Kind regards, > --=20 > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > = From fernando.gont.netbook.win@gmail.com Mon Apr 13 14:02:55 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 750913A6EAE; Mon, 13 Apr 2009 14:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 tHvej6x4dtq0; Mon, 13 Apr 2009 14:02:54 -0700 (PDT) Received: from mail-gx0-f163.google.com (mail-gx0-f163.google.com [209.85.217.163]) by core3.amsl.com (Postfix) with ESMTP id D242E3A6ED8; Mon, 13 Apr 2009 14:02:09 -0700 (PDT) Received: by gxk7 with SMTP id 7so441529gxk.13 for ; Mon, 13 Apr 2009 14:03:20 -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=LSwc2s+dPhZk/nolwE375FttFgXivlgGBPLgK0LqKtA=; b=RHJTTn2m1JJIfBanAbyJ5zEKLdMb26fgUagylVGKBVIxJHCcSaiaGBppsihZlGBXaE ScuEO0wuPXOFPG1jyDVI35GyuBAZUW0zfbiTAtv8imErTG88hr4PCfoR78RpApIb4fmH 7o9OUX75MkELY7wnp4AEl7tHpIobqvnYk8Kws= 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=dTyms580WszwzjPtugbljTePnuhRL3+NFESvEzHjOSfQOtmlsXRuZLV6IMaZn0F99n mP51+VBWKydkX4kPyQYQwWE/c7jjtxQxMthCRXhKlyE/pfOUMuq5lrZnah9kDUSZYA36 DKJ4YnzpACzvuXL+YlzKDllHzLN502WXtXuXM= Received: by 10.100.7.13 with SMTP id 13mr8565634ang.10.1239656599991; Mon, 13 Apr 2009 14:03:19 -0700 (PDT) Received: from ?192.168.0.151? (235-131-17-190.fibertel.com.ar [190.17.131.235]) by mx.google.com with ESMTPS id c9sm853001ana.5.2009.04.13.14.03.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 13 Apr 2009 14:03:19 -0700 (PDT) Sender: Fernando Gont Message-ID: <49E3A88F.9060301@gont.com.ar> Date: Mon, 13 Apr 2009 18:03:11 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Smith, Donald" References: <49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu> <49E39119.1060902@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 Cc: "'tcpm@ietf.org'" , "'ietf@ietf.org'" , 'Joe Touch' , 'Joe Abley' , "'opsec@ietf.org'" , 'Lars Eggert' , "'Eddy, Wesley M. \(GRC-RCN0\)\[Verizon\]'" 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: Mon, 13 Apr 2009 21:02:55 -0000 Smith, Donald wrote: >>>> Please talk to vendors. I don't want to reproduce here >> what seems to >>>> be the consensus among vendors with respect to the current >>>> state of affairs in terms of how up-to-date our specs are. > I talk to vendors a lot. I don't think there is a consensus on the > "how up-to-date our specs are". The consensus seems to be that the current state of affairs is something like: "a mess". Even if you do care to produce a resilient implementation, that task is going to be much harder than necessary. You don't know the amount of cycles we spent in producing draft-gont-tcp-security.... let alone the time it would take to move the advice in an actual implementation. > I can't even get a straight answer on how they addressed the > icmp-blind resets or the tcp-blind resets from several years ago. > There were several possible mitigations with some trade offs on each > of them. Yet finding out how your favorite vendor addressed those is > likely to be difficult. In many cases the lack of a straight answer may have to do with us being unable to get to consensus and get something published in a timely fashion. e.g., the last round on ICMP attacks against TCP was circa 2004. At that point an I-D was published on the subject (now draft-ietf-tcpm-icmp-attacks). Yet we're still nitpicking on it, when everybody did something about it five years ago. It becomes harder to get s staright answer when it's impossible for a vendor to point to a counter-measure that is supposed to be the result of a thorough review process, in a *timely* fashion. I'm aware there's an effort in the vendor community to improve the resiliency of TCP basedon the document published by UK CPNI. Yet we're still debating whether to ignore it or not.... maybe so that we can publish an RFC in the future tagging those implementations as non-compliant... or maybe to allow tcp vulnerabilities to be "rediscovered" every few years. 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 Donald.Smith@qwest.com Mon Apr 13 15:03:33 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 A456C3A6A13; Mon, 13 Apr 2009 15:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hq0TbDwxBTt; Mon, 13 Apr 2009 15:03:32 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id A0B943A68A8; Mon, 13 Apr 2009 15:03:32 -0700 (PDT) Received: from suomp61i.qintra.com (suomp61i.qintra.com [151.117.69.28]) by suomp64i.qwest.com (8.14.0/8.14.0) with ESMTP id n3DM4IhI001293; Mon, 13 Apr 2009 17:04:19 -0500 (CDT) Received: from qtdenexhtm20.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.0/8.14.0) with ESMTP id n3DM4CaU024708; Mon, 13 Apr 2009 17:04:12 -0500 (CDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm20.AD.QINTRA.COM ([151.119.91.229]) with mapi; Mon, 13 Apr 2009 16:04:12 -0600 From: "Smith, Donald" To: "'Joe Touch'" Date: Mon, 13 Apr 2009 16:04:11 -0600 Thread-Topic: [OPSEC] [tcpm] draft-gont-tcp-security Thread-Index: Acm8fCTNNWHKB3L4SN2ay+XPh46BiwAAxQwg Message-ID: References: <49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu> <49E39119.1060902@gont.com.ar> <49E3A9D6.4030504@isi.edu> In-Reply-To: <49E3A9D6.4030504@isi.edu> 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: "'tcpm@ietf.org'" , "'ietf@ietf.org'" , 'Joe Abley' , "'opsec@ietf.org'" , 'Lars Eggert' , "'Eddy, Wesley M. \(GRC-RCN0\)\[Verizon\]'" 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: Mon, 13 Apr 2009 22:03:33 -0000 (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com gcia =20 > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU]=20 > Sent: Monday, April 13, 2009 3:09 PM > To: Smith, Donald > Cc: 'Fernando Gont'; 'tcpm@ietf.org'; 'ietf@ietf.org'; 'Joe=20 > Abley'; 'opsec@ietf.org'; 'Lars Eggert'; 'Eddy,Wesley M.=20 > (GRC-RCN0)[Verizon]' > Subject: Re: [OPSEC] [tcpm] draft-gont-tcp-security >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Donald, >=20 > I'm confused by your post. You appear to believe that TCP is=20 > intended to > be secure. Note that TCP does not require either the MD5 or=20 > AO extension. I didn't mentioned authentication or authorization in my description of sec= urity but those two enhancements do provide some ability for authentication and authorizati= on. Yes, I do think elements of tcp/ip were designed to address the integrity a= nd availablity. >=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 Fernando Gont > >> Sent: Monday, April 13, 2009 1:23 PM > >> To: Joe Touch > >> Cc: tcpm@ietf.org; ietf@ietf.org; Joe Abley; opsec@ietf.org;=20 > >> Lars Eggert; Eddy,Wesley M. (GRC-RCN0)[Verizon] > >> Subject: Re: [OPSEC] [tcpm] draft-gont-tcp-security > >> > >> Joe Touch wrote: > >> > >>>> So we had tcp-secure in 2004, icmp-attacks in 2005, a claim for a > >>>> trivial attack in 2008 (Outpost24/CERT-FI), and we'll=20 > >> probably continue > >>>> in this line, because we do nothing about it. > >>> Whether we have this document or not, we will continue to=20 > >> have people > >>> who incorrectly assume that TCP is secure. > >=20 > > Secure is a general term. TCP was intended to address=20 > several areas of security. > > The classic tenets for computer security is: > > CIA -> Confidentiality, Integrity and Availability. > > TCP doesn't attempt to address Confidentiality. > > However it was designed to address integrity and availability so=20 > > failures in those areas should be documented and addressed in some > > fashion. >=20 > Can you explain this? Where is the integrity protection? Where is the > availability specified? Checksumming in tcp/ip is intended to provide intregrity protection. Mind you it is NOT tamper proof but that is the intent. Detection of lost packets, retransmitions, reassembly of fragments, congest= ion notification, dynamic routing and many other tcp/ip features are intend= ed to address availablity. >=20 > ... > >> It's security/resiliency can be improved. After all, if=20 > that were not > >> the case, I guess you're wasting your time with TCP-AO. Or=20 > is it that > >> you believe the only way to improve a protocol is to throw=20 > >> crypto at it? > >=20 > > Adding crypto improves confidentiality and integrity but is counter > > productive to availability as most > > crypto engines are prone to fairly low pps resource exhaustion > > attacks. >=20 > All prevention methods are susceptible to computational resource > attacks, since all increase the operations performed on a=20 > packet.=20 GTSM is a valuable exception to this statement but other then that I tend t= o agree:) >It is > commonly assumed that this is a desirable tradeoff, and that the > computational resources can be totally protected with line-rate > dedicated computation (e.g., hardware assist). I believe that is a common assumption however I don't believe that assumpti= on is correct. I do a fair amount of router testing and although some portions of ipv4 are= hardware assisted and therefore line-rate there are still many paths to th= e "slow path". IPv6 has many more routes to the slow path:( >=20 > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >=20 > iEYEARECAAYFAknjqdYACgkQE5f5cImnZruhawCgqqkl3NPljMkNRz8buEYROGUO > R2kAnRHhQmWJVtXq/j2wbNy64q6QWe+u > =3DOkiS > -----END PGP SIGNATURE----- > = From fernando.gont.netbook.win@gmail.com Mon Apr 13 15:15: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 B94743A67B1; Mon, 13 Apr 2009 15:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 O-FOR4sVQWYl; Mon, 13 Apr 2009 15:15:30 -0700 (PDT) Received: from mail-gx0-f163.google.com (mail-gx0-f163.google.com [209.85.217.163]) by core3.amsl.com (Postfix) with ESMTP id 4CF063A6C22; Mon, 13 Apr 2009 15:15:30 -0700 (PDT) Received: by gxk7 with SMTP id 7so448239gxk.13 for ; Mon, 13 Apr 2009 15:16:41 -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=6HLm2gJLCSrNWV43539qUV1LrzTRHqLp1J+4IafeMII=; b=gBjuQtq+EvGyEF1UGOsYGd9a9sE1t79yGECoWld7ACruG7XYjqUxNjZNsXCgx/La6V 7CcRq/9dYAYT6viv5oWmWqpKdTqla15Gn2/1Lek4QwX8wCptrryRLHBMCZN4EQ7pXGhJ qIK67qV1WaihVEUMP+yuYGdkweORg6J8QGA2w= 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=UYFkvxkRhrFAu24OuhTopLMiCJSxnih+3tAOoOt9CEvVcg9yq4GDIJ3sMQukWtLYgA Oz8wrUlAuZx9DeDa7LIoudXSaq/pJTHvuT4ogKYfcdy712PvJfXiDga3AXDS9TeaIjji D7R0Ewho9yVgjMiuhHfh/sp2HmzZyR4K7biWg= Received: by 10.100.152.12 with SMTP id z12mr5125294and.141.1239660998200; Mon, 13 Apr 2009 15:16:38 -0700 (PDT) Received: from ?192.168.0.151? (235-131-17-190.fibertel.com.ar [190.17.131.235]) by mx.google.com with ESMTPS id d24sm249633and.37.2009.04.13.15.16.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 13 Apr 2009 15:16:37 -0700 (PDT) Sender: Fernando Gont Message-ID: <49E3B9BF.1060901@gont.com.ar> Date: Mon, 13 Apr 2009 19:16:31 -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> In-Reply-To: <49E3ABC0.1050601@isi.edu> X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'tcpm@ietf.org'" , "'ietf@ietf.org'" , 'Joe Abley' , "'opsec@ietf.org'" , 'Lars Eggert' , "'Eddy, Wesley M. \(GRC-RCN0\)\[Verizon\]'" 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: Mon, 13 Apr 2009 22:15:31 -0000 Joe Touch wrote: >> The consensus seems to be that the current state of affairs is something >> like: "a mess". Even if you do care to produce a resilient >> implementation, that task is going to be much harder than necessary. You >> don't know the amount of cycles we spent in producing >> draft-gont-tcp-security.... let alone the time it would take to move the >> advice in an actual implementation. > > Advice in making a hardened version of TCP would be useful to the > implementation community. To a large extent this is what draft-gont-tcp-security is about. > However, if you're saying that TCP specs in general are a mess, yes they > are. That's why we created a roadmap document, and why it needs to be > maintained. If you're suggesting we need a clean single documentation of > what TCP is, I might even agree. However: > > 1) TCPM is not the place that would generate it > (IMO, that'd be TSVWG) > > 2) this document is not a step in that direction The tcp roadmap is a roadmap to the documents that the IETF has published. There's lots of stuff that has not been published by the IETF and that therefore is not discussed in the tcp roadmap. This is another area in which this document tries to help. > You've produced a summary of issues you feel would harden TCP. I feel > that some of them make TCP more brittle, and some make TCP unnecessarily > complex, and in both cases the mods are not needed in the general > Internet. Is there nothing in the document with which you agree? > TCPsecure is a good example; it has caveats in its ID that > indicate where it is useful and where it is not -- it is NOT a general > solution for the entire Internet (the WG basically agreed to that with > the wording for its use cases). c'mon Joe.. IMO, tcpsecure needed to include those statements about usefulness in large part because it was IPR-encumbered, and in part as a political workaround that would avoid further waste of time in endless discussions. >> In many cases the lack of a straight answer may have to do with us being >> unable to get to consensus and get something published in a timely >> fashion. e.g., the last round on ICMP attacks against TCP was circa >> 2004. At that point an I-D was published on the subject (now >> draft-ietf-tcpm-icmp-attacks). Yet we're still nitpicking on it, when >> everybody did something about it five years ago. > > Uh, well, we're deciding whether we agree with what's been deployed. > Deploying some of these changes hasn't always been a good idea; if it > were, we'd be agreeing to it. Some people prefer to get work done instead of committing/wasting lots of cycles in endless discussions. >> It becomes harder to get s staright answer when it's impossible for a >> vendor to point to a counter-measure that is supposed to be the result >> of a thorough review process, in a *timely* fashion. > > Can you be as specific here as you want us to be? What exactly does a > vendor want that isn't provided by IPsec, TCP MD5, etc., or the existing > known countermeasures? What's "the existing known counter-measures"? >> I'm aware there's an effort in the vendor community to improve the >> resiliency of TCP basedon the document published by UK CPNI. Yet we're >> still debating whether to ignore it or not.... maybe so that we can >> publish an RFC in the future tagging those implementations as >> non-compliant... or maybe to allow tcp vulnerabilities to be >> "rediscovered" every few years. > > If the vendors are following this doc already, then we REALLY need to > ensure it's updated with advice appropriate to the context in which it > is deployed. FWIW, vendors are following the UK CPNI document. The idea of bringing those results to the IETF is so that these results/advice can be further discussed, more eyes look into them, and the doc is modified if it is felt necessary. > Running around saying the sky is falling for everyone isn't > going to help. Who did that? We worked on this document very silently for a couple of years. If we had wanted that "sky is falling" approach, we would have gone to the press before showing anything (like quite a few folks have been doing in the recent past). Or we could have announced part of this stuff as "vulnerabilities" to the press.. That wasn't the case. I tried to get many people to review the document, and have the document be as objective as possible. At least for the ip-security counterpart, I recall asking you to have a look at it before publication, even when I knew that you'd most likely disagree with large parts of the document. This project is already done.... but nevertheless I'm still spending some cycles to bring this to the IETF, because I truly believe the IETF should work on it. Neither me nor UK CPNI have IPRs or anything on the material covered in our document... so there's no hidden motivation in all this. Honestly, I'm not sure why you always have to knock down others' efforts on a "by default" basis, and prejudge the motivation behind those efforts. 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 root@core3.amsl.com Mon Apr 13 16:00: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 C56883A6EDB; Mon, 13 Apr 2009 16:00: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: <20090413230001.C56883A6EDB@core3.amsl.com> Date: Mon, 13 Apr 2009 16:00:01 -0700 (PDT) Cc: opsec@ietf.org Subject: [OPSEC] I-D Action:draft-ietf-opsec-efforts-10.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: Mon, 13 Apr 2009 23:00: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 Best Practices Efforts and Documents Author(s) : C. Lonvick, D. Spak Filename : draft-ietf-opsec-efforts-10.txt Pages : 35 Date : 2009-04-13 This document provides a snapshot of the current efforts to define or apply security requirements in various Standards Developing Organizations (SDO). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsec-efforts-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-opsec-efforts-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-13155401.I-D@ietf.org> --NextPart-- From fernando.gont.netbook.win@gmail.com Mon Apr 13 22:43: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 761FD3A6D99; Mon, 13 Apr 2009 22:43:31 -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 sCSbgW+hjeUV; Mon, 13 Apr 2009 22:43:30 -0700 (PDT) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.241]) by core3.amsl.com (Postfix) with ESMTP id 994FF3A6D97; Mon, 13 Apr 2009 22:43:29 -0700 (PDT) Received: by ag-out-0708.google.com with SMTP id 23so1116653agd.12 for ; Mon, 13 Apr 2009 22:44:40 -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=4r6fJ2HYuYJwLMrCqOfC7vCje8jq+inqAyUc/bkP2sY=; b=DQFayMU3ciGL29pGCYmGerPRVI7Ggym28+WJ9vnLB7x9Kfs4g0ZrMC9B8v77N8jb85 MiDPuq6nfsUwCmUuXTO/0QUiXYOQYu32H3GWfqd5WdhSBsPXVm+MCEVkRSY0n9Pcrx4h 8to77Jfnc2DY+CC+MsV2zCdrj5BGO4Q6oIa6E= 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=cpvBW2J6mIRx+LL/cUc/rw+vmAkDJ+ZwWd08pBIQruqkGb2FA+EVEz6JIbQLwjLhWX eA1XRlaOsNdgevgRKW5dAMDUNFdc42XYhenDDUu79ZQXL9om8rsUjI/nTFgE23iT7Tuj 81dcmdy02OsXoZyyR6IY6BLyx5YpYbDH+JHyA= Received: by 10.90.117.17 with SMTP id p17mr491548agc.30.1239687880210; Mon, 13 Apr 2009 22:44:40 -0700 (PDT) Received: from ?192.168.1.3? ([190.50.221.185]) by mx.google.com with ESMTPS id 34sm1197628agc.39.2009.04.13.22.44.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 13 Apr 2009 22:44:39 -0700 (PDT) Sender: Fernando Gont Message-ID: <49E422C0.5050908@gont.com.ar> Date: Tue, 14 Apr 2009 02:44:32 -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> In-Reply-To: <49E3BED9.1030701@isi.edu> X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'tcpm@ietf.org'" , "'ietf@ietf.org'" , 'Joe Abley' , "'opsec@ietf.org'" , 'Lars Eggert' , "'Eddy, Wesley M. \(GRC-RCN0\)\[Verizon\]'" 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, 14 Apr 2009 05:43:31 -0000 Joe Touch wrote: >>>> The consensus seems to be that the current state of affairs is something >>>> like: "a mess". Even if you do care to produce a resilient >>>> implementation, that task is going to be much harder than necessary. You >>>> don't know the amount of cycles we spent in producing >>>> draft-gont-tcp-security.... let alone the time it would take to move the >>>> advice in an actual implementation. >>> Advice in making a hardened version of TCP would be useful to the >>> implementation community. >> To a large extent this is what draft-gont-tcp-security is about. > > Implementation advice is outside the scope of the IETF. It's not even > operational, IMO. RFC 816: "MODULARITY AND EFFICIENCY IN PROTOCOL IMPLEMENTATION" RFC 815: "IP DATAGRAM REASSEMBLY ALGORITHMS" (see Section 4) and, RFC 1936: "Implementing the Internet Checksum in Hardware" (of which you are on of the co-authors :-) ) That said, to a large extent the document is provides advise about enforcing stricter validation checks, timeouts where appropriate, and about a number of policies that may improve TCP's resiliency/security (e.g., how to select ISN's, etc.) >>> You've produced a summary of issues you feel would harden TCP. I feel >>> that some of them make TCP more brittle, and some make TCP unnecessarily >>> complex, and in both cases the mods are not needed in the general >>> Internet. >> Is there nothing in the document with which you agree? > > That'd be harsh. I agree with some of the implementation advice as > implementation advice. I agree that, in risk-prone environments (where > packets can be tapped, e.g.), some of the recommendations are appropriate. > > I'm disagreeing primarily with the general tone and balance of the document. I believe at this point in time we're deciding whether it makes sense to work on this document, and where it would make sense to do it. draft-gont-tcp-security-00 is just a starting point. Of course, it represents my pov, and to some extent the pov of the reviewers. But the idea of bringing it to the IETF is that future versions of the document represent wg consensus. If you have specific suggestions on how to improve the document, I'll be more than happy to hear about them. However, I believe at this point we are not yet discussing on any specific issue discussed in the draft, but are trying to agree on how to move forward. (Feedback on the technical details in the document is nevertheless welcome, though) >> c'mon Joe.. IMO, tcpsecure needed to include those statements about >> usefulness in large part because it was IPR-encumbered, and in part as a >> political workaround that would avoid further waste of time in endless >> discussions. > > I disagree. Even if it weren't IPR encumbered, I would disagree with > widescale deployment of a modification to TCP that answers a RST with > one *or more* ACKs. As I said numerous times w.r.t. that document, the > modifications it suggests are generally not needed, unnecessarily > complicate packet processing, and since they don't protect from > in-window injection attacks, I find them useless in the general case. TCP is already very complicated. And the implementation of the countermeasures in tcpsecure usually require not much more than (literally) a couple of additional lines, or a slight modification in some conditional statement. >>>> It becomes harder to get s staright answer when it's impossible for a >>>> vendor to point to a counter-measure that is supposed to be the result >>>> of a thorough review process, in a *timely* fashion. >>> Can you be as specific here as you want us to be? What exactly does a >>> vendor want that isn't provided by IPsec, TCP MD5, etc., or the existing >>> known countermeasures? >> What's "the existing known counter-measures"? > > Limit cycles/resources available for new connections, e.g., for SYN > attacks -- as is already done for things like IKE. At the point in which you actually try to put this into code, a number of questions arise that need to be answered. Why should vendors rehash the same analysis over an over again (with the potential of doing it wrong, which would lead to buggy implementations), when we could put out a document with consensus on the preferable way to do those things. >> FWIW, vendors are following the UK CPNI document. The idea of bringing >> those results to the IETF is so that these results/advice can be further >> discussed, more eyes look into them, and the doc is modified if it is >> felt necessary. > > I've been saying I feel that mods are necessary, and you keep > complaining. That's not how I read your comments. If your point of view is "it would be interesting to work on this. however, i believe the document should be modified in this way, because of this reason" that's one thing. If your pov is "we don't need this. go somewhere else", that's something entirely different. > If you're here for a rubber stamp, you came to the wrong WG ;-) Rubber-stamp? No, Joe. The UK CPNI rubberstamp is more than enough, and when it comes to advice on this issues, I believe it's even more credible. Ask the question in bugtraq or full-disclosure, and that's most likely the conclusion you'll get to. I'm involved in the IETF, and honestly believe that the IETF should work on this. I do know that the end result of that process would be such that I probably won't be as happy with the resulting RFC than with the UK CPNI document. But at least I would have helped to change the current state of affairs a little bit. > The sky has been falling in this WG for several years. Although this > document is the first aggregation of such recommendations, as you know > it's composed of many documents you yourself have been discussing for > that period in this WG.. I'd probably argue that the case with tcpm is that at (many) times protocol specifications have been taken as if they were casted in stone. And unless one is part of some small circle of people that is supposed to have been allowed by God to modify such specs, it will be very hard there's no effort that takes less than quite a few years. Very loud people take the time to maintain endless discussions, and most mere mortals that need to get work done end up completely avoiding tcpm altogether, because it requires a huge spend of time. Virtually every developer that I know of won't care about what the end result in tcpm is. At most, they will post a question to hear comments. But that's it. To a large extent people cannot believe the amount of energy we spend for such a null progress. Example: ICMP attacks draft (draft-ietf-tcpm-icmp-attacks). The doc was reviewed by devolpers from Sun, FreeBSD, NetBSD, OpenBSD, Linux, extreme networks, and Cisco (this last one "unofficially"). To them, the draft looks okay. Many other people have also agreed with that. But I cannot get those folks involved in our endless discussions. The ROI for them is NULL. Do they care about the outcome? Not really. They agree with the proposal, it is in the code already, and has been running for years. They just let us waste our time. I agree that there are benefits to be gained from having a more conservative philosophy, to put it some way. I believe that it is a good thing to challenge proposals, to aim at improving their quality, etc. This has helped improve many documents, including those I have authored. But I believe at some point it starts looking as "everything that neither me or my inner circle proposes will be banned". >> Honestly, I'm not sure why you always have to knock down others' efforts >> on a "by default" basis, and prejudge the motivation behind those efforts. > > I'm asking the question I apparently keep needing to ask: > > Why do you think that just because something is implemented > we should recommend it? That's not how the tcp-security document was produced. For instance, many of the recommendations had never been implemented. And the document argues *against* some common implementation strategies. > Why do you think that a message that isn't expected indicates > an attack to be defended against, vs. the actions of a > benign endpoint? We simply raise the bar about what we react to. If there are packets for which there's no legitimate use, we don't react to them (if this doesn't cause harm). > I have a high bar for the need for modifications to TCP, and the need to > propagate local solutions to every endpoint in the Internet. And do you believe that such propagation depends on our outcome? -- Thanks God, it doesn't. Try to find any implementation that is fully-compliant with the RFCs, and let me know if you find any. The lack of advice on all these issues has put vendors in a position in which they have to figure out that advice by themselves. Sometimes they got to the right answers, sometimes not. Have a look at the vulnerability advisories referenced in the I-D: the same errors are committed over and over again. draft-gont-tcp-security is an effort to help the vendor/developer community in that area. P.S.: My apologizes for the possible politically-incorrect comments. But this is the best trade-off I have been able to get between being politically-correct and being honest. 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 Mon Apr 13 14:02:59 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 799AC28C13E; Mon, 13 Apr 2009 14:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] 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 afWbtLTLw9qT; Mon, 13 Apr 2009 14:02:58 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 127CC3A67A4; Mon, 13 Apr 2009 14:02:40 -0700 (PDT) Received: from [75.215.162.89] (89.sub-75-215-162.myvzw.com [75.215.162.89]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n3DL2Hgg027815; Mon, 13 Apr 2009 14:02:19 -0700 (PDT) Message-ID: <49E3A856.9020703@isi.edu> Date: Mon, 13 Apr 2009 14:02:14 -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> In-Reply-To: <49E39119.1060902@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 X-Mailman-Approved-At: Tue, 14 Apr 2009 01:01:10 -0700 Cc: "tcpm@ietf.org" , ietf@ietf.org, Joe Abley , opsec@ietf.org, Lars Eggert , "Eddy, Wesley M. \(GRC-RCN0\)\[Verizon\]" 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: Mon, 13 Apr 2009 21:02:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: > Joe Touch wrote: > >>> So we had tcp-secure in 2004, icmp-attacks in 2005, a claim for a >>> trivial attack in 2008 (Outpost24/CERT-FI), and we'll probably continue >>> in this line, because we do nothing about it. >> Whether we have this document or not, we will continue to have people >> who incorrectly assume that TCP is secure. > > That's correct. But we also have people that do know it is not mean to > be secure, but that it should be resilient enough so that it's still > usable. One way or another, most stacks implement counter-measures for > SYN-floods (on which tcpm did publish something), timers on the > FIN-WAIT-2 state, port randomization (on which tsvwg is working), ICP > ISN randomization, etc. > > The reason for which they did that was to improve TCP's security/resiliency. > > Would you argue in favour of predictable ISNs, predictable ports, > time-less FIN-WAIT-2 state, etc.? -- I hope you wouldn't. These measures can be used to reduce the impact of attacks when TCP is not secured. However, they DO NOT make TCP secure. They DO make TCP more brittle - they limit the way in which two legitimate endpoints can do legitimate things. >>>> It summarizes issues already raised by the WG, >>> I believe this statement is unfair with respect to our document. e.g., >>> has the issues described in Section 4.3, Section 9.2, or Section 10 been >>> brought to tcpm before??? >> I didn't say that's all it does ;-) Agreed that it raises other issues, >> many of which are operational. > > Many of which arise if you expect to use TCP in some other scenario that > just two computers in a LAN. If that makes those issues "operational", I > agree. Many of those don't arise for computers in a wide area, or with millions of other computers on the network either. They arise only when there are active attacks, and only for some kinds of attackers (on-path, off-path, high-speed access, etc.) IMO, any decision which would be enabled or disabled depending on whether security was a concern or performance was needed is operational. E.g., port randomization helps only when attackers are off-path and when port use is a fraction of the active port space. That's operational. Ditto for ISN randomization. I.e., if the protection is not needed in the absence of attacks, it may be operational. >>>> TCP itself is not a secure protocol, nor is it intended to be. >>> Yeah. But that does not mean that we should not do our best to improve >>> it. >> It means we should not try to give the incorrect impression that it >> *can* be secured. > > It's security/resiliency can be improved. After all, if that were not > the case, I guess you're wasting your time with TCP-AO. Or is it that > you believe the only way to improve a protocol is to throw crypto at it? I *know* that the only way to secure a protocol is to throw crypto at it. I also *know* that unexpected packets are *not* indications of attacks. These two things are not evident in this document, and should be. Further, this document should make a case as to whether the improvements are operational or not. AFAICT, most are operational. >> Interpreting every unexpected event as an attack makes >> a protocol robust but also brittle; TCP is intended to trade flexibility >> for security, AFAICT, because it is agnostic about intent, and gives the >> benefit of doubt at all times. > > I would prefer that instead of making this type of broad statement, you > would argue against a particular recommendation in > draft-gont-tcp-security, and explain how it makes TCP more brittle. Randomizing ports and ISNs assumes there is a window over which some values are NOT used; that window precludes legitimate exchanges from occurring. That is what I mean by "brittle." >> Consider packet drops. That can happen due to loss, non-malicious >> corruption, or jamming, e.g. In the last case, it makes sense to blast >> copies of packets in the hopes of getting something through, but that's >> NOT what we assume. > > Wasn't this very behavior what lead to the Internet congestion collapse > in the 80's, or am I missing something? Loss of a segment can mean: a) congestion (correlated drops) b) non-correlated drops (not related to increasing traffic) c) active removal (attack) If (a), then you backoff. That's how congestion collapse was addressed. If you believe that packet drops are caused by either non-correlated drops or active removal, you send MORE - you send copies of each packet, e.g. That is NOT what we assume, but what I presume you ought to recommend in a document that assumes that every event that COULD have been an attack probably is an attack. >>> Please talk to vendors. I don't want to reproduce here what seems to >>> be the consensus among vendors with respect to the current state of >>> affairs in terms of how up-to-date our specs are. >> Vendors misapply our protocols then complain that they don't work. Yes, >> there are operational issues, but one severe operational issue is not >> using security for some policy, financial, or operation expense and then >> complaining that nonsecure TCP is being attacked. > > Joe, we're talkng about a simple web server being taken down because of > a SYN flood, a FIN-WAIT-2 flood, or the like. Even the most stupid web > server should survive these types of attacks. If you're talking about implementation advice (don't put all your resources in pending connections), I agree that a good implementation should be implemented well. But that's operational / implementation advice, not protocol advice. I do not agree that all web servers should implement SYN cookies, e.g. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknjqFYACgkQE5f5cImnZrtBNwCgiJPsTDBt34Im+s/TFkBm90DE Xn4AoNlUvCAucvZoVVMTpex4sMXAaXb2 =1ijT -----END PGP SIGNATURE----- From touch@ISI.EDU Mon Apr 13 14:08:13 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 7CDA53A6A06; Mon, 13 Apr 2009 14:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id np9EJSfzLIk1; Mon, 13 Apr 2009 14:08:12 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id AB7B23A6924; Mon, 13 Apr 2009 14:08:12 -0700 (PDT) Received: from [75.215.162.89] (89.sub-75-215-162.myvzw.com [75.215.162.89]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n3DL8dSh029094; Mon, 13 Apr 2009 14:08:41 -0700 (PDT) Message-ID: <49E3A9D6.4030504@isi.edu> Date: Mon, 13 Apr 2009 14:08:38 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Smith, Donald" References: <49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu> <49E39119.1060902@gont.com.ar> In-Reply-To: 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 X-Mailman-Approved-At: Tue, 14 Apr 2009 01:01:10 -0700 Cc: "'tcpm@ietf.org'" , "'ietf@ietf.org'" , 'Joe Abley' , "'opsec@ietf.org'" , 'Lars Eggert' , "'Eddy, Wesley M. \(GRC-RCN0\)\[Verizon\]'" 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: Mon, 13 Apr 2009 21:08:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Donald, I'm confused by your post. You appear to believe that TCP is intended to be secure. Note that TCP does not require either the MD5 or AO extension. 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 Fernando Gont >> Sent: Monday, April 13, 2009 1:23 PM >> To: Joe Touch >> Cc: tcpm@ietf.org; ietf@ietf.org; Joe Abley; opsec@ietf.org; >> Lars Eggert; Eddy,Wesley M. (GRC-RCN0)[Verizon] >> Subject: Re: [OPSEC] [tcpm] draft-gont-tcp-security >> >> Joe Touch wrote: >> >>>> So we had tcp-secure in 2004, icmp-attacks in 2005, a claim for a >>>> trivial attack in 2008 (Outpost24/CERT-FI), and we'll >> probably continue >>>> in this line, because we do nothing about it. >>> Whether we have this document or not, we will continue to >> have people >>> who incorrectly assume that TCP is secure. > > Secure is a general term. TCP was intended to address several areas of security. > The classic tenets for computer security is: > CIA -> Confidentiality, Integrity and Availability. > TCP doesn't attempt to address Confidentiality. > However it was designed to address integrity and availability so > failures in those areas should be documented and addressed in some > fashion. Can you explain this? Where is the integrity protection? Where is the availability specified? ... >> It's security/resiliency can be improved. After all, if that were not >> the case, I guess you're wasting your time with TCP-AO. Or is it that >> you believe the only way to improve a protocol is to throw >> crypto at it? > > Adding crypto improves confidentiality and integrity but is counter > productive to availability as most > crypto engines are prone to fairly low pps resource exhaustion > attacks. All prevention methods are susceptible to computational resource attacks, since all increase the operations performed on a packet. It is commonly assumed that this is a desirable tradeoff, and that the computational resources can be totally protected with line-rate dedicated computation (e.g., hardware assist). Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknjqdYACgkQE5f5cImnZruhawCgqqkl3NPljMkNRz8buEYROGUO R2kAnRHhQmWJVtXq/j2wbNy64q6QWe+u =OkiS -----END PGP SIGNATURE----- From touch@ISI.EDU Mon Apr 13 14:16: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 F033D3A6ECA; Mon, 13 Apr 2009 14:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 nbJQWIjqok+C; Mon, 13 Apr 2009 14:16:49 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id DDB2B3A6EC8; Mon, 13 Apr 2009 14:16:49 -0700 (PDT) Received: from [75.215.162.89] (89.sub-75-215-162.myvzw.com [75.215.162.89]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n3DLGn33001231; Mon, 13 Apr 2009 14:16:51 -0700 (PDT) Message-ID: <49E3ABC0.1050601@isi.edu> Date: Mon, 13 Apr 2009 14:16:48 -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> In-Reply-To: <49E3A88F.9060301@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 X-Mailman-Approved-At: Tue, 14 Apr 2009 01:01:10 -0700 Cc: "'tcpm@ietf.org'" , "'ietf@ietf.org'" , 'Joe Abley' , "'opsec@ietf.org'" , 'Lars Eggert' , "'Eddy, Wesley M. \(GRC-RCN0\)\[Verizon\]'" 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: Mon, 13 Apr 2009 21:16:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: > Smith, Donald wrote: > >>>>> Please talk to vendors. I don't want to reproduce here >>> what seems to >>>>> be the consensus among vendors with respect to the current >>>>> state of affairs in terms of how up-to-date our specs are. >> I talk to vendors a lot. I don't think there is a consensus on the >> "how up-to-date our specs are". > > The consensus seems to be that the current state of affairs is something > like: "a mess". Even if you do care to produce a resilient > implementation, that task is going to be much harder than necessary. You > don't know the amount of cycles we spent in producing > draft-gont-tcp-security.... let alone the time it would take to move the > advice in an actual implementation. Advice in making a hardened version of TCP would be useful to the implementation community. However, if you're saying that TCP specs in general are a mess, yes they are. That's why we created a roadmap document, and why it needs to be maintained. If you're suggesting we need a clean single documentation of what TCP is, I might even agree. However: 1) TCPM is not the place that would generate it (IMO, that'd be TSVWG) 2) this document is not a step in that direction You've produced a summary of issues you feel would harden TCP. I feel that some of them make TCP more brittle, and some make TCP unnecessarily complex, and in both cases the mods are not needed in the general Internet. TCPsecure is a good example; it has caveats in its ID that indicate where it is useful and where it is not -- it is NOT a general solution for the entire Internet (the WG basically agreed to that with the wording for its use cases). >> I can't even get a straight answer on how they addressed the >> icmp-blind resets or the tcp-blind resets from several years ago. >> There were several possible mitigations with some trade offs on each >> of them. Yet finding out how your favorite vendor addressed those is >> likely to be difficult. > > In many cases the lack of a straight answer may have to do with us being > unable to get to consensus and get something published in a timely > fashion. e.g., the last round on ICMP attacks against TCP was circa > 2004. At that point an I-D was published on the subject (now > draft-ietf-tcpm-icmp-attacks). Yet we're still nitpicking on it, when > everybody did something about it five years ago. Uh, well, we're deciding whether we agree with what's been deployed. Deploying some of these changes hasn't always been a good idea; if it were, we'd be agreeing to it. > It becomes harder to get s staright answer when it's impossible for a > vendor to point to a counter-measure that is supposed to be the result > of a thorough review process, in a *timely* fashion. Can you be as specific here as you want us to be? What exactly does a vendor want that isn't provided by IPsec, TCP MD5, etc., or the existing known countermeasures? > I'm aware there's an effort in the vendor community to improve the > resiliency of TCP basedon the document published by UK CPNI. Yet we're > still debating whether to ignore it or not.... maybe so that we can > publish an RFC in the future tagging those implementations as > non-compliant... or maybe to allow tcp vulnerabilities to be > "rediscovered" every few years. If the vendors are following this doc already, then we REALLY need to ensure it's updated with advice appropriate to the context in which it is deployed. Running around saying the sky is falling for everyone isn't going to help. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknjq78ACgkQE5f5cImnZrv1lwCg3sR/xHE5SRW9nld39xFN+ZCb rWkAn2pA80tWrpS/8iQTau97RoFpaEBl =yF7F -----END PGP SIGNATURE----- From touch@ISI.EDU Mon Apr 13 15:22:28 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 613313A6858; Mon, 13 Apr 2009 15:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 qivFj0jN3KuL; Mon, 13 Apr 2009 15:22:27 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 7DD673A68A8; Mon, 13 Apr 2009 15:22:27 -0700 (PDT) Received: from [75.215.162.89] (89.sub-75-215-162.myvzw.com [75.215.162.89]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n3DMN0R2016634; Mon, 13 Apr 2009 15:23:02 -0700 (PDT) Message-ID: <49E3BB44.9000206@isi.edu> Date: Mon, 13 Apr 2009 15:23:00 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Smith, Donald" References: <49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu> <49E39119.1060902@gont.com.ar> <49E3A9D6.4030504@isi.edu> In-Reply-To: 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 X-Mailman-Approved-At: Tue, 14 Apr 2009 01:01:10 -0700 Cc: "'tcpm@ietf.org'" , "'ietf@ietf.org'" , 'Joe Abley' , "'opsec@ietf.org'" , 'Lars Eggert' , "'Eddy, Wesley M. \(GRC-RCN0\)\[Verizon\]'" 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: Mon, 13 Apr 2009 22:22:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Smith, Donald wrote: ... >>>> The classic tenets for computer security is: >>>> CIA -> Confidentiality, Integrity and Availability. >>>> TCP doesn't attempt to address Confidentiality. >>>> However it was designed to address integrity and availability so >>>> failures in those areas should be documented and addressed in some >>>> fashion. > Can you explain this? Where is the integrity protection? Where is the > availability specified? > >> Checksumming in tcp/ip is intended to provide intregrity protection. Error protection != integrity protection. Anyone can reconstitute the checksum, so it is not an integrity mechanism. >> Mind you it is NOT tamper proof but that is the intent. What is your definition of integrity? Mine means some assurance that what was sent is what is received. Anything that any intermediary can reconstitute trivially is not protected. >> Detection of lost packets, retransmitions, reassembly of fragments, >> congestion notification, dynamic routing and many other tcp/ip features >> are intended to address availablity. The first group (loss detection, retransmission, reassy) address links with errors, not 'availability' in the usual sense. The second set might apply, but aren't part of TCP per se (TCP uses the absence of info to indicate congestion, not the presence, at least in the required base of the protocol). > ... >>>>> It's security/resiliency can be improved. After all, if > that were not >>>>> the case, I guess you're wasting your time with TCP-AO. Or > is it that >>>>> you believe the only way to improve a protocol is to throw >>>>> crypto at it? >>>> Adding crypto improves confidentiality and integrity but is counter >>>> productive to availability as most >>>> crypto engines are prone to fairly low pps resource exhaustion >>>> attacks. > All prevention methods are susceptible to computational resource > attacks, since all increase the operations performed on a > packet. >> GTSM is a valuable exception to this statement but other then that I tend to agree:) > > It is > commonly assumed that this is a desirable tradeoff, and that the > computational resources can be totally protected with line-rate > dedicated computation (e.g., hardware assist). >> I believe that is a common assumption however I don't believe that assumption is correct. >> I do a fair amount of router testing and although some portions of >> ipv4 are hardware assisted and therefore line-rate there are still many >> paths to the "slow path". IPv6 has many more routes to the slow path:( First, I'm speaking of hardware crypto assist. I'm assuming fast-path packets. Slow-path packets are self-correcting in many routers - they're dumped when their queue overflows, or are simply processed *very* slowly. If you care about computational resources, you put in line-rate hardware, period. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknju0MACgkQE5f5cImnZruVggCguJGkydTXB9yWgK+nPfpBqQy8 izAAoIT+9Tmof98TX+0WLdYkCFcj4Ikx =ac+U -----END PGP SIGNATURE----- From touch@ISI.EDU Mon Apr 13 15:38:07 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 4D7CF3A6EDA; Mon, 13 Apr 2009 15:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 AAY2MmlPsbYu; Mon, 13 Apr 2009 15:38:05 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id B67783A6858; Mon, 13 Apr 2009 15:38:03 -0700 (PDT) Received: from [75.215.162.89] (89.sub-75-215-162.myvzw.com [75.215.162.89]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n3DMcHKi019716; Mon, 13 Apr 2009 15:38:19 -0700 (PDT) Message-ID: <49E3BED9.1030701@isi.edu> Date: Mon, 13 Apr 2009 15:38:17 -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> In-Reply-To: <49E3B9BF.1060901@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 X-Mailman-Approved-At: Tue, 14 Apr 2009 01:01:10 -0700 Cc: "'tcpm@ietf.org'" , "'ietf@ietf.org'" , 'Joe Abley' , "'opsec@ietf.org'" , 'Lars Eggert' , "'Eddy, Wesley M. \(GRC-RCN0\)\[Verizon\]'" 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: Mon, 13 Apr 2009 22:38:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: > Joe Touch wrote: > >>> The consensus seems to be that the current state of affairs is something >>> like: "a mess". Even if you do care to produce a resilient >>> implementation, that task is going to be much harder than necessary. You >>> don't know the amount of cycles we spent in producing >>> draft-gont-tcp-security.... let alone the time it would take to move the >>> advice in an actual implementation. >> Advice in making a hardened version of TCP would be useful to the >> implementation community. > > To a large extent this is what draft-gont-tcp-security is about. Implementation advice is outside the scope of the IETF. It's not even operational, IMO. >> However, if you're saying that TCP specs in general are a mess, yes they >> are. That's why we created a roadmap document, and why it needs to be >> maintained. If you're suggesting we need a clean single documentation of >> what TCP is, I might even agree. However: >> >> 1) TCPM is not the place that would generate it >> (IMO, that'd be TSVWG) >> >> 2) this document is not a step in that direction > > The tcp roadmap is a roadmap to the documents that the IETF has > published. There's lots of stuff that has not been published by the IETF > and that therefore is not discussed in the tcp roadmap. > > This is another area in which this document tries to help. Those are documents that the IETF may or may not agree with. Neither "Implemented" nor "published" doesn't mean we should endorse that solution. >> You've produced a summary of issues you feel would harden TCP. I feel >> that some of them make TCP more brittle, and some make TCP unnecessarily >> complex, and in both cases the mods are not needed in the general >> Internet. > > Is there nothing in the document with which you agree? That'd be harsh. I agree with some of the implementation advice as implementation advice. I agree that, in risk-prone environments (where packets can be tapped, e.g.), some of the recommendations are appropriate. I'm disagreeing primarily with the general tone and balance of the document. >> TCPsecure is a good example; it has caveats in its ID that >> indicate where it is useful and where it is not -- it is NOT a general >> solution for the entire Internet (the WG basically agreed to that with >> the wording for its use cases). > > c'mon Joe.. IMO, tcpsecure needed to include those statements about > usefulness in large part because it was IPR-encumbered, and in part as a > political workaround that would avoid further waste of time in endless > discussions. I disagree. Even if it weren't IPR encumbered, I would disagree with widescale deployment of a modification to TCP that answers a RST with one *or more* ACKs. As I said numerous times w.r.t. that document, the modifications it suggests are generally not needed, unnecessarily complicate packet processing, and since they don't protect from in-window injection attacks, I find them useless in the general case. >>> In many cases the lack of a straight answer may have to do with us being >>> unable to get to consensus and get something published in a timely >>> fashion. e.g., the last round on ICMP attacks against TCP was circa >>> 2004. At that point an I-D was published on the subject (now >>> draft-ietf-tcpm-icmp-attacks). Yet we're still nitpicking on it, when >>> everybody did something about it five years ago. >> Uh, well, we're deciding whether we agree with what's been deployed. >> Deploying some of these changes hasn't always been a good idea; if it >> were, we'd be agreeing to it. > > Some people prefer to get work done instead of committing/wasting lots > of cycles in endless discussions. Publishing recommendations without validating them isn't wasting time. >>> It becomes harder to get s staright answer when it's impossible for a >>> vendor to point to a counter-measure that is supposed to be the result >>> of a thorough review process, in a *timely* fashion. >> Can you be as specific here as you want us to be? What exactly does a >> vendor want that isn't provided by IPsec, TCP MD5, etc., or the existing >> known countermeasures? > > What's "the existing known counter-measures"? Limit cycles/resources available for new connections, e.g., for SYN attacks -- as is already done for things like IKE. >>> I'm aware there's an effort in the vendor community to improve the >>> resiliency of TCP basedon the document published by UK CPNI. Yet we're >>> still debating whether to ignore it or not.... maybe so that we can >>> publish an RFC in the future tagging those implementations as >>> non-compliant... or maybe to allow tcp vulnerabilities to be >>> "rediscovered" every few years. >> If the vendors are following this doc already, then we REALLY need to >> ensure it's updated with advice appropriate to the context in which it >> is deployed. > > FWIW, vendors are following the UK CPNI document. The idea of bringing > those results to the IETF is so that these results/advice can be further > discussed, more eyes look into them, and the doc is modified if it is > felt necessary. I've been saying I feel that mods are necessary, and you keep complaining. If you're here for a rubber stamp, you came to the wrong WG ;-) >> Running around saying the sky is falling for everyone isn't >> going to help. > > Who did that? We worked on this document very silently for a couple of > years. If we had wanted that "sky is falling" approach, we would have > gone to the press before showing anything (like quite a few folks have > been doing in the recent past). Or we could have announced part of this > stuff as "vulnerabilities" to the press.. The sky has been falling in this WG for several years. Although this document is the first aggregation of such recommendations, as you know it's composed of many documents you yourself have been discussing for that period in this WG.. > That wasn't the case. > > I tried to get many people to review the document, and have the document > be as objective as possible. At least for the ip-security counterpart, I > recall asking you to have a look at it before publication, even when I > knew that you'd most likely disagree with large parts of the document. > > This project is already done.... but nevertheless I'm still spending > some cycles to bring this to the IETF, because I truly believe the IETF > should work on it. Neither me nor UK CPNI have IPRs or anything on the > material covered in our document... so there's no hidden motivation in > all this. > > Honestly, I'm not sure why you always have to knock down others' efforts > on a "by default" basis, and prejudge the motivation behind those efforts. I'm asking the question I apparently keep needing to ask: Why do you think that just because something is implemented we should recommend it? Why do you think that a message that isn't expected indicates an attack to be defended against, vs. the actions of a benign endpoint? For this document, yes, this means: Does the IETF need such a document at all? If we do need such a document, is this the right content? I have a high bar for the need for modifications to TCP, and the need to propagate local solutions to every endpoint in the Internet. That is the approach I expect of others in this WG, and yes, I'll speak out when it's not the case. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknjvtgACgkQE5f5cImnZru0lwCg6zvNwRNl9SBH1QcMo4Y7xnMz vRwAoOVpLWkco+DKxLFhY26CVR2LtaJ5 =YkNg -----END PGP SIGNATURE----- From lars.eggert@nokia.com Tue Apr 14 00:54:57 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 062103A6D6B; Tue, 14 Apr 2009 00:54:57 -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 tG5KGQn5-JwY; Tue, 14 Apr 2009 00:54:56 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 4DFC13A68AC; Tue, 14 Apr 2009 00:54:55 -0700 (PDT) Received: from [10.180.41.39] ([192.100.124.156]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n3E7tlVr021648 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Apr 2009 10:55:47 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: Joe Touch In-Reply-To: <49E3BED9.1030701@isi.edu> Content-Type: multipart/signed; boundary=Apple-Mail-28--604463031; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 14 Apr 2009 10:55:41 +0300 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> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [212.213.221.39]); Tue, 14 Apr 2009 10:55:49 +0300 (EEST) X-Mailman-Approved-At: Tue, 14 Apr 2009 01:01:10 -0700 Cc: "'tcpm@ietf.org'" , "'ietf@ietf.org'" , 'Joe Abley' , "'opsec@ietf.org'" , "'Eddy, Wesley M. \(GRC-RCN0\)\[Verizon\]'" 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, 14 Apr 2009 07:54:57 -0000 --Apple-Mail-28--604463031 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On 2009-4-14, at 1:38, Joe Touch wrote: >>> Advice in making a hardened version of TCP would be useful to the >>> implementation community. >> >> To a large extent this is what draft-gont-tcp-security is about. > > Implementation advice is outside the scope of the IETF. It's not even > operational, IMO. I do believe there is value in having a document that would inform a stack vendor of various potential attack vectors against a TCP stack and what techniques exist to harden their stacks. I agree with Joe that some of the hardening techniques that vendors are implementing come with consequences (make TCP more brittle). To me, this is a *reason* this document should be published via the IETF (i.e., TCPM) - we are probably in the best position to correctly evaluate and classify the impact of various hardening techniques. Stack vendors have been putting these mechanisms in to their stacks without clear specifications and discussions of the potential upsides and downsides that would let them make an educated decision. It seems clear to me that the vendor community is looking for guidance here, and I do believe the IETF should give it. Yes, there is a fine line here, where some of the hardening techniques introduce some new assumptions on what the segment flow of a valid connection looks like, etc. It will be important to accurately describe the downsides of some of these techniques, especially where they could result in valid connections being dropped. Lars --Apple-Mail-28--604463031 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA0MTQwNzU1NDJaMCMGCSqGSIb3DQEJBDEWBBREqH3+Yywn6SkM ypipqjJrdrfJyzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAefcwn9J83NjbayLSfmaOtmOQIA8WYa2t4Z9IcLUviG+OlmZj5CdY L1D9ATmCChbP/0aJ1hi1rl57gkoJLeHVjwIT19AhHriv6bfukiNn+aiIr4HFjJobMwfFmw5muwi+ ObIPr7KZxKlwVhcepSL1iC1/LsAi6t1yGKDyqVoTNTJnlw9jjxT8z4Inu+KL7QTGIAcrh9PeKcoP Emxo5XEa3tR//A5Ie7LmRqOADOOz3OhhEiQ3Cry1iPFydvQDJOl2/aYAidtBT7jcsrwmBqENPa+c gxIJB4r3bU+Bt4pQ+H+AEx94oErvwD4sUL02V8Q00xEHMnMBziKtrMRV8A74CAAAAAAAAA== --Apple-Mail-28--604463031-- From touch@ISI.EDU Tue Apr 14 07:19:58 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 6B20728C13C; Tue, 14 Apr 2009 07:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.157, 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 GQO0U+JHeIaL; Tue, 14 Apr 2009 07:19:56 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id BBE4E3A6DE3; Tue, 14 Apr 2009 07:19:56 -0700 (PDT) Received: from [192.168.1.44] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n3EEKSc2024923; Tue, 14 Apr 2009 07:20:30 -0700 (PDT) Message-ID: <49E49BAC.8000300@isi.edu> Date: Tue, 14 Apr 2009 07:20:28 -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> <49E422C0.5050908@gont.com.ar> In-Reply-To: <49E422C0.5050908@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: "'tcpm@ietf.org'" , "'ietf@ietf.org'" , 'Joe Abley' , "'opsec@ietf.org'" , 'Lars Eggert' , "'Eddy, Wesley M. \(GRC-RCN0\)\[Verizon\]'" 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, 14 Apr 2009 14:19:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: > Joe Touch wrote: > >>>>> The consensus seems to be that the current state of affairs is something >>>>> like: "a mess". Even if you do care to produce a resilient >>>>> implementation, that task is going to be much harder than necessary. You >>>>> don't know the amount of cycles we spent in producing >>>>> draft-gont-tcp-security.... let alone the time it would take to move the >>>>> advice in an actual implementation. >>>> Advice in making a hardened version of TCP would be useful to the >>>> implementation community. >>> To a large extent this is what draft-gont-tcp-security is about. >> Implementation advice is outside the scope of the IETF. It's not even >> operational, IMO. > > RFC 816: "MODULARITY AND EFFICIENCY IN PROTOCOL IMPLEMENTATION" > RFC 815: "IP DATAGRAM REASSEMBLY ALGORITHMS" (see Section 4) > > and, > > RFC 1936: "Implementing the Internet Checksum in Hardware" (of which you > are on of the co-authors :-) ) Those are informational, you will note. > That said, to a large extent the document is provides advise about > enforcing stricter validation checks, timeouts where appropriate, and > about a number of policies that may improve TCP's resiliency/security > (e.g., how to select ISN's, etc.) Those 'validation checks' aren't validations when they exceed the TCP specifications. >>>> You've produced a summary of issues you feel would harden TCP. I feel >>>> that some of them make TCP more brittle, and some make TCP unnecessarily >>>> complex, and in both cases the mods are not needed in the general >>>> Internet. >>> Is there nothing in the document with which you agree? >> That'd be harsh. I agree with some of the implementation advice as >> implementation advice. I agree that, in risk-prone environments (where >> packets can be tapped, e.g.), some of the recommendations are appropriate. >> >> I'm disagreeing primarily with the general tone and balance of the document. > > I believe at this point in time we're deciding whether it makes sense to > work on this document, and where it would make sense to do it. > draft-gont-tcp-security-00 is just a starting point. Of course, it > represents my pov, and to some extent the pov of the reviewers. But the > idea of bringing it to the IETF is that future versions of the document > represent wg consensus. > > If you have specific suggestions on how to improve the document, I'll be > more than happy to hear about them. > > However, I believe at this point we are not yet discussing on any > specific issue discussed in the draft, but are trying to agree on how to > move forward. (Feedback on the technical details in the document is > nevertheless welcome, though) Agreed. I'm suggesting that there are several possible documents, with different possible 'homes': 1. a document that focuses on implementing a hardened TCP that is outside the scope of the IETF, esp. where it exceeds IETF recommendations for modifications to TCP 2. a document that summarizes and streamlines TCP modifications i.e., this would be somewhat like a 793-bis; that's a huge undertaking, and would belong in TSVWG rather than TCPM If this document is intended to be an IETF product, rather than an informational individual contribution, it needs to reflect IETF consensus. >>> c'mon Joe.. IMO, tcpsecure needed to include those statements about >>> usefulness in large part because it was IPR-encumbered, and in part as a >>> political workaround that would avoid further waste of time in endless >>> discussions. >> I disagree. Even if it weren't IPR encumbered, I would disagree with >> widescale deployment of a modification to TCP that answers a RST with >> one *or more* ACKs. As I said numerous times w.r.t. that document, the >> modifications it suggests are generally not needed, unnecessarily >> complicate packet processing, and since they don't protect from >> in-window injection attacks, I find them useless in the general case. > > TCP is already very complicated. And the implementation of the > countermeasures in tcpsecure usually require not much more than > (literally) a couple of additional lines, or a slight modification in > some conditional statement. The number of lines alone does not reflect the complexity issue; the way it complicates interactions is. >>>>> It becomes harder to get s staright answer when it's impossible for a >>>>> vendor to point to a counter-measure that is supposed to be the result >>>>> of a thorough review process, in a *timely* fashion. >>>> Can you be as specific here as you want us to be? What exactly does a >>>> vendor want that isn't provided by IPsec, TCP MD5, etc., or the existing >>>> known countermeasures? >>> What's "the existing known counter-measures"? >> Limit cycles/resources available for new connections, e.g., for SYN >> attacks -- as is already done for things like IKE. > > At the point in which you actually try to put this into code, a number > of questions arise that need to be answered. Why should vendors rehash > the same analysis over an over again (with the potential of doing it > wrong, which would lead to buggy implementations), when we could put out > a document with consensus on the preferable way to do those things. Showing a way to do something is useful; claiming it is preferred requires consensus. The IETF doesn't specify preferred implementations; it does give them as examples, but they tend to be in informational individual documents rather than as WG product. >>> FWIW, vendors are following the UK CPNI document. The idea of bringing >>> those results to the IETF is so that these results/advice can be further >>> discussed, more eyes look into them, and the doc is modified if it is >>> felt necessary. >> I've been saying I feel that mods are necessary, and you keep >> complaining. > > That's not how I read your comments. If your point of view is "it would > be interesting to work on this. however, i believe the document should > be modified in this way, because of this reason" that's one thing. > > If your pov is "we don't need this. go somewhere else", that's something > entirely different. IMO, the IETF doesn't need to spend group cycles to work on how to implement TCP efficiently or in safe ways. That's software engineering, and may be a good idea or even a good individual submission, but not what I think of as WG effort. If this doc is intended to be a WG product, it needs to focus on reflecting IETF consensus and recommendations. Its current focus is "what is implemented", as if that is sufficient rationale. ... >> The sky has been falling in this WG for several years. Although this >> document is the first aggregation of such recommendations, as you know >> it's composed of many documents you yourself have been discussing for >> that period in this WG.. > > I'd probably argue that the case with tcpm is that at (many) times > protocol specifications have been taken as if they were casted in stone. > And unless one is part of some small circle of people that is supposed > to have been allowed by God to modify such specs, it will be very hard > there's no effort that takes less than quite a few years. We are conservative. We're talking about changes that affect the core of the Internet, so that is appropriate. Whether a modification is accepted as standards track or not is based on whether it is **generally** needed, not whether it has been implemented or even deployed. I'm not quite sure of what small circle you're referring to, but the primary mods to the standards track over the past few years have been in ways that were supported by a large pile of analysis, e.g., increasing TCP's initial window. When people come without that pile, they're challenged. A pile of code is not a substitute for a pile of analysis. > Very loud people take the time to maintain endless discussions, and most > mere mortals that need to get work done end up completely avoiding tcpm > altogether, because it requires a huge spend of time. > > Virtually every developer that I know of won't care about what the end > result in tcpm is. At most, they will post a question to hear comments. > But that's it. To a large extent people cannot believe the amount of > energy we spend for such a null progress. > > Example: ICMP attacks draft (draft-ietf-tcpm-icmp-attacks). > The doc was reviewed by devolpers from Sun, FreeBSD, NetBSD, OpenBSD, > Linux, extreme networks, and Cisco (this last one "unofficially"). To > them, the draft looks okay. Many other people have also agreed with > that. But I cannot get those folks involved in our endless discussions. > The ROI for them is NULL. > > Do they care about the outcome? Not really. They agree with the > proposal, it is in the code already, and has been running for years. > They just let us waste our time. > > I agree that there are benefits to be gained from having a more > conservative philosophy, to put it some way. I believe that it is a good > thing to challenge proposals, to aim at improving their quality, etc. > This has helped improve many documents, including those I have authored. > But I believe at some point it starts looking as "everything that > neither me or my inner circle proposes will be banned". TCPM exists as much to protect TCP from tweaking as it is to mature proposed tweaks. The more tweaks anyone proposes, the more they get challenged. The less analysis behind the proposals, the more they get challenged. Deployed code is not a substitute for analysis. It's unfortunate if you feel personally affected by that approach, but it's simply cause and effect. **ALL** documents in this WG are challenged, and the bar in this WG is higher than in other WGs - and it should be. If your goal is making progress more quickly, you need to create your own protocol to modify. >>> Honestly, I'm not sure why you always have to knock down others' efforts >>> on a "by default" basis, and prejudge the motivation behind those efforts. >> I'm asking the question I apparently keep needing to ask: >> >> Why do you think that just because something is implemented >> we should recommend it? > > That's not how the tcp-security document was produced. For instance, > many of the recommendations had never been implemented. And the document > argues *against* some common implementation strategies. Agreed; those are not the parts I'm as concerned with. >> Why do you think that a message that isn't expected indicates >> an attack to be defended against, vs. the actions of a >> benign endpoint? > > We simply raise the bar about what we react to. If there are packets for > which there's no legitimate use, we don't react to them (if this doesn't > cause harm). When a packet arrives that *could* have been legitimate, i.e., for which there is *any* legitimate use, you have an obligation to react to it. I don't agree that some of what you're proposing takes this into account. >> I have a high bar for the need for modifications to TCP, and the need to >> propagate local solutions to every endpoint in the Internet. > > And do you believe that such propagation depends on our outcome? -- > Thanks God, it doesn't. Try to find any implementation that is > fully-compliant with the RFCs, and let me know if you find any. > > The lack of advice on all these issues has put vendors in a position in > which they have to figure out that advice by themselves. Sometimes they > got to the right answers, sometimes not. > > Have a look at the vulnerability advisories referenced in the I-D: the > same errors are committed over and over again. > > draft-gont-tcp-security is an effort to help the vendor/developer > community in that area. I agree that vendors need some sort of implementation advice. I don't agree that the IETF needs to be the place where that is made. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknkm6wACgkQE5f5cImnZrsZbQCg4F5I57j8Zz/wTSsnjfN7dhrx tqMAoNaM+MmXCJc6yvsvwXUc52cn+ZaB =9V8t -----END PGP SIGNATURE----- From joelja@bogus.com Tue Apr 14 07:56: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 738513A68ED; Tue, 14 Apr 2009 07:56: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 y8cFYg57EBUF; Tue, 14 Apr 2009 07:56:34 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 3A3213A6B0D; Tue, 14 Apr 2009 07:56:34 -0700 (PDT) Received: from [172.168.1.113] (adsl-76-205-24-189.dsl.pltn13.sbcglobal.net [76.205.24.189]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id n3EEvdsG047791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 14 Apr 2009 14:57:41 GMT (envelope-from joelja@bogus.com) Message-ID: <49E4A45B.4040402@bogus.com> Date: Tue, 14 Apr 2009 07:57:31 -0700 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.21 (X11/20090409) 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> 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/9233/Tue Apr 14 09:45:01 2009 on nagasaki.bogus.com X-Virus-Status: Clean Cc: 'Joe Abley' , "'opsec@ietf.org'" , "'tcpm@ietf.org'" , Joe Touch 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, 14 Apr 2009 14:56:35 -0000 IETF list omitted for brevity... I think this is exactly the kind of discussion that this document needed, and I glad that we've finally managed to stimulate it. In my own opinion: I do belive that implementation advice is in scope for the ietf. We should plow operational experience with our protocol stack and it's limitations back into the standards process, We should avoid producing advice on general cases that would result in protocols becoming more rather than less brittle except when absolutely necessary. We should be mindful that existing deployed implementations are unlikely to change based solely on recommendations. joel Lars Eggert wrote: > Hi, > > > > On 2009-4-14, at 1:38, Joe Touch wrote: >>>> Advice in making a hardened version of TCP would be useful to the >>>> implementation community. >>> >>> To a large extent this is what draft-gont-tcp-security is about. >> >> Implementation advice is outside the scope of the IETF. It's not even >> operational, IMO. > > I do believe there is value in having a document that would inform a > stack vendor of various potential attack vectors against a TCP stack and > what techniques exist to harden their stacks. > > I agree with Joe that some of the hardening techniques that vendors are > implementing come with consequences (make TCP more brittle). To me, this > is a *reason* this document should be published via the IETF (i.e., > TCPM) - we are probably in the best position to correctly evaluate and > classify the impact of various hardening techniques. Stack vendors have > been putting these mechanisms in to their stacks without clear > specifications and discussions of the potential upsides and downsides > that would let them make an educated decision. It seems clear to me that > the vendor community is looking for guidance here, and I do believe the > IETF should give it. > > Yes, there is a fine line here, where some of the hardening techniques > introduce some new assumptions on what the segment flow of a valid > connection looks like, etc. It will be important to accurately describe > the downsides of some of these techniques, especially where they could > result in valid connections being dropped. > > Lars > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From Donald.Smith@qwest.com Tue Apr 14 08:19:45 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 389C83A6AF6; Tue, 14 Apr 2009 08:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6WNdKv7LTdz; Tue, 14 Apr 2009 08:19:44 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by core3.amsl.com (Postfix) with ESMTP id F40CB3A69FF; Tue, 14 Apr 2009 08:19:43 -0700 (PDT) Received: from sudnp796.qintra.com (sudnp796.qintra.com [151.116.2.212]) by sudnp799.qwest.com (8.14.0/8.14.0) with ESMTP id n3EFKnFX018059; Tue, 14 Apr 2009 09:20:49 -0600 (MDT) Received: from qtdenexhtm21.AD.QINTRA.COM (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.0/8.14.0) with ESMTP id n3EFKf6W005198; Tue, 14 Apr 2009 09:20:42 -0600 (MDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm21.AD.QINTRA.COM ([151.119.91.230]) with mapi; Tue, 14 Apr 2009 09:20:42 -0600 From: "Smith, Donald" To: "'Joe Touch'" , "'Fernando Gont'" Date: Tue, 14 Apr 2009 09:20:41 -0600 Thread-Topic: [OPSEC] [tcpm] draft-gont-tcp-security Thread-Index: Acm811oKZ1TOpUQ2Qjei9FPovceZAgAOO5Bg Message-ID: References: <49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu> <49E39119.1060902@gont.com.ar> <49E3A856.9020703@isi.edu> In-Reply-To: <49E3A856.9020703@isi.edu> 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: "'tcpm@ietf.org'" , "'ietf@ietf.org'" , 'Joe Abley' , "'opsec@ietf.org'" , 'Lars Eggert' , "'Eddy, Wesley M. \(GRC-RCN0\)\[Verizon\]'" 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, 14 Apr 2009 15:19:45 -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 Joe Touch > Sent: Monday, April 13, 2009 3:02 PM > To: Fernando Gont > Cc: tcpm@ietf.org; ietf@ietf.org; Joe Abley; opsec@ietf.org;=20 > Lars Eggert; Eddy,Wesley M. (GRC-RCN0)[Verizon] > Subject: Re: [OPSEC] [tcpm] draft-gont-tcp-security >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 >=20 >=20 > Fernando Gont wrote: > > Joe Touch wrote: > >=20 > >>> So we had tcp-secure in 2004, icmp-attacks in 2005, a claim for a > >>> trivial attack in 2008 (Outpost24/CERT-FI), and we'll=20 > probably continue > >>> in this line, because we do nothing about it. > >> Whether we have this document or not, we will continue to=20 > have people > >> who incorrectly assume that TCP is secure. > >=20 > > That's correct. But we also have people that do know it is=20 > not mean to > > be secure, but that it should be resilient enough so that it's still > > usable. One way or another, most stacks implement=20 > counter-measures for > > SYN-floods (on which tcpm did publish something), timers on the > > FIN-WAIT-2 state, port randomization (on which tsvwg is=20 > working), ICP > > ISN randomization, etc. > >=20 > > The reason for which they did that was to improve TCP's=20 > security/resiliency. > >=20 > > Would you argue in favour of predictable ISNs, predictable ports, > > time-less FIN-WAIT-2 state, etc.? -- I hope you wouldn't. >=20 > These measures can be used to reduce the impact of attacks when TCP is > not secured. However, they DO NOT make TCP secure. They DO=20 > make TCP more > brittle - they limit the way in which two legitimate endpoints can do > legitimate things. >=20 > >>>> It summarizes issues already raised by the WG,=20 > >>> I believe this statement is unfair with respect to our=20 > document. e.g., > >>> has the issues described in Section 4.3, Section 9.2, or=20 > Section 10 been > >>> brought to tcpm before??? > >> I didn't say that's all it does ;-) Agreed that it raises=20 > other issues, > >> many of which are operational. > >=20 > > Many of which arise if you expect to use TCP in some other=20 > scenario that > > just two computers in a LAN. If that makes those issues=20 > "operational", I > > agree. >=20 > Many of those don't arise for computers in a wide area, or=20 > with millions > of other computers on the network either. They arise only=20 > when there are > active attacks, and only for some kinds of attackers=20 > (on-path, off-path, > high-speed access, etc.) >=20 > IMO, any decision which would be enabled or disabled depending on > whether security was a concern or performance was needed is=20 > operational. > E.g., port randomization helps only when attackers are=20 > off-path and when > port use is a fraction of the active port space. That's operational. > Ditto for ISN randomization. Given that this is opsec and that my major concern is the network elements= =20 I am much more concerned about "off-path" or "blind attacks" then direct at= tacks. Customers generally don't attack the router they are connected to. Peers generally don't attack the router they are connected to. >=20 > I.e., if the protection is not needed in the absence of=20 > attacks, it may > be operational. >=20 > >>>> TCP itself is not a secure protocol, nor is it intended to be. > >>> Yeah. But that does not mean that we should not do our=20 > best to improve > >>> it. > >> It means we should not try to give the incorrect impression that it > >> *can* be secured.=20 > >=20 > > It's security/resiliency can be improved. After all, if=20 > that were not > > the case, I guess you're wasting your time with TCP-AO. Or=20 > is it that > > you believe the only way to improve a protocol is to throw=20 > crypto at it? >=20 > I *know* that the only way to secure a protocol is to throw=20 > crypto at it. Now I think I understand what you mean by secure. I don't agree with your opinion. For example SSL is a form of encryption bu= t has done little to secure http as sites have trained customers to ignore cert errors. Banks put lock bitmaps on their pages to show how "safe" they are. Phishers depend on this user confusion! >=20 > I also *know* that unexpected packets are *not* indications=20 > of attacks. In the router world packets destined towards my routers that are "unexpecte= d" are often an indication of attack or a misconfigured system either can cause problems= for the network and blocking it TOWARDS the router is a BCP. >=20 > These two things are not evident in this document, and should be. > Further, this document should make a case as to whether the=20 > improvements > are operational or not. AFAICT, most are operational. >=20 > >> Interpreting every unexpected event as an attack makes > >> a protocol robust but also brittle; TCP is intended to=20 > trade flexibility > >> for security, AFAICT, because it is agnostic about intent,=20 > and gives the > >> benefit of doubt at all times.=20 > >=20 > > I would prefer that instead of making this type of broad=20 > statement, you > > would argue against a particular recommendation in > > draft-gont-tcp-security, and explain how it makes TCP more brittle. >=20 > Randomizing ports and ISNs assumes there is a window over which some > values are NOT used; that window precludes legitimate exchanges from > occurring. That is what I mean by "brittle." >=20 > >> Consider packet drops. That can happen due to loss, non-malicious > >> corruption, or jamming, e.g. In the last case, it makes=20 > sense to blast > >> copies of packets in the hopes of getting something=20 > through, but that's > >> NOT what we assume. > >=20 > > Wasn't this very behavior what lead to the Internet=20 > congestion collapse > > in the 80's, or am I missing something? >=20 > Loss of a segment can mean: > a) congestion (correlated drops) > b) non-correlated drops (not related to increasing traffic) > c) active removal (attack) >=20 > If (a), then you backoff. That's how congestion collapse was=20 > addressed. >=20 > If you believe that packet drops are caused by either non-correlated > drops or active removal, you send MORE - you send copies of=20 > each packet, > e.g. That is NOT what we assume, but what I presume you ought to > recommend in a document that assumes that every event that COULD have > been an attack probably is an attack. >=20 > >>> Please talk to vendors. I don't want to reproduce here=20 > what seems to > >>> be the consensus among vendors with respect to the=20 > current state of > >>> affairs in terms of how up-to-date our specs are. > >> Vendors misapply our protocols then complain that they=20 > don't work. Yes, > >> there are operational issues, but one severe operational=20 > issue is not > >> using security for some policy, financial, or operation=20 > expense and then > >> complaining that nonsecure TCP is being attacked. > >=20 > > Joe, we're talkng about a simple web server being taken=20 > down because of > > a SYN flood, a FIN-WAIT-2 flood, or the like. Even the most=20 > stupid web > > server should survive these types of attacks. >=20 > If you're talking about implementation advice (don't put all your > resources in pending connections), I agree that a good implementation > should be implemented well. But that's operational / implementation > advice, not protocol advice. >=20 > I do not agree that all web servers should implement SYN cookies, e.g. >=20 > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >=20 > iEYEARECAAYFAknjqFYACgkQE5f5cImnZrtBNwCgiJPsTDBt34Im+s/TFkBm90DE > Xn4AoNlUvCAucvZoVVMTpex4sMXAaXb2 > =3D1ijT > -----END PGP SIGNATURE----- > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > = From touch@ISI.EDU Tue Apr 14 08:29:36 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 9792C3A6DCC; Tue, 14 Apr 2009 08:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 kL2CS0Qy0X3I; Tue, 14 Apr 2009 08:29:35 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id B6B753A6DE3; Tue, 14 Apr 2009 08:29:35 -0700 (PDT) Received: from [192.168.1.44] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n3EFUAtR011014; Tue, 14 Apr 2009 08:30:12 -0700 (PDT) Message-ID: <49E4AC01.5060104@isi.edu> Date: Tue, 14 Apr 2009 08:30:09 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Smith, Donald" References: <49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu> <49E39119.1060902@gont.com.ar> <49E3A856.9020703@isi.edu> In-Reply-To: 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: "'tcpm@ietf.org'" , "'ietf@ietf.org'" , 'Joe Abley' , "'opsec@ietf.org'" , 'Lars Eggert' , "'Eddy, Wesley M. \(GRC-RCN0\)\[Verizon\]'" 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, 14 Apr 2009 15:29:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Inline... > Given that this is opsec and that my major concern is the network elements > I am much more concerned about "off-path" or "blind attacks" then direct attacks. > Customers generally don't attack the router they are connected to. > Peers generally don't attack the router they are connected to. Some routers are on shared-access media. Other routers are connected across unsecured network elements - e.g., to network management components, etc. On-path doesn't mean directly connected on one hop - it includes the entire path. ... >> > I *know* that the only way to secure a protocol is to throw >> > crypto at it. > > Now I think I understand what you mean by secure. > I don't agree with your opinion. For example SSL is a form of encryption > but has done little to > secure http as sites have trained customers to ignore cert errors. > Banks put lock bitmaps on their pages to show how "safe" they are. > Phishers depend on this user confusion! Mechanism cannot compensate for users that ignore it. >> > I also *know* that unexpected packets are *not* indications >> > of attacks. > > In the router world packets destined towards my routers that are > "unexpected" are often an indication of attack or a misconfigured > system either can cause problems for the network and blocking it > TOWARDS the router is a BCP. I'm talking about expectations within a TCP connection, or about the establishment of TCP connections. This doc addresses TCP, not the Internet in general. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknkrAEACgkQE5f5cImnZrvCuwCgmNXYuIsIz0D3sKZPGPS4s9I/ a4UAn1Y61FP4a45kZdAtGelzTp4ah51O =Z6sO -----END PGP SIGNATURE----- From fernando.gont.netbook.win@gmail.com Tue Apr 14 11:12: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 6D9AD3A6E31; Tue, 14 Apr 2009 11:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 fbLNVqmelL18; Tue, 14 Apr 2009 11:12:39 -0700 (PDT) Received: from mail-gx0-f163.google.com (mail-gx0-f163.google.com [209.85.217.163]) by core3.amsl.com (Postfix) with ESMTP id 5E7293A6E1F; Tue, 14 Apr 2009 11:12:39 -0700 (PDT) Received: by gxk7 with SMTP id 7so573009gxk.13 for ; Tue, 14 Apr 2009 11:13:50 -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=fV/JPQL733nZWB41/rMJagl/yIHeoNhAAEsSstTUcRk=; b=vAlZsIpuJ92c+2uV6RDgHKYqaIE4nPAOBPkm1PjRggkCOOOK9I6hoEuz0UmncvxJ/0 rxT/JTjB7e5bgeZLLmmJ+rm4MVVZx+kJ+/xaGsBU8m+t+x9lRRJxArwD88LIlFzem2UN RHEcPj612cB+JIQnRV8+D17Lg6cKCvZ7eyc28= 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=HFhJLFOxzkKttO3vbX4oCvfAagmujZWqKF3FIZnwiuKwMpzKqVTcww+yBS4Y/y2FuI /gFqVAfOObl7x3vedYElnIwDVJBzQHzvR3U8rq3hzqXts5mApJ5lIa0UYkI6Gcy8QkDn lMerUsqiXaRKD6FrRIgPCvX1uVcIR79LVuxCY= Received: by 10.100.45.9 with SMTP id s9mr10485951ans.133.1239732830709; Tue, 14 Apr 2009 11:13:50 -0700 (PDT) Received: from ?172.16.1.133? (host4.190-139-184.telecom.net.ar [190.139.184.4]) by mx.google.com with ESMTPS id 6sm531735yxg.30.2009.04.14.11.13.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 14 Apr 2009 11:13:49 -0700 (PDT) Sender: Fernando Gont Message-ID: <49E4D257.40504@gont.com.ar> Date: Tue, 14 Apr 2009 15:13:43 -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> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'tcpm@ietf.org'" , "'ietf@ietf.org'" , Joe Touch , 'Joe Abley' , "'opsec@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, 14 Apr 2009 18:12:40 -0000 Lars Eggert wrote: > I agree with Joe that some of the hardening techniques that vendors are > implementing come with consequences (make TCP more brittle). To me, this > is a *reason* this document should be published via the IETF (i.e., > TCPM) - we are probably in the best position to correctly evaluate and > classify the impact of various hardening techniques. Stack vendors have > been putting these mechanisms in to their stacks without clear > specifications and discussions of the potential upsides and downsides > that would let them make an educated decision. It seems clear to me that > the vendor community is looking for guidance here, and I do believe the > IETF should give it. This is the reason for which the output of the CPNI project was submitted as an IETF I-D. 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 fernando.gont.netbook.win@gmail.com Tue Apr 14 11:34:54 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 8D93128C20E; Tue, 14 Apr 2009 11:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 l6NbMTWe0e8n; Tue, 14 Apr 2009 11:34:53 -0700 (PDT) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.248]) by core3.amsl.com (Postfix) with ESMTP id 5E78E28C20F; Tue, 14 Apr 2009 11:34:52 -0700 (PDT) Received: by ag-out-0708.google.com with SMTP id 23so1264150agd.12 for ; Tue, 14 Apr 2009 11:36:03 -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=rVFU2xr2gLNcl2gqS0LzqIh7K8bb/pdodTsPZOr5SEI=; b=mH2q+Y8q5ugZLSo6BzKHZewGZICWKcJ8dSTfPUPnL7J92xhsSkLccQzsQXldVLmdXM bAJt+y2qMr740wcqDCJ5sWmobSx8YnGXrqEXPKU6/Mm9P7o86BNmwWR5xwN7xrArWH25 HrcTyaWnVLjPv2z9zsTnFrkFTr1rymSMAZGb4= 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=LP4Bdea5rmw+1Ne2gmCDzn9/+ycokHKL/BPnyX3XD/BQ2lQlefgl111B8fE0NJYTgR xl/I5WeSiP1A/FTEPI+FJArBUD7+MCY4mdzn8j2C8uhtPWjoqFVSCnvHQTGwOOZw5K5J wqjA6RxMrt0FFqTfTNZ5gC9hZfdTnNyLSb8IA= Received: by 10.90.88.16 with SMTP id l16mr10101126agb.112.1239734163524; Tue, 14 Apr 2009 11:36:03 -0700 (PDT) Received: from ?172.16.1.133? (host101.190-139-184.telecom.net.ar [190.139.184.101]) by mx.google.com with ESMTPS id 6sm264661agb.10.2009.04.14.11.36.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 14 Apr 2009 11:36:02 -0700 (PDT) Sender: Fernando Gont Message-ID: <49E4D78D.20004@gont.com.ar> Date: Tue, 14 Apr 2009 15:35:57 -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> <49E4A45B.4040402@bogus.com> In-Reply-To: <49E4A45B.4040402@bogus.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'Joe Abley' , "'opsec@ietf.org'" , "'tcpm@ietf.org'" , Lars Eggert , Joe Touch 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, 14 Apr 2009 18:34:54 -0000 Hello, Joel, > I do belive that implementation advice is in scope for the ietf. > > We should plow operational experience with our protocol stack and it's > limitations back into the standards process, > > We should avoid producing advice on general cases that would result in > protocols becoming more rather than less brittle except when absolutely > necessary. > > We should be mindful that existing deployed implementations are unlikely > to change based solely on recommendations. Do you have a possible action plan to pursue this effort? 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 tglassey@earthlink.net Tue Apr 14 12:22:37 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 CF05A28C1B9; Tue, 14 Apr 2009 12:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_LIST=2.3] 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 8FsyJ-vuMFak; Tue, 14 Apr 2009 12:22:37 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id D21FB28C1B5; Tue, 14 Apr 2009 12:22:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ELMvYCbh+jvv0ubaw5sa+uuFZtDbE65BIFf6OzXhtS2DTBhp08l5OANDhMZ8PUYj; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [38.104.134.74] (helo=[192.168.1.138]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LtoCm-0005aN-1E; Tue, 14 Apr 2009 15:22:00 -0400 Message-ID: <49E4E233.9040609@earthlink.net> Date: Tue, 14 Apr 2009 12:21:23 -0700 From: Todd Glassey 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> In-Reply-To: <49E4D257.40504@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79bd0f68e3a5c852fb565124da4159354c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 38.104.134.74 X-Mailman-Approved-At: Tue, 14 Apr 2009 16:03:58 -0700 Cc: "'tcpm@ietf.org'" , "'ietf@ietf.org'" , Joe Touch , 'Joe Abley' , "'opsec@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: Tue, 14 Apr 2009 19:22:37 -0000 Fernando Gont wrote: > Lars Eggert wrote: > > >> I agree with Joe that some of the hardening techniques that vendors are >> implementing come with consequences (make TCP more brittle). To me, this >> is a *reason* this document should be published via the IETF (i.e., >> TCPM) - we are probably in the best position to correctly evaluate and >> classify the impact of various hardening techniques. Stack vendors have >> been putting these mechanisms in to their stacks without clear >> specifications and discussions of the potential upsides and downsides >> that would let them make an educated decision. It seems clear to me that >> the vendor community is looking for guidance here, and I do believe the >> IETF should give it. >> > > This is the reason for which the output of the CPNI project was > submitted as an IETF I-D. > Yeah - so then this would be tested across all of the local TCP implementations including the MS, AT&T *(i.e. Lachman Associates Inc) and possibly Mentat's fast system? > Kind regards, > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.0.238 / Virus Database: 270.11.57/2059 - Release Date: 04/14/09 14:52:00 > > From lars.eggert@nokia.com Wed Apr 15 00:16:32 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 EDAB93A6BAB; Wed, 15 Apr 2009 00:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 KxbJlxzh3Nfm; Wed, 15 Apr 2009 00:16:32 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 293B03A6B98; Wed, 15 Apr 2009 00:16:30 -0700 (PDT) Received: from [IPv6:2001:2060:40:2:219:e3ff:fe06:dc74] ([IPv6:2001:2060:40:2:219:e3ff:fe06:dc74]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n3F7HJqk064106 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 15 Apr 2009 10:17:21 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: Todd Glassey In-Reply-To: <49E4E233.9040609@earthlink.net> Content-Type: multipart/signed; boundary=Apple-Mail-69--520365169; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 15 Apr 2009 10:17:19 +0300 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> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Wed, 15 Apr 2009 10:17:22 +0300 (EEST) Cc: "'tcpm@ietf.org'" , "'ietf@ietf.org'" , Joe Touch , 'Joe Abley' , "'opsec@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: Wed, 15 Apr 2009 07:16:33 -0000 --Apple-Mail-69--520365169 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, Todd, On 2009-4-14, at 22:21, Todd Glassey wrote: > Fernando Gont wrote: >> Lars Eggert wrote: >>> I agree with Joe that some of the hardening techniques that >>> vendors are >>> implementing come with consequences (make TCP more brittle). To >>> me, this >>> is a *reason* this document should be published via the IETF (i.e., >>> TCPM) - we are probably in the best position to correctly evaluate >>> and >>> classify the impact of various hardening techniques. Stack vendors >>> have >>> been putting these mechanisms in to their stacks without clear >>> specifications and discussions of the potential upsides and >>> downsides >>> that would let them make an educated decision. It seems clear to >>> me that >>> the vendor community is looking for guidance here, and I do >>> believe the >>> IETF should give it. >>> >> >> This is the reason for which the output of the CPNI project was >> submitted as an IETF I-D. >> > Yeah - so then this would be tested across all of the local TCP > implementations including the MS, AT&T *(i.e. Lachman Associates Inc) > and possibly Mentat's fast system? Nothing would be "tested", the IETF isn't in the business of auditing TCP stacks. What we're talking about is describing attack vectors, potential countermeasures and the the impact (downsides) those countermeasures might come with. Implementors will need to decide for themselves if and how to apply any of these techniques to their stacks. Lars --Apple-Mail-69--520365169 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA0MTUwNzE3MjBaMCMGCSqGSIb3DQEJBDEWBBSSn2e9WQWGdMA9 e22FMJ0HHudOYzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAV273PUT8G+6aJDYm5JLQl2CNgVT9UCd5/iib8786AoCnc9JEZfun kGgkluGmlydWO1iqs6gJhF18Qn0KUXZdaryFuic8z5Ig+A4GS+Q4wNnxZ/nIGMgw0kH8EyNhjzye o4C2XBnOqbgBqfx/VHMv00NSFW5undLqIfI7xXLyQlwnaRmQZz9hGXgBCg3/WRZa69F3IV7gcd4U 20+D6qLQqENDMirkP5cO0hdYAiH9gfzaf1yFnltno03JkNyPIWErFXd6/qcZ2gjhquuUc/1PUuVW ZmHFDCOmEuhvEbFWOSa+vmC3GYV3ZBN+MF7TkmkfmkBrdOpi7LjBpsOUJvmV6gAAAAAAAA== --Apple-Mail-69--520365169-- From lars.eggert@nokia.com Wed Apr 15 08:13: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 4DDDB3A697A; Wed, 15 Apr 2009 08:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 vrCEKjYZpM46; Wed, 15 Apr 2009 08:13:22 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 848423A6944; Wed, 15 Apr 2009 08:13:21 -0700 (PDT) Received: from [IPv6:2001:2060:40:2:219:e3ff:fe06:dc74] ([IPv6:2001:2060:40:2:219:e3ff:fe06:dc74]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n3FFEDg4046102 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 15 Apr 2009 18:14:14 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: Todd Glassey In-Reply-To: <49E5F36D.7020808@earthlink.net> Content-Type: multipart/signed; boundary=Apple-Mail-8--491751556; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 15 Apr 2009 18:14:13 +0300 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> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Wed, 15 Apr 2009 18:14:15 +0300 (EEST) Cc: "'tcpm@ietf.org'" , "'ietf@ietf.org'" , Joe Touch , 'Joe Abley' , "'opsec@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: Wed, 15 Apr 2009 15:13:23 -0000 --Apple-Mail-8--491751556 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On 2009-4-15, at 17:47, Todd Glassey wrote: > Lars Eggert wrote: >> Nothing would be "tested", the IETF isn't in the business of auditing >> TCP stacks. > Yo Lars Good-morning, let me respond. "Sure it is..." let me amplify - > > Don't the IETF standards processes "require the development of two or > more independent implementations of any given protocol specification > and > the associated interoperability testing to document that the suite > runs > as advertised in the specification?" this is required when moving from Proposed Standard to Draft Standard. (Also, what RFC are you quoting in the previous paragraph?) This doesn't apply to the document we're discussing here, because: >> What we're talking about is describing attack vectors, potential >> countermeasures and the the impact (downsides) those countermeasures >> might come with. Implementors will need to decide for themselves if >> and how to apply any of these techniques to their stacks. > Which would be filed as a Use Case Document as a set lf BCP's for a > protocol stanadard. This by the way is where the real value of the > IETF > comes in - in also telling people how to and how not to use these > protocols. Yes, it is likely that whatever the outcome is, the document would be published as Informational or BCP. Lars --Apple-Mail-8--491751556 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA0MTUxNTE0MTNaMCMGCSqGSIb3DQEJBDEWBBSGaD9k6ujSBpmQ e+RjH2JSDdpY+jCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAH+EqL9M8xqKnh08WeyMxaSPBL8hsiqCwqgXeJ2xNY/InodiwCZLS htAgqRqKFbG9gVTV1nPmNTiQR5JNsatELiftw5jzRY9jWlyoYG6UeDQD83HF+YL6apPpoVMEu4iB m/+bo/kwJ7/vJKjhQT1xlga+zu0ZXOnxE9srUhwbnoKIy0qZAJYFmwjPcndlkVx9EeI/HJHVaR3F dprkEUvvwxhxSXRM4n09Mf/7gfa7fljRTiHQpu6TNv24vCrRoJqVSLaLFXb8+lppu4CiBxE18YgO yRzMevjxfbPz91/Mgri4YtNr7kiFZajwe0QNR/yexXmITsWoIp4UUwzcyOaB+QAAAAAAAA== --Apple-Mail-8--491751556-- From joelja@bogus.com Thu Apr 16 11:21:49 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 9BA8B3A6B43 for ; Thu, 16 Apr 2009 11:21:49 -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 ujI6xhIKRep3 for ; Thu, 16 Apr 2009 11:21:49 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id C543A3A6993 for ; Thu, 16 Apr 2009 11:21:48 -0700 (PDT) Received: from [205.226.9.186] ([205.226.9.186]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id n3GIMH1f010746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 16 Apr 2009 18:22:59 GMT (envelope-from joelja@bogus.com) Message-ID: <49E77753.1080100@bogus.com> Date: Thu, 16 Apr 2009 11:22:11 -0700 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: opsec wg mailing list References: <49D461DD.3000101@bogus.com> In-Reply-To: <49D461DD.3000101@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/9247/Thu Apr 16 16:05:15 2009 on nagasaki.bogus.com X-Virus-Status: Clean Subject: Re: [OPSEC] Working Group Last Call draft-ietf-opsec-blackhole-urpf-03.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, 16 Apr 2009 18:21:49 -0000 Deadline is tomorrow... no opposition has so far been proffered, thanks joel Joel Jaeggli wrote: > This announcement is for working group last call on: > > http://tools.ietf.org/html/draft-ietf-opsec-blackhole-urpf-03.txt. > > Please send your comments to the list by Friday April 17, 2009. > > Thanks > Joel > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > From warren@kumari.net Thu Apr 16 13:03:28 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 598413A6F81 for ; Thu, 16 Apr 2009 13:03:28 -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 BNz1utzcMkaB for ; Thu, 16 Apr 2009 13:03:27 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 1B4CD3A6F7B for ; Thu, 16 Apr 2009 13:03:26 -0700 (PDT) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id n3GK4RjL020126; Thu, 16 Apr 2009 21:04:28 +0100 Received: from smtp.corp.google.com (spacemonkey1.corp.google.com [192.168.120.115]) by wpaz37.hot.corp.google.com with ESMTP id n3GK4PST012895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 16 Apr 2009 13:04:26 -0700 Received: from [192.168.0.13] (pool-71-114-4-37.washdc.dsl-w.verizon.net [71.114.4.37]) (authenticated bits=0) by smtp.corp.google.com (8.13.8/8.13.8) with ESMTP id n3GK4Nem026177 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 16 Apr 2009 13:04:24 -0700 Message-Id: <102A38CB-3128-4EF8-87A2-BDA347E5AE20@kumari.net> From: Warren Kumari To: Joel Jaeggli In-Reply-To: <49E77753.1080100@bogus.com> Content-Type: multipart/signed; boundary=Apple-Mail-6--387943050; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 16 Apr 2009 16:04:21 -0400 References: <49D461DD.3000101@bogus.com> <49E77753.1080100@bogus.com> X-Mailer: Apple Mail (2.930.3) Cc: opsec wg mailing list Subject: Re: [OPSEC] Working Group Last Call draft-ietf-opsec-blackhole-urpf-03.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, 16 Apr 2009 20:03:28 -0000 --Apple-Mail-6--387943050 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Apr 16, 2009, at 2:22 PM, Joel Jaeggli wrote: > Deadline is tomorrow... > > no opposition has so far been proffered, Yup, and I haven't heard a peep either :-) I was going to wait till midnight on Friday before letting out a sigh though :-) W > > > thanks > joel > > Joel Jaeggli wrote: >> This announcement is for working group last call on: >> >> http://tools.ietf.org/html/draft-ietf-opsec-blackhole-urpf-03.txt. >> >> Please send your comments to the list by Friday April 17, 2009. >> >> Thanks >> Joel >> _______________________________________________ >> 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 For every complex problem, there is a solution that is simple, neat, and wrong. -- H. L. Mencken --Apple-Mail-6--387943050 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO7jCCBwQw ggXsoAMCAQICAkqjMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMDkwMTEyMTQ1NjU2WhcNMTAwMTEyMTQ1NjU2WjBtMR4wHAYDVQQKExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxKTAnBgNVBAMTIFN0YXJ0Q29tIEZyZWUgQ2VydGlmaWNhdGUgTWVtYmVyMSAwHgYJ KoZIhvcNAQkBFhF3YXJyZW5Aa3VtYXJpLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAOpIMArXNarz9bdruFNHpMNz+sUcBEF3f1RluhE8ql3r1N5BCbcbPBqY8wHRJ3yH59lge/e2 gtktfNk3YEc7rO3liKat365evpVYbWsb8aB9hDMp72JBNw8pfXB9Rck3EONNidTSEXzIAV8Wqmpn 5MNkQEvAwca2RBiqTVXUAUSFehgRrdzs+atQJZY5LYf+SS262jnUmeAEhqkTeL/bSGoKJw8gdm6E LtBeMnZNivWXYWkx/FH9T9dsLHa+91GAt7wLwGkF4j0wuDZjipttxqXgyb37rrmEXFtprrgoTkfP d+o2ToD82+cRZ5SHiPMX5Jdj40NDJ6088cnM1dC5ZGcCAwEAAaOCA4wwggOIMAwGA1UdEwQFMAMC AQAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU GOTT7VrujcbZuYjov6zCuOXWGucwHAYDVR0RBBUwE4ERd2FycmVuQGt1bWFyaS5uZXQwgagGA1Ud IwSBoDCBnYAUU3Ltkpzg2ssBXHx+ljVO8tS4UYKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQ0wggFHBgNV HSAEggE+MIIBOjCCATYGCysGAQQBgbU3AQIAMIIBJTAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCBvAYIKwYBBQUHAgIwga8wFBYNU3RhcnRDb20gTHRkLjADAgEB GoGWTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJs ZSBhdCBodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeG JWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwu c3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGG LWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0 MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEA PIQakfJqAW8o9+7fyY93sn1/X5qgpMXZv/VPbNVpZDCjTTU/VZVgMxad3gAvMOvDpoSkk3U6Gyx9 +Y9mhHdUpYIVxjKN5r9vak/AkbsjKdRyoZaPPIdABIF3y8mnvxfYchzRQk7vEESSticddQyrWjHh gMAAdKoqHgA6zcWfebD0+/4rrB+JUEBy9AlzeQpuKiZ5Y9dtD1IJ24bL+tCCSZqR5P/hyMXmm4tM G5AQb4EEUS5ikx0+WrKaagC6zGrBeYRHmOXPKQ3aGAadY/NIZQ6EC1VosbR1FhIvg7V4lLGGyVEB x4r+W9zg4vLRvSboJ4cPrqHB95+hYF7E7zA9hjCCB+IwggXKoAMCAQICAQ0wDQYJKoZIhvcNAQEF BQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NFoXDTEyMTAyMjIxMDE1NFowgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zO LdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKT pT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirM cNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95m4Jg rM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8wCwYDVR0P BAQDAgGmMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjCBqAYDVR0jBIGgMIGdgBROC+8a pEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBM dGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0GCCsGAQUF BwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MGAG A1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMCeg JaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFUMIIBUDCC AUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3Jn L3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRlcm1l ZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFydENvbSkg THRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExp bWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5 IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgB hvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUAA4ICAQCq muHgW4zOHRv8HcYsMCCgt5Mm/fECts0RKL8p/8cwz/+B/wXPBRQ04KCUfp19i4tBD91O07Ixvgmi IvdPvGJUoQA6ZD635v/Es4xrSbXzOhGpbiToaXKjK9zssyt2mBiT+USHmery0930Gg2bCKKF5emE hUf9B6VOBSQ3NMLshWmZhWwq406fETWMkVk01+plkr/k62jsLo98663XUqYFBItlqsDPRv+aOCF0 Gxh8e6F07y+s68PSDmDt0DimQ4BTYR3ilIKjAFIi3IP/loXBnvmOLpirsYIbcGmLIA/2y3yH6Kdz Qv7uSasAwloswCa7oZmzleCxvOfTBQm9sP2HmOecwz1RpkNzGXa4sHTiq4ZRYzo2IoZptvFBzrzQ 9ht5CtC757oni6o0DHOhrlHGQEDlr/eqVuAX24kF6QKomzDHm9D2SEmuzxRMxogXNsQLlUZDOJAf f/oongNQ/zk4kScLH+q5KFYDrDfXwsOdtrczprlX4qg0uGxWL9NLF/3RRsGrB1FH9w7C4aQ0mHXo 2++Eio7bqiwyDrgJtmwNWsQOvu5IxXjSJ4ElOjj0jK3vsQI6HP+nKGjBrYRQ/popq/4v/BfMA8Hc s2rO6MZHQrWlvIVYq/JiZ26eAm3JJZQzD5HkOqkDZsUg4Tnql9Y8sdnE4v7z6vv08sVf7LZXoTGC A2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkqjMAkGBSsOAwIaBQCg ggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDQxNjIwMDQy MlowIwYJKoZIhvcNAQkEMRYEFOfj1I7cjYAbJ6QLi6mSOQBi12jsMIGkBgkrBgEEAYI3EAQxgZYw gZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICSqMwgaYGCyqGSIb3DQEJEAILMYGWoIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJl IERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQ cmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkqjMA0GCSqGSIb3DQEBAQUABIIBABX9Ya3A 8SCZmAUEU+6h0ZOzF2Q6Ktwkk4kg29fQuBGZZ9d2/fa8ykHNkfZ7fOpEjYegx83osjbAzv/rEsRy LxtGkSlw5FpLIh/XlKLN9Far8QfbqagyApqkZpLurkac/JR/WA8pN1BEyTDlSPjTUdIVioIYx2sk 09HnycNIj8pCwCOQl8jJaQm9OeW2DpNbS8dGCFnlRrncpjUeYrDH9lVvSyGi/UrWKQ1XJm8mc0xI 1ZnC4I9RKjXyyKBXtlbu5jPT7vV0XdraeNYsla4OWsxTq/Y3eR0UVxWr2zDsrbwI+VrqlTVAwoqa tIhsID6x9kXhyPgSMfdb6csXF0iCn2oAAAAAAAA= --Apple-Mail-6--387943050-- From tglassey@earthlink.net Wed Apr 15 07:46:11 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 454E13A6A45; Wed, 15 Apr 2009 07:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 GAo8UGfzC3Uv; Wed, 15 Apr 2009 07:46:10 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 434BC3A6944; Wed, 15 Apr 2009 07:46:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Xt1YVas4lT3EYf+o5AS8UQ3T7JFElyyx97LzJ+949KiyIKCXdAWupFW3nKtG6uYA; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [67.180.133.66] (helo=[192.168.1.100]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lu6OU-0001Oy-U2; Wed, 15 Apr 2009 10:47:19 -0400 Message-ID: <49E5F36D.7020808@earthlink.net> Date: Wed, 15 Apr 2009 07:47:09 -0700 From: Todd Glassey 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79f67c55b1fa4594b85a5844cb47905a42350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.180.133.66 X-Mailman-Approved-At: Sat, 18 Apr 2009 22:23:48 -0700 Cc: "'tcpm@ietf.org'" , "'ietf@ietf.org'" , Joe Touch , 'Joe Abley' , "'opsec@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: Wed, 15 Apr 2009 14:46:11 -0000 Lars Eggert wrote: > Hi, Todd, > > On 2009-4-14, at 22:21, Todd Glassey wrote: >> Fernando Gont wrote: >>> Lars Eggert wrote: >>>> I agree with Joe that some of the hardening techniques that vendors >>>> are >>>> implementing come with consequences (make TCP more brittle). To me, >>>> this >>>> is a *reason* this document should be published via the IETF (i.e., >>>> TCPM) - we are probably in the best position to correctly evaluate and >>>> classify the impact of various hardening techniques. Stack vendors >>>> have >>>> been putting these mechanisms in to their stacks without clear >>>> specifications and discussions of the potential upsides and downsides >>>> that would let them make an educated decision. It seems clear to me >>>> that >>>> the vendor community is looking for guidance here, and I do believe >>>> the >>>> IETF should give it. >>>> >>> >>> This is the reason for which the output of the CPNI project was >>> submitted as an IETF I-D. >>> >> Yeah - so then this would be tested across all of the local TCP >> implementations including the MS, AT&T *(i.e. Lachman Associates Inc) >> and possibly Mentat's fast system? > > Nothing would be "tested", the IETF isn't in the business of auditing > TCP stacks. Yo Lars Good-morning, let me respond. "Sure it is..." let me amplify - Don't the IETF standards processes "require the development of two or more independent implementations of any given protocol specification and the associated interoperability testing to document that the suite runs as advertised in the specification?" - I generally refer to that as IOT (Inter-Operability Testing). And for what its worth the IETF's mergence towards a leading edge standards process also reinforces the importance of that testing too by the way. By comparison, in trailing edge standards processes the IOT is accomplished in the various implementations which are done in the industry. In leading edge models where there is genesis happening the testing would have to be included in the implementation of any prototypes of the stack or system and its operations. This IMHO is the real issue with the worlds abuse of the IETF's processes - they seem to think that RFC's are standards and there are many here who use that to substantiate their technological advantage in their marketing, meaning that they derive financial value from misrepresenting this to the commercial community as well I think. The fix for that is to make RFC's unreliable for use as a protocol specification for anything other than a Standards Track effort as they should be - a Request For Comments rather than something the Trust's selling access to. Todd Glassey > What we're talking about is describing attack vectors, potential > countermeasures and the the impact (downsides) those countermeasures > might come with. Implementors will need to decide for themselves if > and how to apply any of these techniques to their stacks. Which would be filed as a Use Case Document as a set lf BCP's for a protocol stanadard. This by the way is where the real value of the IETF comes in - in also telling people how to and how not to use these protocols. Todd > > Lars From fred@cisco.com Mon Apr 20 23:42: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 7AA693A69DE for ; Mon, 20 Apr 2009 23:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.577 X-Spam-Level: X-Spam-Status: No, score=-106.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 7fr+Hdr758dT for ; Mon, 20 Apr 2009 23:42:29 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 72DBE3A6910 for ; Mon, 20 Apr 2009 23:42:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,222,1238976000"; d="scan'208";a="42305015" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 21 Apr 2009 06:43:45 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3L6hjFj005781; Tue, 21 Apr 2009 02:43:45 -0400 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3L6hinA004435; Tue, 21 Apr 2009 06:43:45 GMT Message-Id: <908AC7E5-4CCC-43DF-AD65-7CDF71436F98@cisco.com> From: Fred Baker To: opsec@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 20 Apr 2009 23:43:37 -0700 References: <20090421063001.E9D0E3A6FE3@core3.amsl.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1380; t=1240296225; x=1241160225; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Fwd=3A=20I-D=20Action=3Adraft-baker-v6ops-greyn et-00.txt=20 |Sender:=20 |To:=20opsec@ietf.org; bh=r6MaZg8dPx6P7hK5Nj+suc/tvWHzDgZo0pDpjjy4fsE=; b=DtxnucjTvD3w6f6B8XeEFGZ1VIGO++5542ZIJRqjl1NTvhHPXaE+WvhxcO DritnLOFHXwLRbXt9SlWmYA4mViDCLgOE1z5CQE++45jJMMAWRW4/3Q0gZqb t3SoiOzdsd; Authentication-Results: rtp-dkim-2; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: draft-baker-v6ops-greynet@tools.ietf.org Subject: [OPSEC] Fwd: I-D Action:draft-baker-v6ops-greynet-00.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: Tue, 21 Apr 2009 06:42:30 -0000 I'd appreciate any thoughts folks have. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: April 20, 2009 11:30:01 PM PDT > To: i-d-announce@ietf.org > Subject: I-D Action:draft-baker-v6ops-greynet-00.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : IPv4 and IPv6 Greynets > Author(s) : F. Baker, et al. > Filename : draft-baker-v6ops-greynet-00.txt > Pages : 8 > Date : 2009-04-20 > > This note discusses a feature to support building Greynets for IPv4 > and IPv6. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-baker-v6ops-greynet-00.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. Content-Type: text/plain
Content-ID: <2009-04-20232808.I-D@ietf.org >

> > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From lars.eggert@nokia.com Mon Apr 27 13:21:44 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 2BE943A700E; Mon, 27 Apr 2009 13:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=0.223, 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 40fg2yiMcT38; Mon, 27 Apr 2009 13:21:43 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id E70D028C1B8; Mon, 27 Apr 2009 13:21:18 -0700 (PDT) Received: from lars-2.vzbi.com (lars-2.vzbi.com [166.58.67.119]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n3RKMY2e081933 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 27 Apr 2009 23:22:35 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <88ACD16A-1137-4E55-871F-8F0C992D7A63@nokia.com> From: Lars Eggert To: tcpm@ietf.org, opsec@ietf.org In-Reply-To: <49EE1873.1090907@gont.com.ar> Content-Type: multipart/signed; boundary=Apple-Mail-32-563544112; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 27 Apr 2009 16:22:28 -0400 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> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [212.213.221.39]); Mon, 27 Apr 2009 23:22:36 +0300 (EEST) 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: Mon, 27 Apr 2009 20:21:44 -0000 --Apple-Mail-32-563544112 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit [Trimming the CC list to the relevant WGs.] Hi, On 2009-4-21, at 15:03, Fernando Gont 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. 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. Lars --Apple-Mail-32-563544112 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA0MjcyMDIyMjlaMCMGCSqGSIb3DQEJBDEWBBTqQZ0uIgBV4gOc vgOYQ3UG8wVdZjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAftK3hpcO/EGaRwtKzh3ajaOlg2rXapCEEVTbY9ygcWw5ZAf1hhfo aJK+otNsRlrVVim8SAJNXdafprb4V5SFdFHYv0ggwfphwHP/LvsDg1dTTE/iXZOJcBf+sa5eX9UW 6+41VFjgp2SXxzwbUZU9fN6bbTfNZbYkFXKbW98GiQlrz/09/lzI0HifyODkDnxFDyVoyeO8X+r3 VqP1gac8AGnASSHVV7SUoxTFXGHmUMSxoEN/GrLetB4HUn0i67dvFOSuiJh6HSAEbHP7eP3YWrVL YAJntj59mwWjdx3Sr9i1bcZ0uaIiPCg1QYgIXEFD+WdeKN/3ZZohGxpTIFDSOAAAAAAAAA== --Apple-Mail-32-563544112-- From joelja@bogus.com Wed Apr 29 08:28:28 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 AC8A73A715F; Wed, 29 Apr 2009 08:28:28 -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 b5eN0IbUQuLu; Wed, 29 Apr 2009 08:28:27 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 8D2C53A6959; Wed, 29 Apr 2009 08:28:27 -0700 (PDT) Received: from [172.168.1.100] (adsl-75-36-137-89.dsl.pltn13.sbcglobal.net [75.36.137.89]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id n3TFTfLW003594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 Apr 2009 15:29:47 GMT (envelope-from joelja@bogus.com) Message-ID: <49F8725D.9020806@bogus.com> Date: Wed, 29 Apr 2009 08:29:33 -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/9304/Wed Apr 29 11:57:58 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: Wed, 29 Apr 2009 15:28:28 -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 03 having completed WG last call. 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 has been 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. 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.