Re: transport vs network and ipsec syn

Dan.McDonald@Eng.sun.com (Dan McDonald) Fri, 28 February 1997 22:06 UTC

Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA10855 for ipsec-outgoing; Fri, 28 Feb 1997 17:06:08 -0500 (EST)
From: Dan.McDonald@Eng.sun.com
Message-Id: <199702282210.OAA07972@kebe.eng.sun.com>
Subject: Re: transport vs network and ipsec syn
To: parkosar@pb.com
Date: Fri, 28 Feb 1997 14:10:34 -0800
Cc: ipsec@tis.com
In-Reply-To: <9701288571.AA857165346@smtppc.ct.pb.com> from "Arthur Parkos" at Feb 28, 97 01:15:23 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

> one question (multipart), i was not sure how ipsec addresses the syn attack:

Phil's right in that AH with replay protection, when it's turned on, will
stop SYN attacks dead.

And even without replay protection, you have assurances that only the SYN for
the particular connection id will be flooded if some miscreant replays a
particular SYN.

> - it's not guaranteed that all connections will be attempted with ipsec
> authentication instantiated. therefore a host will still need to respond to
> the request for a connection. or will a host refuse all connect attempts
> from non-ipsec host.

You are right.  What you aren't clear on is that I _can_ be selective on
which listening endpoints I have IPsec turned on.  An example I see my
customers using is:

	* Port 80/TCP (WWW) has no IPsec on it
	* Maybe port 20-21/TCP (FTP) has no IPsec on it
	* All other ports (telnet, etc.) have a minimum requirement of
	  AH with replay protection.

And anyone who tells you you can't implement per-endpoint IPsec policy is on
drugs.  I suggest you read the NRL IPsec code for a working counterexample.

> - if ipsec is implemented, the host will still need to perform an
> authentication on the potential partner which would eat cpu cycles.

Yes, but memory isn't being slopped.

BTW, in my forthcoming Simple IPsec API draft, I detail a potential
denial-of-service attack that is similar to what is described above.  There
is a fix, BTW.

> - if ipsec is there, the host receives the connect attempt and retrieves
> the address, so what if it was signed.  couldn't a bad entity sign fake ip
> addresses and then send them on to a potential host to be attacked?

In that case you're problems are probably a lot worse than a simple
denial-of-service attack.

> - when will the infrastructure be in place so that a host can authenticate
> a connection attempt from the myriad potential connectees where
> certificates may have been issued by different certificate authorities

Good question.  That's partially a key mgmt. question too, as the ISAKMP,
Photuris, etc. have to decide if the certificate used for the key exchange is
trustworthy.

Thanks for the questions, I hope I answered them.

--
Daniel L. McDonald  -  Solaris Internet Engineering  ||  MY OPINIONS ARE NOT
Mail: danmcd@eng.sun.com, danmcd@kebe.com <*>        ||  NOT NECESSARILY SUN'S!
Phone: (415) 786-6815            |"rising falling at force ten
WWW: http://www.kebe.com/~danmcd | we twist the world and ride the wind" - Rush