[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: transport vs network and ipsec syn




--- On Fri, 28 Feb 97 13:15:23 EST  Arthur Parkos <parkosar@pb.com> wrote:

> one question (multipart), i was not sure how ipsec addresses the syn attack:
> 
> - 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.

The NRL IPsec code that I wrote actually permits the system administrator
to configure the node such that connection requests arriving without
IPsec are simply dropped and not passed up to TCP.  

In such a configuration, the node is fully protected against TCP session 
stealing attacks.  

The node is also protected from hosts that it has no IPSEC Security 
Association with.  

Since the IPSEC Security Association creation requires at least one new 
round-trip, the current form of TCP SYN flooding attacks (which
use a bogus source IP address in the SYN packets) are precluded.  

If the attacker uses a real source IP address to attack another node, then
the attacker's identity is known and provable -- in which case one can
add packet filters to one's router/node and/or call the Police.

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

Experience with the cisco ISAKMP/Oakley daemon and NRL IPsec code on
a BSD Pentium/90 box with 16 MB of RAM indicates this is not a significant
operational issue.

> - 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?

I can't parse the above.

> - 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

Not clear how you are defining "infrastructure".  If one considers
the potential use of DNSSEC to distribute signed public key values,
deployment could happen fairly quickly after the next version of BIND
(which reportedly will include DNSSEC extensions) is released.  TIS
has already obtained US Export Licensing for BIND with DNSSEC, so
that shouldn't be an obstacle.

Ran
rja@Inet.org