ietf
[Top] [All Lists]

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

2009-04-13 18:24:08
-----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-----
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>