[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt
> The 5 minute interval of keep-alives (keep-alives still sent
> every 20 (or X) seconds) after all SAs are down is to allow
> for the case for the peer external to the NAT to potentially
> decide that it needs to rekey the MM, and still have the NAT
> hole poked so that the IKE traffic could traverse the NAT and
> reach the internal machine. This is a tradeoff between
> maintaining lots of state and sending keep-alives vs.
> potentially breaking upper layer connections.
The paragraph as worded implies that a single keepalive packet
might be sent after an elapsed period of up to N (5) minutes.
I would suggest moving the paragraph to after the paragraph
below it and re-wording it to something like:
"A peer MAY continue to send NAT-keepalive packets every M seconds
for up to N minutes after the last Phase I and Phase II SA between
the peers has been deleted. This will keep the NAT mappings alive
and allow the peer external to the NAT to initiate a rekey if it
decides it needs to. N is a locally ..."
Also I would think that the 5 minute default is too long. If VPN
wasn't involved the "server" wouldn't normally be able to connect
back to the "client" after 5 minutes so I'm not sure why this
capability should be provided for VPN. One or two keepalive
packets after the last SA has been deleted should be more than
sufficient as the default. Is the long 5 minute default have
something to do with the fact that the keepalive mechanism
happens at the IP layer and for some implementations it might
be problematic for it to know when the last Phase 1 SA has been
deleted? I guess this is a problem of dangling Phase 1 SAs :-)
To really be reliable the IPsec system behind the NAT device will
need to keep TCP connection state and generate keepalives while
there are open TCP connections (no need to keep the IPsec/IKE SAs
active though). The NAT device use to keep the TCP state for
them but since TCP is now encapsulated in ESP/UDP the NAT mappings
no longer have state and just have the UDP timeout. The IPsec
system must now assume that burden if it wants to provide the
same functionality that would exist without using VPN. There is
probably a better solution to this than sending a packet every
20 seconds for TCP connections that are idle for a very long time.
But I don't think just doing it for five minutes is a solution either.
-dave
Follow-Ups: