[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt
So the following might be a useful addition to the ID:
The peer outside the NAT MAY want to maintain the outbound
SPD and enough information to facilitate a rekey after the
IKE and IPsec SAs have been deleted for a period of X
minutes or while the peer inside the NAT continues to
send NAT-keepalives, whichever is shorter (perhaps accounting
for the possibility of lost keepalives). X is a locally
configurable parameter with a default value of 5 minutes.
Ideally N and X would be the same - should perhaps this
information be exchanged as part of [Kiv00]? For the
tunnel case, if the outside system isn't going to maintain
state for N minutes then the inside system needn't send
the linger keepalives.
To tell you the truth, without specific goals in mind,
with a clear and precise explanation of how to achieve
those goals, the whole N minute linger thing seems like
a kludge to me (except perhaps in the transport case).
-dave
-----Original Message-----
From: Brian Swander [mailto:briansw@windows.microsoft.com]
Sent: Wednesday, July 11, 2001 3:03 PM
To: Mason, David; ipsec@lists.tislabs.com
Subject: 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