[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IPSEC Security Gateways & NAT
Welcome back Derek,
There are plenty examples to have at least two authenticated id to
proceed in the real life.
The higher security, the more cross checking (could be implicitly) required.
(Just image a few Derek Atkins out there, they all have valid driver
license but I don't know which one (maybe 2) is the one (maybe 2) in this
thread :-)
If today's IKE has ID protection (well, not today's pre-shared key),
how could the security is reduced if one CID (clear text id) (such as IP
address)
is added that does not link to PID (protected id)?
Under this suggestion, any (D)DOS attacker has the CID but no pre-shared
key/
pass-phrase the responder will not send any message if the first initiator's
message does not pass hashing check.
The "scale" is not an issue in the view of the domain "user" community.
Potentially it will require "secured key distribution" that can happen
in other channel and not real time.
It is certainly not the "everyone is welcome" as today's IKE's first
pair of messages.
As for throttle method,
the DOS attacker will successfully deny valid service request to responder
if NAT traverse is enabled as we have analyzed.
In addition, the DDOS still can make the responder throttle on five hundred
addresses
and no time for other process. (with or without NAT)
Even the responder does not crash, the DOS goal is reached.
The IKE's NAT traverse helps DOS attack.
Or should I say "No NAT traverse will reduce DOS attack".
Regards,
--- David
-----Original Message-----
From: Derek Atkins [mailto:warlord@MIT.EDU]
Sent: Tuesday, June 19, 2001 1:25 PM
To: Chen, David
Cc: jshukla; 'Dan Harkins'; ipsec@lists.tislabs.com
Subject: Re: IPSEC Security Gateways & NAT
"Chen, David" <dchen@ellacoya.com> writes:
> Derek,
>
> Id protection is important.
>
> That's why today's IKE exchange ID and authentication peer after secured
> communication channel - i.e. DH-key exchange.
Except that with pre-shared keys, there is no ID protection. The
ID must be the Source IP Address, and that is world-visible to anyone.
All the other mechanisms hide the ID within the DH.
> In the real world, one person have several different ids in different
domain
> of society. Each of them has different function and "privacy".
> However, collectively, these Ids perceived by environment as an unique Id.
>
> The suggestion here, is adding one *more* id beside what IKE had
> to improve IKE's resistance to DOS attack.
The difference is that generally one does not use multiple identities
during one transaction. Any single transaction generally uses one
single identity. For example, you present your credit card to a
merchant, or you present your driver's license to a police officer,
or you present your passport to a custom's agent.
You are proposing IKE have TWO identities per transaction. The first
is a pre-shared host key based upon some publically visible name (SIP
or a message-1/message-2 ID payload) and the second is some other
authentication based upon a protected identity.
I think many people believe that this added complexity is not worth
the benefits. Because I _know_ that IP Address 1.2.3.4 is bombarding
me with IKE traffic (real or not), I can just throttle that traffic
down. Your added cleartext-identity with pre-shared key:
a) doesn't scale, and
b) doesn't protect you from a DDoS zombie.
> It will not reduce today's Id protection security but
> add one more to reduce DOS attack.
Considering there is no ID protection in pre-shared keys, it could
hardly reduce it any more.
> You have a nice vacation-flight to UK.
>
> I will land mine in my backyard.
Who said anything about Vacation? I was referring to the IETF Meeting
in August.
> --- David
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available