Re: NAT Traversal

[Tero Kivinen <kivinen@ssh.fi>]

Chinna N.R. Pellacuru writes:
> > The keepalives are only needed if you are actually the one who is
> > behind NAT box. If we are talking about road warrior - SGW case, then
> > the road warrior will send keepalives, the SGW will not send them.
> > Also we are mostly interested in the performance in the SGW end the
> > road warriors laptop do have enough cpu to do the few SA flow
> > processing it is doing. The SGW might be doing thousands of tunnels
> > and every small operation we need to do there counts.
> 
> That's good. Is that mentioned in the drafts? I thought that the draft
> didn't give so much detail about keepalives. It just says "A peer SHOULD
> send a NAT-keepalive packet if a need to send such packets is detected
> according to [Kiv00] and if no other packet to the peer has...".

draft-ietf-ipsec-nat-t-ike-01.txt ([Kiv00]) says:
----------------------------------------------------------------------
...
3.2.  Detecting presense of NAT

The purpose of the NAT-D payload is twofold, It not only detects the
presence of NAT between two IKE peers, it also detects where the NAT is.
The location of the NAT device is important in that the keepalives need
to initiate from the peer "behind" the NAT.
...
If there is no NAT between then the first NAT-D payload should match one
of the local NAT-D packet (i.e the local NAT-D payloads this host is
sending out), and the one of the other NAT-D payloads must match the
remote ends IP address and port. If the first check fails (i.e first
NAT-D payload does not match any of the local IP addresses and ports),
then it means that there is dynamic NAT between, and this end should
start sending keepalives as defined in the [Hutt01].
----------------------------------------------------------------------

> It also says that the keepalive timer should be 20 seconds, but I read
> somewhere else that the practical recommended default timer is 9 seconds.

Normal time to keep udp connections is usually few minutes, but as
there are boxes which are using shorter timeouts (even down to 30
seconds), that is the reson draft-ietf-ipsec-udp-encaps-01.txt
suggests the 20 seconds.

Also as the keepalive packets are usually sent via the local area
network only, that means that they are usually more reliable than the
global internet. This means that it is quite often enough if we send
only one packet per timeout value, i.e we don't need to care about
lost packets.

Again, because this is not always the case the parameter needs to be
configurable.

One more thing to note about the keepalives is that they are only sent
where there is no other traffic going on the IPsec or IKE SA. Normally
there is constant data going for the IPsec SA, thus it is already
keeping the mapping up. This is also one of the benfits of having IKE
and IPSec SA share the mapping, so we don't need to keep the IKE SA up
with timeouts, as the IPsec SA packets keeps it up. 

> The checksum is a simple 16-bit ones-complement sum of the data. If the
> checksum is so fool proof why is it not a MUST, and is only optional. I

It is MUST to implement for both UDP and TCP, and it MUST to be on by
default. There MAY be option to turn it off for UDP. It is always MUST
for tcp. This has already been pointed out in this thread with
reference to rfc1122.

Note, that the case where we talk about turning off the checksum
calculation is mostly for the cases where there is one more checksum
inside the packet anyways, and where the local stack is going to
process the packet.

> > The STUN protocol seems quite complicated, it for example does binary
> > search with different timeouts to find out the lifetime discovery etc.
> What do you propose? Instead use a very low lifetime so that it would work
> everywhere? I think it would save a lot of chatter by choosing the right
> lifetime, and using an appropriate lifetime rather than using a minimum
> default of 9 seconds always, like some implementations do.

There are few problems. Firstly doing lifetime parameter detection
takes real time. To see if the lifetime parameter is more than 5
minutes, we need to wait for 5 minutes. Of course we could start with
the short timeouts, and while the probe goes on, we could raise the
keepalive timers used in the IKE. Another problem is that the lifetime
parameter isn't constant. When the load goes up, those timers usually
goes down, because the NAT box is running out of the memory. This
means that we might start up with 5 minute timers, but when the load
goes up suddenly our connections are broken because the NAT box
lowered the timer value to 2 minute.

> I am not proposing that you come up with another version of IKE just for
> NAT traversal. I am saying that you can use a generic "NAT discovery"
> protocol before even starting IKE.

That would be one of the options. When we ware discussing this in the
Minneapolis IETF year ago, this draft wasn't available. I have to
check the STUN protocol more to say if there is something that is
missing that IKE needs. 

> If you use a generic protocol like the one above, you get those
> tremendrous benefits like finding out the lifetime you have to use.
> Keepalives are also consuming precious bandwidth. They shouldn't be just
> considered from a CPU cost on laptops point of view.

One of the things we ware discussing was also limiting the TTL of the
keepalives. They only need to reach the last NAT box to keep that one
up, thus we could configure the TTL to be short enough so that they
will be expired before the actually go any furter out. This was
rejected mostly because finding out the proper TTL complicates things
and the TTL could change during the normal operation.

Also as the keepalives are only sent when there is no other traffic
going, their bandwidth usage is limited only in the case where the
client is not doing anything. 

> OK. It's 16 bytes of overhead. I think that I saw a proposal that used
> 24 bytes at some point. 16 bytes is still a lot of overhead for each ESP
> packet.

That might be old Stenberg proposal, that was changed because people
considered its overhead too big. 

> And there are these NAT boxes that were upgraded because some IPsec
> implementations were broken, and your proposal will again not work through
> these NAT boxes. It's ironic that broken IPsec will work through these
> upgraded NAT boxes, but IPsec-NAT-traversal won't work.

No, it does not work through those boxes. Put two clients behind one
NAT box that maps them to same IP address, and think what happens when
the second one of them is sending the INITIAL-CONTACT notification.
That notification will remove all IKE SAs and IPsec SA associated with
the remote system. In this case the remote system is the port 500 of
the NAT box. In our case the remote port will be different, meaning
that the remote systems can be considered different. I think there are
quite a lot of implementations out there that will check the remote
ip-address, but if they want to implement NAT-T they will have to
modify their interpretation to check port number too. 

> Some IPsec implementations were broken, and so people to workaround it
> upgraded their NAT boxes with a hack. Now, there comes along this new
> IPsec NAT traversal protocol which again doesn't work with these NAT

I wouldn't say our proposals come out now. They have been out for
several years. During that time NAT boxes changed. 

> boxes, and so the NAT boxes need to be upgraded again to come up with
> another hack to work with this new IPsec NAT Traversal protocol.  The
> second upgrade to the NAT box is required because the IPsec NAT traversal
> protocol is designed with the most important design goal as, NAT boxes
> will NOT be upgraded! There seems to be a BIG disconnect between your
> design goals and practical deployment.

There is already been discussion about changing the current draft so
that it will float to different port in the middle of the Phase 1 to
cope with that kind of NAT boxes. Of course it makes things more
complicated but we have to do something for the issue. 

> Exactly, "VALUE-ADD" is what people are willing to pay for double the
> cost, and sometimes even more. My point is that the ISPs can add some
> "VALUE" using our proposal, by translating IPsec properly, instead of the
> customers trying to figure out a way by themselves to somehow sneak
> through the ISP's NAT implementation.

I wouldn't be paying double for the different kind of NAT, I am paying
about double to get fixed ip-address without NAT at all. 
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/