[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NAT Traversal
"Chinna N.R. Pellacuru" <pcn@cisco.com> writes:
> For inbound processing: The following packet fields are used to look
> up the SA in the SAD:
>
> o Outer Header's Destination IP address: the IPv4 or IPv6
> Destination address.
> [REQUIRED for all implementations]
Note this this says _OUTER_ header. This means that this will be the
address of the Security Gateway or the NAT box, in all cases except a
BITW. In other words, for the vast majority of all cases, this
basically means "on which inbound interface this packet arrive?" or at
worst "to which interface was this packet addressed?"
In other words, this is a practical no-op.
> o IPsec Protocol: AH or ESP, used as an index for SA lookup
> in this database. Specifies the IPsec protocol to be
> applied to the traffic on this SA.
> [REQUIRED for all implementations]
Ok, you might have something here, but you only get 1 bit of lookup
space. Is that really significant?
> o SPI: the 32-bit value used to distinguish among different
> SAs terminating at the same destination and using the same
> IPsec protocol.
> [REQUIRED for all implementations]
This is where the major differences are between SA.
Chinna, I think you are being a bit confused about what the (new)
intention is with regards to the "required" elements. That fact that
a particular process is not required does not mean that you cannot do
it that way. What it means is that you cannot EXPECT a peer to do it
that way.
If you want to continue, in your implementation, looking up a SAD by
the tuple {destIP,Protocol,SPI} you are more than welcome to do so.
However, with the relaxted constraints you cannot assume that your
peer is going to look it up in the same manner.
On a different note, you never answered a key question I had: in your
proposal what is the NAT gateway supposed to do if it has multiple
cache hits? Here's what I mean: assume the following network
architecture:
Private network Public network
Host-(A)--
\
Host-(B)--+-- (N) NAT Box (NP) ------- Security Gateway (SG)
/
Host-()C--
Feel free to add as many hosts as you want on the left side -- assume
you're at a conference with thousands of people, with many co-workers
from the same company.
Next, all these users try to connect to one security gateway. Assume
they all connect at the same time (the current working groups just let
out and they are all on break now).
You get three IKE sessions -- fine -- the IKE cookies uniquely
identify them. No problem. Each pair agree on a set of SPIs
and start sending out ESP packets. The NAT box sees packets that
look like the following:
IP {src=A, dst=SG} ESP {SPI=spiA1} ...
IP {src=B, dst=SG} ESP {SPI=spiB1} ...
IP {src=C, dst=SG} ESP {SPI=spiC1} ...
The NAT box will add these entries to its table, convert the
IP address, and send them on:
IP {src=NP, dst=SG} ESP {SPI=spiA1} ...
IP {src=NP, dst=SG} ESP {SPI=spiB1} ...
IP {src=NP, dst=SG} ESP {SPI=spiC1} ...
This is all well and good. Now the Security Gateway responds.
The NAT box gets three packets that look like:
IP {src=SG, dst=NP} ESP {SPI=spiX1} ...
IP {src=SG, dst=NP} ESP {SPI=spiX2} ...
IP {src=SG, dst=NP} ESP {SPI=spiX3} ...
Now, the NAT box has to somehow has to map these three packets back
onto the original sources. Clearly the only thing it has to work with
is the SPI, because everything else is the same. So, how does it do
that? Worse, what happens if hash{spiX1} === hash{spiXn} (for some
value n)? If you have enough hosts connecting through the NAT then
you can make the probability of this occuring arbitrarily large.
Can you please explain how you expect to handle this?
-derek
--
Derek Atkins
Computer and Internet Security Consultant
derek@ihtfp.com www.ihtfp.com