>>
>> How are you establishing sessions? Manual keying: will generally
>> work (but is so insecure you're wasting your time) IKE: might
>> possibly work.
>>
>> What IKE authentication are you using? Pre-shared secrets: won't ever
>> work. Raw public keys: won't ever work. Certificates: might
>> possibly work.
>OK, most of the rest made perfect sense, but you lost me here. Why will NAT
>break IKE?
>As long as your endpoints have entries for the NAT'ed IP Address of the peer
>and whatever auth criteria they need, shouldn't it Just Work? There's no IP
>address info communicated as part of inside of the IKE packets, AFAIK?
"As long as your endpoins have entries..." is a pretty strong caveat.
Most NAT is really PAT nowadays (which can never ever work), but even
true NAT doesn't generally offer predictable IP addresses. So in the
small case where you actually know what the IP address is going to be,
then you can NAT and---in theory---the authentication will work.
However, you still have a problem: the ID sent in the fifth IKE packet
is not going to match the IP address outside the packet. Some IPSEC
implementations are going to be very anal about this, and will barf because
everything doesn't match. This also opens you up to the MITM attack.
The other option is to use aggressive mode, but this sends the hash of
your PSS in the clear. While the PSS space is, in theory, large, it is in
practice quite small and having that hash in the clear sounds like a bad idea
to me. Also not everyone supports aggressive mode.
So there are sub-options where this will possibly work, but they are inherently
less secure.
>The other thing that confused me was why ESP should work in Tunnel mode but
>not Transport mode. All host implementations will be using transport mode,
>neh? There's very little difference between them that NAT should care about
>- neither of them cover the IP header in their auth section, and the ESP
>itself doesn't contain any IP addresses.
No, host implementations will use tunnel mode, unless you're talking
host-to-host. I don't forsee host-to-host IPSEC for a number of
years. It's too computationally intensive (although the new Intel and 3COM
adapters are a nice start), but, more importantly, the overhead of managing all
those sessions is too hard right now. Figure in 3 to 5 years it will be common
(just as SSL is common today), but for now, you're talking to security gateways
in most cases. Generally, most folks talk PC-to-gateway, which requires
tunnel mode (unless you really want to talk to the gateway).
But that doesn't answer your question. Like the IKE question, it's actually a
more qualified one: IPSEC in transport mode will work, except for those
protocols which violate layering concepts and know about things like IP
addresses. Unfortunately, TCP and UDP are some of those protocols: the
UDP & TCP checksums are defined as covering the IP address outside of the UDP &
TCP area in addition to the data inside of the packet. Normally, a NAT device
simply fixes up the checksum so that the packet doesn't know that it has been
screwed with. Unfortunately, in transport mode, the checksum is encrypted, so
the NAT device can't fix it up, and the UDP & TCP checksum will fail to
authenticate.
So a more precise answer would have been "transport mode: works great, unless
you want to send TCP or UDP, in which case doesn't work." I guess you could do
IP-in-IP and that would work. Or non-TCP/non-UDP protocols, such as OSPF.
Except that there is no multicast support. Or UDP with the checksum turned
off.
//INSERT SHAMELESS PLUG
If you really want to know more about all this, you should attend
the full-day VPN Day at Interop in Las Vegas in a few weeks which
features, among an all-star class of firewall-heads and security-geeks
(mainly Fred Avolio) yours truly who will explain all this at very,
very high speed.
//END SHAMLESS PLUG SORRY FOR THE RUDE INTERRUPTION
jms
Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
Phone: +1 520 324 0494 (voice) +1 520 324 0495 (FAX)
[EMAIL PROTECTED] http://www.opus1.com/jms Opus One
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
