Re: [tcpm] [OPSEC] draft-gont-tcp-security

"Smith, Donald" <Donald.Smith@qwest.com> Mon, 13 April 2009 22:03 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 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" <Donald.Smith@qwest.com>
To: 'Joe Touch' <touch@ISI.EDU>
Date: Mon, 13 Apr 2009 16:04:11 -0600
Thread-Topic: [OPSEC] [tcpm] draft-gont-tcp-security
Thread-Index: Acm8fCTNNWHKB3L4SN2ay+XPh46BiwAAxQwg
Message-ID: <B01905DA0C7CDC478F42870679DF0F1004BC4176F9@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> <B01905DA0C7CDC478F42870679DF0F1004BC4176D0@qtdenexmbm24.AD.QINTRA.COM> <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
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>, 'Fernando Gont' <fernando@gont.com.ar>
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 22:03:33 -0000

(coffee != sleep) & (!coffee == sleep)
Donald.Smith@qwest.com gcia   

> -----Original Message-----
> From: Joe Touch [mailto:touch@ISI.EDU] 
> Sent: Monday, April 13, 2009 3:09 PM
> To: Smith, Donald
> Cc: 'Fernando Gont'; '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
> 
> -----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.
I didn't mentioned authentication or authorization in my description of security but those
two enhancements do provide some ability for authentication and authorization.
Yes, I do think elements of tcp/ip were designed to address the integrity and availablity.


> 
> 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?

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, congestion notification, dynamic routing and many other tcp/ip features are intended to address availablity.

> 
> ...
> >> 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:(

> 
> 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-----
>