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.
- proposed IPSEC changes/extensions Stephen Kent
- Re: proposed IPSEC changes/extensions David Wagner
- Re: proposed IPSEC changes/extensions Ran Atkinson
- Re: proposed IPSEC changes/extensions Hilarie Orman
- Re: proposed IPSEC changes/extensions pau
- Re: proposed IPSEC changes/extensions Michael Sabin
- Re: proposed IPSEC changes/extensions Stephen Kent
- Re: proposed IPSEC changes/extensions pau
- Re: proposed IPSEC changes/extensions Bill Sommerfeld
- Re: proposed IPSEC changes/extensions pau
- Re: proposed IPSEC changes/extensions Santeri Paavolainen
- Re: proposed IPSEC changes/extensions Rodney Thayer
- Re: proposed IPSEC changes/extensions Santeri Paavolainen
- Re: proposed IPSEC changes/extensions Stephen Kent
- Re: proposed IPSEC changes/extensions David Wagner
- Re: proposed IPSEC changes/extensions Steven Bellovin
- Re: proposed IPSEC changes/extensions Michael Sabin
- Re: proposed IPSEC changes/extensions John Gilmore