[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IPSEC Security Gateways & NAT
Derek,
The idea of tunneling IKE by using UDP/IP will required the IPSec's IKE
daemon change.
In order to traverse any number of NAPT-GW between the initiator and
responder,
the initiator and responder have to encapsulate, de-capsulate the outer
UDP/IP header
fore process today's IKE packet.
An example will be like this:
Let's say, for today's IKE exchange, the address are assigned as following:
(without NAT)
Laptop <========> SG
100.10.10.49/500 <=========> 100.10.10.1/500
For tunneling IKE's IP packet through UDP/IP, the IP header (SIP->DIP) will
looks like:
((100.10.10.49/500->100.10.10.1/500)100.10.10.49/500->100.10.10.1/500)
from Laptop to SG. (yes, redundancy)
If one directionally NAT exists between the Laptop and Home-SG:
Let's say, Laptop was assigned 10.0.1.1, NAT-GW is 10.10.10.1 and Home-SG
is
100.10.10.1,
Laptop<->NAT-GW<=====>Home-SG
1) From Laptop to NAT
((100.10.10.49/500->100.10.10.1/500) 10.0.1.1/500->100.10.10.1/500)
from NAT to SG
((100.10.10.49/500->100.10.10.1/500) 10.10.10.1/4999->100.10.10.1/500)
2)From SG to NAT
((100.10.10.1/500->100.10.10.49/500) 100.10.10.1/500->10.10.10.1/4999)
From NAT to Laptop
((100.10.10.1/500->100.10.10.49/500) 100.10.10.1/500->10.0.1.1/500)
Similarly, this scheme still can do IKE even another NAT in between NAT-GW
and
Home-SG for bi-directional NAT.
In this case, the Laptop's inner IP address (100.10.10.49) are not
reachable.
It's function is simply an 32 bit id to get the correct "pass phrase".
However, it can traverse all NATs in the path.
For other IPSec packets,
The UDP->UDP and TCP->TCP mapping, I mean the IPSec packet originator
will copy the inner UDP/TCP/protocol to outer UDP/TCP/protocol before
encryption. (slightly different of tunnel mode)
The mapping along with IP's TOS field will help the applications (in a DS
domain)
use IPSec tunnel without changing the applications packets QoS
classification.
If the outer DS different inner DS (which is encrypted), it requires the
DS domain crossing. Otherwise, for different class of encrypted flows
will be using same (or arbitrary ) DS class.
Looks like the ESPoUDP is inserting UDP in the IPSec packets?
Then, there will be no mapping due to the inner IP header have been
encrypted.
Thanks for clarifying the ESPoUDP.
Regards,
--- David
-----Original Message-----
From: Derek Atkins [mailto:warlord@MIT.EDU]
Sent: Wednesday, June 13, 2001 9:52 AM
To: Chen, David
Cc: 'jshukla'; ipsec@lists.tislabs.com
Subject: 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
Follow-Ups: