[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: some issues about IPSec
...talking about denial-of-service attack on the ISAKMP/IPsec - I came up
with very easy one.
ISAKMP main mode authenticates users in it's third exchange, after very hard
work of negotiation and doing Diffie-Hellman (exponentiation!!) and deriving
secret keys during previous two exchanges.
And only in the third exchange, after verifying signatures, CRL and
certificate chain (more exponentiation!!) my fake ISAKMP session will be
rejected.
This attack is especially possible against SGWs that will authenticate "road
warriers" - for whom SGWs will not have permanent IP addresses in its SPD
and will rely on the main mode exchange to authenticate them before
rejecting the session.
Charles Lynn wrote:
> Harald,
>
> > You're talking about different tunnel-mode semantics than most people,
>
> Maybe I was not sufficiently clear. My message was intended to give
> reasons why Transport Mode is needed, not about the relative merits of
> the different tunneling schemes. I think that trying to get a tunnel
> to emulate the IP layer, in all its glory, is very hard. But I think
> that IPSec should serve all the communities that need real security
> services, not just those wanting a VPN, or mobility, or ...
>
> In addition, IPSec should not be so restrictive that it makes it
> harder for the routing subsystem to evolve in ways that inevitably
> will be needed to scale to a truly global Internet. The number of
> folk working in the area is so large today that I find it hard to keep
> track of all that is happening. Have you heard about the suggestions
> to help the scaling and autoconfiguration problem by having routers
> rewrite IP addresses as the packets pass by? Consider what will
> happen to end-to-end authentication then. AH may turn out to be a
> major denial of service attack. (At the moment, ESP authentication,
> either with or without confidentiality, could be used to get around
> the problem, but I do not think that the infrastructure to decide when
> AH will work and when ESP would be needed is there.)
>
> Lots of things for us to consider in IPSecond.
>
> Charlie
--
Bronislav Kavsan
IRE Secure Solutions, Inc.
100 Conifer Hill Drive Suite 513
Danvers, MA 01923
voice: 978-739-2384
http://www.ire.com
Follow-Ups:
References: