Re: NAT Traversal

["Chinna N.R. Pellacuru" <pcn@cisco.com>]

On 6 Mar 2002, Derek Atkins wrote:

> "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.

Tunnel endpoint need not be the address on the incoming interface. You can
pick whatever tunnel endpoint as long as everyone knows how to route the
traffic to that tunnel endpoint.

>
> >          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.
>

That makes sense. I don't think I said anything about any assumsion that
an IPsec peer needs to expect something from the other IPsec peer
regarding what SPIs it picks.

There was definitely discussion about internal indexing of the SAD. I
don't think I was confused about that.

> 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.

Makes sense.

> However, with the relaxted constraints you cannot assume that your
> peer is going to look it up in the same manner.
>

We do not require that any IPsec peer of ours, have any assumptions on its
peer's SPI (IE. our local SPI). Where is the local SPI in the outgoing ESP
or AH packet for the peer to even lookup?

> 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?

When the NAT box receives traffic with spiX1 then it tries to see if spiX1
pairs with which of spiA1, spiB1 or spiC1. As I have already explained,
this test is done by the actual algorithm that was used to pair the SPIs
by the QM responder. One of the proposed algorithm is to make half of the
responder SPI as the hash of the initiator SPI. Here initiator and
responder are roles in IKE Quick Mode.

There is nothing bad upto here. Curious why you have worse below.

 Worse, what happens if hash{spiX1} === hash{spiXn} (for some
> value n)?

As I had already mentioned, we have no way in this case to demux. We just
drop the traffic, and hope that the IPsec boxes will try and renegotiate
because they find that none of their data traffic is going through. If you
find someone at a conference who is banging on the keyboard and frustrated
that his ESP traffic isn't going through, he is probably using our SPI
matching technique, and probably is working for a company who has sent a
lot of employees to that conference, and all of them suddenly decided to
connect back to the corporate network simultaneously. You can help him by
telling him to try and connect after a couple of minutes.

You are truly picking on our worst case here. We have not designed our
solution for a "road-warrior" or road warriors who take a break and try
to connect just after the break simultaneously.

 If you have enough hosts connecting through the NAT then
> you can make the probability of this occuring arbitrarily large.
>

"enough hosts" trying to use the same Security Gateway, and also using the
same tunnel endpoint on that Security Gateway. There is no reason why all
users have to use the same tunnel endpoint, even if they are all using the
same Security Gateway. Generally you would want a corporation to have
multiple Security Gateways for redundancy, and for load balancing you
would want the user community to be split across the different Security
Gateways.

Curious what was your estimate of the probability of a "collision" in NAT
translation in this scenario.

> Can you please explain how you expect to handle this?
>

Yes, the NAT box drops the traffic when it cannot demux.

IP is a best effort protocol, and it is connectionless. If IP was
connection based, we would not have to come up with the SPI matching logic
to identify the inbound stream to the outbound stream. UDP is also
connectionless, and if for some reason a UDP translation is lost in a NAT
translation table, the endpoints have to start over, and setup another UDP
session. This is not just for the UDP encapsulation scheme, but for UDP in
general, and for any connectionless protocol.

Our proposal is geared to help people who are willing and have the luxury
to design their network end to end.

Thank you very much for following this entire discussion, and taking the
time to understand our proposal, even though we don't have a draft yet.

    chinna

> -derek
>
> --
>        Derek Atkins
>        Computer and Internet Security Consultant
>        derek@ihtfp.com             www.ihtfp.com
>

chinna narasimha reddy pellacuru
s/w engineer