[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt
I think that if the ID states that a peer MAY send keepalives for N minutes
with a default of 5 minutes that many implementers will always send
keepalives for 5 minutes. I don't think this is such a good idea.
Asking/requiring clients to keep track of TCP connection state isn't such a
good idea either (it should be recommended though - gateways will usually
already have this capacity).
As a tradeoff recommendation how about something like:
A peer SHOULD send a NAT-keepalive packet while there is an IKE or IPsec SA
in place if a need to send such packets is detected according to [Kiv00] 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.
A peer MAY continue to send NAT-keepalive packets every M seconds while
there exists open TCP connections between the systems. As an alternative to
maintaining state for TCP connections for this purpose a peer MAY continue
to send NAT-keepalive packets every M seconds for up to N minutes after the
last active IPsec traffic was processed even when the last IKE and IPsec SA
between the peers has been deleted. This means that if a VPN session has
been idle for more than N minutes when the last SA between the systems is
deleted then no more keepalives are sent. N is a locally configurable
parameter with a default value of 5 minutes.
With this wording implementers are less likely to continue sending keepalive
packets for 5 minutes after each and every VPN session is torn down. I'm
assuming here that the N minutes linger period was a tradeoff between
maintaining lots of state vs. potentially breaking upper layer connections.
-dave
-----Original Message-----
From: Brian Swander [mailto:briansw@windows.microsoft.com]
Sent: Tuesday, July 10, 2001 12:06 PM
To: Mason, David; ipsec@lists.tislabs.com
Subject: RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt
I can field a couple of the below:
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.
As for the AH specification, we put it in for completeness because we
didn't want to open the draft up to the criticism of ignoring AH. I
cannot speak for the rest of the authors, but I'd be surprised if anyone
is very interested in supporting AH. Also, I don't think there would be
much resistance to removing the specification of AH, if we reach that
consensus.
bs
-----Original Message-----
From: Mason, David [mailto:David_Mason@nai.com]
Sent: Tuesday, July 10, 2001 7:22 AM
To: ipsec@lists.tislabs.com
Subject: RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt
What is the purpose/motivation behind the AH Envelope? It seems like
needless overhead to me.
What is the purpose/motivation of the long period (default 5 minutes)
keepalive mentioned in the second paragraph of section 4?
Why bother providing even a MAY for support of AH? Only support for
IPv4 AH
is specified, in which case ESPNULL provides practically the same
protection
(yes AH protects 3 historic security options, the router alert option
which
is noted to be incompatible with IPsec, and the multi-destination
delivery
option but how often are these options actually used?). In the past
people
have been jumping up and down about IKE/IPsec already being too complex.
I
think this is a case where added complexity provides very little
benefit.
Just for the fun of causing trouble and stoking fires: I noticed that
the
NAT-traversal drafts were published under the auspices of the WG instead
of
as individual submissions. I thought there was an edict that the WG
would
not support changes to IKE/IPsec. Has the edict been dropped, or is it
a
wish-washy edict, or are IDs with lots of authors from powerful
companies
exempt?
-dave