Re: [tcpm] [OPSEC] draft-gont-tcp-security
"Smith, Donald" <Donald.Smith@qwest.com> Mon, 13 April 2009 19:54 UTC
Return-Path: <Donald.Smith@qwest.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@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" <Donald.Smith@qwest.com>
To: 'Fernando Gont' <fernando@gont.com.ar>, 'Joe Touch' <touch@ISI.EDU>
Date: Mon, 13 Apr 2009 13:55:30 -0600
Thread-Topic: [OPSEC] [tcpm] draft-gont-tcp-security
Thread-Index: Acm8bWCAc1S4KexUSCS6Tc+o0uRA6wAAO68A
Message-ID: <B01905DA0C7CDC478F42870679DF0F1004BC4176D0@qtdenexmbm24.AD.QINTRA.COM>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221318F5E8@NDJSSCC01.ndc.nasa.g ov><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
X-Mailman-Approved-At: Tue, 14 Apr 2009 08:24:13 -0700
Cc: "'tcpm@ietf.org'" <tcpm@ietf.org>, "'ietf@ietf.org'" <ietf@ietf.org>, 'Joe Abley' <jabley@ca.afilias.info>, "'opsec@ietf.org'" <opsec@ietf.org>
Subject: Re: [tcpm] [OPSEC] draft-gont-tcp-security
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Apr 2009 19:54:48 -0000
(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. > > 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. Again, it was intended to help ensure integrity and availability. > >> 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 can be made better that is not an incorrect impression it is a fact. > > 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. > > > 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. 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 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. > > > > 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. Again the use of a generic "secure". What do you mean by "nonsecure" here? > > 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 > > > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec >
- [tcpm] draft-gont-tcp-security Eddy, Wesley M. (GRC-RCN0)[Verizon]
- Re: [tcpm] draft-gont-tcp-security Joe Touch
- Re: [tcpm] draft-gont-tcp-security Fernando Gont
- Re: [tcpm] draft-gont-tcp-security Joe Touch
- Re: [tcpm] draft-gont-tcp-security Fernando Gont
- Re: [tcpm] [OPSEC] draft-gont-tcp-security Fernando Gont
- Re: [tcpm] draft-gont-tcp-security Joe Touch
- Re: [tcpm] [OPSEC] draft-gont-tcp-security Joe Touch
- Re: [tcpm] [OPSEC] draft-gont-tcp-security Joe Touch
- Re: [tcpm] [OPSEC] draft-gont-tcp-security Fernando Gont
- Re: [tcpm] [OPSEC] draft-gont-tcp-security Joe Touch
- Re: [tcpm] [OPSEC] draft-gont-tcp-security Joe Touch
- Re: [tcpm] [OPSEC] draft-gont-tcp-security Fernando Gont
- Re: [tcpm] [OPSEC] draft-gont-tcp-security Lars Eggert
- Re: [tcpm] [OPSEC] draft-gont-tcp-security Joe Touch
- Re: [tcpm] [OPSEC] draft-gont-tcp-security Smith, Donald
- Re: [tcpm] [OPSEC] draft-gont-tcp-security Smith, Donald
- Re: [tcpm] [OPSEC] draft-gont-tcp-security Joel Jaeggli
- Re: [tcpm] [OPSEC] draft-gont-tcp-security Smith, Donald
- Re: [tcpm] [OPSEC] draft-gont-tcp-security Joe Touch
- Re: [tcpm] [OPSEC] draft-gont-tcp-security Fernando Gont
- Re: [tcpm] [OPSEC] draft-gont-tcp-security Fernando Gont
- Re: [tcpm] [OPSEC] draft-gont-tcp-security Lars Eggert
- Re: [tcpm] [OPSEC] draft-gont-tcp-security Todd Glassey
- Re: [tcpm] [OPSEC] draft-gont-tcp-security Todd Glassey
- Re: [tcpm] [OPSEC] draft-gont-tcp-security Lars Eggert
- Re: [tcpm] [OPSEC] draft-gont-tcp-security Lars Eggert
- Re: [tcpm] [OPSEC] draft-gont-tcp-security Fernando Gont
- Re: [tcpm] [OPSEC] draft-gont-tcp-security Joel Jaeggli
- Re: [tcpm] [OPSEC] draft-gont-tcp-security Fernando Gont
- Re: [tcpm] [OPSEC] draft-gont-tcp-security Joe Touch
- Re: [tcpm] [OPSEC] draft-gont-tcp-security Fernando Gont
- Re: [tcpm] [OPSEC] draft-gont-tcp-security Joe Touch