Re: Last Call: 'UDP Encapsulation of IPsec Packets' to Proposed Standard

[Tero Kivinen <kivinen@ssh.fi>]

Henrik Levkowetz writes:
> >  > In section 4. NAT Keepalive Procedure:
> >  >
> >  >   "A peer SHOULD send a NAT-keepalive packet if a need to send such
> >  >   packets is detected according to [Kiv05] and if no other packet to
> >  >   the peer has been sent in M seconds. M is a locally configurable
> >  >   parameter with a default value of 20 seconds."
> >  >
> >  > Is there a rationale for 20 seconds? Experience with MIP4 NAT traversal
> >  > indicates that a longer time (110 seconds is the default per rfc 3519)
> >  > seems to work well.
> > 
> > In that case just locally configure it to be 110 seconds :-). But yes,
> > there was some experimentation done by (Microsoft? SSH?) to set the value.
> 
> Ok. If you could point me to the source this might be interesting.

>From my old email:
----------------------------------------------------------------------
    * To: "Chinna N.R. Pellacuru" <pcn@cisco.com>
    * Subject: Re: NAT Traversal
    * From: Tero Kivinen <kivinen@ssh.fi>
    * Date: Sun, 3 Mar 2002 23:34:30 +0200
    * Cc: ipsec mailling list <ipsec@lists.tislabs.com>
    * In-Reply-To: <Pine.GSO.4.33.0203030750040.28716-100000@cypher.cisco.com>
    * Organization: SSH Communications Security Oy
    * References: <15490.12610.696868.294810@ryijy.hel.fi.ssh.com><Pine.GSO.4.33.0203030750040.28716-100000@cypher.cisco.com>
    * Sender: owner-ipsec@lists.tislabs.com

Chinna N.R. Pellacuru writes:
...
> 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. 
----------------------------------------------------------------------

I do not remember where the 20/30 seconds actually came from, but I
remember someone saying that 30 seconds was quite normal (i.e thats
why we use 20 seconds), and as you can see from above Chinna N.R.
Pellacuru says that there has been practical recommended timer of 9
seconds. 

> As for the description of the DOS attack, I still think that should be
> explicit. What kind of attack is it? What are the details? Doing "the
> strictest possible checks for UDP packets" how?

There are dozens of different UDP packet attacks, lots of them are
related to fragments (i.e sending every other fragment, sending 4000
small fragments, sending packets that go over the 64k limit etc). I do
not think it is practical to list them all here. 
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/