[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt
> That's not true. Most NAT boxes will expire a TCP
> mapping if they are idle for some period of time
> (generally on the order of 10 minutes, but it certainly
> varries from box to box). So, you _still_ need a
> keepalive on a TCP session, too.
Well that would be at least an order of magnitude less
keepalives.
> If your connection is idle for that long a period of
> time, send an IKE DELETE notification and tear down
> the session.
Do you think that this recommendation should go into the
ID (and would you suggest a default - if the inside system
would lose connections after 10 minutes without using VPN
then perhaps a 10 minute default would be appropriate).
> The reason you need the keepalive there is that if the
> IKE SAs are still in place, there is no way to know
> _which side_ will want to send the 'next' packet. If it's
> the 'server' (e.g. the non-natted host' then there is no way
> for that server to contact the client (the natted host)
> because all state information has been lost. And there is no
> way to notify the client that there is any data to transmit,
> either,for the same reason.
If there are IKE SAs still in place then all state information
has not been lost so I'm assuming you mean the NAT mappings
are gone. That's why I proposed using a TCP second channel.
So the server could contact the client via the TCP NAT mapping
and request that the client reactivate the UDP NAT mapping.
-dave
Follow-Ups: