Re: [tcpm] [OPSEC] draft-gont-tcp-security
Joe Touch <touch@ISI.EDU> Mon, 13 April 2009 22:22 UTC
Return-Path: <touch@ISI.EDU>
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 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 <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: "Smith, Donald" <Donald.Smith@qwest.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> <B01905DA0C7CDC478F42870679DF0F1004BC4176F9@qtdenexmbm24.AD.QINTRA.COM>
In-Reply-To: <B01905DA0C7CDC478F42870679DF0F1004BC4176F9@qtdenexmbm24.AD.QINTRA.COM>
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'" <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: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-----
- [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