[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSEC Security Gateways & NAT
"Chen, David" <dchen@ellacoya.com> writes:
> Jayant,
>
> It seems works if
> IKE is encapsulated in an UDP/IP with the same as IKE's original 500/IP at
> initiator and the responder do not check the outer IP and knows to
> decapsulate the outer UDP/IP.
> Extra header consumes bandwidth, but it is signal; therefore, can trade for
> security through NAPT.
I suppose you could use a UDP-in-UDP encapsulation for IKE, but _how_
would the IKE daemon know to do this? The Initiator may not know that
it's sitting behind a NAT gateway. How could it? Now, the responder
can _tell_ if the initiator is behind a NAT gateway, because the
Source IP Address of the incoming packets wont match the contents
(assuming the initiator says "my IP Addr is 1.2.3.4" in the IKE
messages), or the source port wont be 500 (because it's been
translated).
At this point the responder can cache the port-num and just use it to
send IKE packets back to the originator, just by responding to the
source IP/Port in the first packet. Any NAT Gateway worth it's salt
will make sure that multiple packets from the same source ip/port to
the same dest ip/port will get mapped to the same NAT'ed ip/port,
within some time window.
> For ESPoUDP,
> it is desirable having maping as TCP->TCP and UDP->UDP and
> OtherProtocol->OtherProtocol from inner to outer and not just uniformly
> using
> UDP.
There is no such mapping. Where do you think you could even GET one?
Consider than in the "normal" IPSec case, all you get through the
network is an ESP packet. You don't know what the underlying
transport protocol is. So, why are you suggesting that some window be
created where one doesn't exist?
All UDP is giving you is an address that the NAT box can use to map
the ESP between source and destination. The reasons for using UDP are
that:
1) UDP is packet-oriented
2) UDP is fairly light-weight
3) UDP can easily be NAT'ed based on source/dest ip/port
The problem with trying to NAT ESP is that the uniqueness is based
upon 'dest ip/spi' but each 'dest' behind the NAT could use the same
SPI. For example, hosts A and B behind NAT-gateway N could both
choose SPI 0x01 when talking to correspondant host C. C will
'respond' with packets destined for 'N', but N wont know whether the
SPI belongs to A or B.
Consider UDP NATing, however. Hosts A and B share UDP port 500
between IKE and ESPoUDP. When they send messages to C, N will
translate the source from A/500 and B/500 to, e.g. N/501 and N/502.
Then when C responds to N/501, N knows to relay the packet to A/500;
when C responds to N/502, N can relay to B/500.
I suppose you could also try to put QoS in there somewhere, but you'd
be better off solving the "IPSec QoS problem" in general first,
because that is a more difficult problem to solve. Once you figure
out how to add QoS to IPSec in general, then adding it to EDPoUDP
would work exactly the same.
Note that there is necessarily no protection on the QoS bits, because
there is no way for an intermediate gateway to verify the security.
"'jshukla'" <jshukla@earthlink.net> writes:
> 1) There needs to be a mapping at the
> receiver (inner IP addresses and port #s to outer
> IP addresses and port #s). This mapping is used
> to send the packets back to the initiator.
This mapping is really done at the NAT gateway. The endpoints really
don't need to be NAT-aware, per se. The endpoints just need to know
to respond to the source ip/port instead of automatically responding
to port 500. Yes, it should also cache the source ip/port for the
particular host, but that's not really much more than it's already
doing.
> 2) You can reverse the effect of NAT with
> this mapping and therefore the subsequent packets
> don't have to have the extra IP/UDP headers.
This is true of IKE messages, but with IKE messages you don't need an
extra header. With ESP, yes, you need the extra header so the NAT box
has something to munge that is considered 'unique'.
> 3) Its a bad idea to just use UDP for encapsulation
> because you are mapping TCP/UDP services to
> UDP. This can lead to incompatibility with QoS
> protocols and will make BITW implementations
> difficult. There might be problems with routing
> fragmented packets and ICMP messages.
> A better solution is to use TCP -> TCP and
> UDP-> UDP encapsulation.
HUH? What are you talking about? You are mapping ESP services (a
packet-oriented service) to UDP (another packet-oriented service).
There is no TCP service here. Or at least none visible to anyone
except the security endpoints.
As for QoS, as I mentioned above there is a bigger problem of QoS for
plain vanilla IPSec. Go solve that first before trying to solve an
encapsulated IPSec.
> etc. etc.
>
> For more information you can read our draft on
> NAT and QoS compatible end-2-end security. We
> have a new and more detailed draft coming out soon.
>
> regards,
> Jayant
-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
References: