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

Re: IPSEC Security Gateways & NAT

"Chen, David" <dchen@ellacoya.com> writes:

> Derek,
> 
> Id protection still valid as of today's mechanism (after DH-key exchange).
> The IP address is not a user Id for user authorization, authentication.

Except that in this case the enclosed ID means absolutely nothing.
Indeed, that ID _must_ be the IP Address.

> The IP address is the machine Id (and maybe group user id) 
> that will help to reduce randomly DOS attack *only*.

Insufficient.  A road-warrior does not necessarily know their IP
Address, because the IP Address is always changing.  Unless you
recommend that road-warriors use a pre-defined, "non-routable" IP
Address as their ID and ALWAYS just encapsulate that "special" SIP in
their currently real address?

> If we tunneled the IKE message, the inner IP address is not altered by the
> NAT device(s) that in-between two SGs.
> It could be unreachable addresses.  
> Either NAT existing or not, the outer IP address are reachable address the
> inner address may or may not routable and only for preventing DOS attack.

Right, as I said above, you could always have the inner IP Address be
some pre-determined, static, non-routable address which can be used to
assure linkability as a road-warrior moves.  In other words, your
inner IP is your ID, and you are sending your ID in the clear.  If you
are going to do that, you might as well just send an ID payload as
part of the initial exchange.

In my mind, this means you are willing to live without Identity
Protection (because, indeed, the Identity MUST be the Source IP
Address -- in your case the "inner" IP Address).  As I said, the IDs
"protected" in messages 5 and 6 means nothing, as they MUST be the
SIPs in order for anything to work right.  Either that, or you need to
share _TWO_ sets of keys, one for the SIP, and one for the actual
protected ID.  But you don't seem to be talking about this, so I
assume you are talking about the existing standard where the ID must
be the SIP.

> As for the mechanism, 
> it seems enough by using as simple as modified CHAP mechanism with
> the freedom of choosing hashing algorithm.
> The random number is visible but
> to protect from replay attack. (replay helps DOS attack) 
> It is idea to let initiator to generate random number.

Since you seem to feel that ID protection isn't necessary for
pre-shared key authentication, why not just change the protocol so the
endpoints send their IDs in the clear as part of messages 1 and 2 (or
perhaps 2 and 3?).  Then you can use a MAC based on the shared secret
to verify messages 3 and 4.  This solves the DoS problem for
pre-shared auth.  However, it doesn't solve it for other auth
mechanisms.

You seem to be willing to give up "privacy" (ID protection) for
"security" (some protection against DoS).  Please remember the
immortal words of an American Forefather who said (paraphrased):
"he who gives up privacy for security will live with neither."

As I keep saying (and this is the LAST time I will say it -- I will
ignore any more messages on the topic):  If you want to protect
against DoS, then build a DoS protection protocol that works for
ALL of IKE.  And unfortunately I (and many other people) do not
believe that giving up ID protection is a valid (or necessary)
step to protect against DoS.

Have a Nice Day.

-derek

PS: If you'd like to continue this discussion, I suggest you come
to London and we can spend as much time as you would like talking
about this.

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