[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt
There may be extra state on the peer outside the nat, especially in
transport mode in order to allow the outside peer to rekey MM. Also, we
cannot make assumptions about when rekeying occurs. Some
implementations use the continuous channel, and some only bring up SAs
when the traffic is flowing. Thus, you may have scenarios when the peer
outside the NAT needs to do the rekey.
These could occur in tunnel mode as well, for exactly the same reasons.
In this case, the peer outside the nat would need to remember which UDP
encap ports to use in order to initiate the MM rekey. Yes, the inside
peer can reinitiate the MM in the tunnel case at any time without
problems, but in order to make sure connectivity is up, the outside peer
may need to do it.
bs
-----Original Message-----
From: Mason, David [mailto:David_Mason@NAI.com]
Sent: Wednesday, July 11, 2001 11:47 AM
To: Brian Swander; 'ipsec@lists.tislabs.com'
Subject: RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt
On further thought, it seems that sending keepalives while there are TCP
connections open or for an N minute linger period really only helps the
transport case (so that the decapsulated packet is guaranteed to have
the
same source address after a rekey).
Keeping the NAT mapping alive so that the "outside" peer can rekey
doesn't
work unless that peer maintains information about SAs that no longer
exist
(this would have to be done in both the kernel and in the IKE daemon).
If a
rekey is required when an SA expires it will generally have been
performed
already so as to provide lossless rekey.
The inside peer can rekey at any time - it will just cause a new NAT
mapping
to be created. In the tunnel case this shouldn't cause any problems.
Did I
miss something here?
-dave
-----Original Message-----
From: Mason, David
Sent: Wednesday, July 11, 2001 1:46 PM
To: 'Brian Swander'; ipsec@lists.tislabs.com
Subject: 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