[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSEC Security Gateways & NAT
Unfortunately the double encapsulation is just as bad as opening up
all ports. There is no verification that the Source IP is correct
until it's too late in the process.
The initiator can put any information they want in the 'inside' header
to make it look like anything they want. The outside header can be
anything as well, provided that there is something "listening" on that
port.
For example, an attacker can use the encapsulation method similarly to
how you proposed using an open port. They sit at a machine of address
1.2.3.4, port Y, and spew out messages that look like:
((10.0.0.1/500) 1.2.3.4/Y) -> responder/500
((10.0.0.2/500) 1.2.3.4/Y) -> responder/500
And so on. Again, there is no way for the responder to know whether
there is a single attacking machine or multiple NAT'ed machines.
So, you either have to accept the fact that a responder cannot
differentiate between a single SIP attack and a lot of real
connections from behind a NAT, or we have no NAT traversal, or you
have to give up initiator ID protection from passive eavesdroppers.
Like all things in computing, it is a choice, a tradeoff.
Having been stuck behind NAT's, I would certainly prefer to _have_
some NAT traversal potential, so I would hope we do not choose "no NAT
traversal". That leaves either losing ID protection or accepting that
loaded NATs may be considered attackers, or coming up with a
completely different protocol (perhaps with many more messages) to try
to defeat these DDoS attacks.
-derek
"Chen, David" <dchen@ellacoya.com> writes:
> Derek,
>
> Here is my observation:
>
> In order let IKE packets traverse through NAT,
> the responder has to respond udp port number other than 500.
> For DOS attacker, he gains more attacking messages from a single address.
> In addition, as long as responder drop some real user's IKE messages
> (due to the mixing of real and attacked messages and throttling/blocked
> this same SIP of NAT device)
> the DOS attack is successfully denying others valid access to the
> responder. (although not as disaster as the responder is brought down).
>
> if no NAT allowed, the responder will only respond to udp port 500,
> Furthermore, the responder sure can block (not throttle) the SIP since it
> represents only one initiator (and is the attacker)
>
> Since the initiator's IP address could be the only id before DH-key
> exchange,
> it seems can help to reduce DOS attack?
> (by using pre-shared key to auth this ip-address before DH-key exchange)
>
> If this is the case, when traversing trough NAT,
> then tunneling IKE by encapsulating yet another UDP is a good method?
>
> Regards,
>
> --- David
>
>
>
> -----Original Message-----
> From: Derek Atkins [mailto:warlord@MIT.EDU]
> Sent: Monday, June 18, 2001 2:22 PM
> To: Chen, David
> Cc: 'Dan Harkins'; ipsec@lists.tislabs.com
> Subject: Re: IPSEC Security Gateways & NAT
>
>
> "Chen, David" <dchen@ellacoya.com> writes:
>
> > Derek,
> >
> > The trouble is the responder can not tell
> > if this an attack or just lots of users behind the
> > same NAT try to connect at the same time.
> >
> > In addition, the DDOS can have many SIP attack at the same time.
> > Even throttle on a address, it does not help to prevent using
> > many SIP addresses attack.
>
> I think this is just a problem with IKE in general. Let's not start
> mixing apples with oranges here. This conversation started on NAT
> traversal, and now is moving into general IKE DDoS protection.
>
> As I've said, NAT does not (IMHO) add any additional attacks
> that aren't already available without NAT.
>
> > For message 1 and 2, the attacker and resonder will use (appx.) equal
> > resource but message 3,4 is the attacker's goal, and it still
> > be able do this.
>
> Yes, but if an attacker at IP address X sends me several bogus
> "message 3" messages, or lots and lots of transactions, I can just
> blacklist that host.
>
> > Maybe initiator's IP address need to link with auth?
>
> Maybe. Maybe not. Certainly in the end of the process we have an
> authentication of the endopoint, although not necessarily the IP
> Address. Consider that a road-warrior practically NEVER has the same
> IP address, so authenticating the IP Address is meaningless.
>
> The question is: what attacks are you trying to protect against?
> What's your threat model? Considering IKE is already subject to
> DDoS attacks, I would suggest that if you consider DDoS a major
> threat, you need to fix IKE in that way. However that has nothing
> to do with IKE NAT Traversal.
>
> > --- 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
--
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: