Re: proposed IPSEC changes/extensions

David Wagner <daw@cs.berkeley.edu> Tue, 05 November 1996 13:09 UTC

Received: from cnri by ietf.org id aa13749; 5 Nov 96 8:09 EST
Received: from neptune.hq.tis.com by CNRI.Reston.VA.US id aa08600; 5 Nov 96 8:09 EST
Received: from neptune.tis.com by neptune.TIS.COM id aa05723; 5 Nov 96 7:48 EST
To: ipsec@tis.com
Path: not-for-mail
From: David Wagner <daw@cs.berkeley.edu>
Newsgroups: isaac.lists.ipsec
Subject: Re: proposed IPSEC changes/extensions
Date: Mon, 04 Nov 1996 21:58:00 -0800
Organization: ISAAC Group, UC Berkeley
Lines: 25
Message-ID: <55ml18$9pk@joseph.cs.berkeley.edu>
References: <199611011912.OAA01596@thunk.orchard.medford.ma.us>

<Pine.SUN.3.91.961104122622.11989B-100000@hutcs-2.cs.hut.fi>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk

[Apologies if I'm covering old, familiar ground again:]

In article <Pine.SUN.3.91.961104122622.11989B-100000@hutcs-2.cs.hut.fi>,
Santeri Paavolainen  <santtu@mail.cs.hut.fi> wrote:
> TCP is inherently safe
> from replay prevention, and no cryptographic security is needed. The
> only item of interest is authentication, eg. tamperproof connections. 

I disagree.  TCP still needs replay protection.

For one thing, TCP sequence numbers were designed for robustness against
long-lived packets and network errors, not against adversaries.  TCP sequence
numbers can easily wrap around (and they do in some applications).  Once
they wrap, you're vulnerable to replays.

Also, when host-pair keying is in effect, and one host has mutually
distrustful users, TCP probably needs replay protection, lest one of
Bellovin's attacks compromise confidentiality.  (Alice binds to port
1234, receives some traffic, disconnects; Bob then binds to port 1234,
replays the old traffic, and receives the decryption of Alice's data.)

Who knows -- there may be other attacks, too.  I say, for robustness,
and for security against known attacks, TCP does need replay protection.

Anyhow, maybe this doesn't change your main point.  Just a nitpick.