[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt
Sorry for continuing to harp on the NAT-keepalives, but does the WG really
want to come out with a proposal that has the potential of generating lots
of unnecessary traffic? With the dramatic increase of always connected
systems behind NAPT devices (e.g., cable modems), it is very probable that
these systems will maintain long lived VPN links that will be idle for very
long periods of time (thereby generating lots of NAT-keepalives under the ID
as it stands now).
The sole purpose of the NAT-keepalives is to keep the UDP NAT mappings
alive. Perhaps this isn't necessary (at least not for long periods of
inactivity). The system inside the NAT can cause a new UDP NAT mapping to
be created at any time. All that needs to be done is to find a way that
will enable the outside system to do this as well. Obviously the only way
for this to happen is for the outside system to ask the inside system to do
it. What about a dual-channel communication pathway for the IKE daemons?
The regular UDP method, but also a back-up TCP connection. The
justification ID didn't really cover this possibility. It addressed TCP as
an either-or option compared to UDP.
I haven't really thought about all of the ramifications. Here are a few
questions to begin with:
How does the system outside the NAT determine it needs to ask for a NAT
mapping activation? One way would be if the UDP channel hadn't been used
recently. Obviously this only happens when it needs to send something to
the peer.
How does it request a NAT mapping activation? Using the TCP channel,
perhaps using an acknowledged notify exchange.
What if the TCP channel goes down (faked reset packet)? This is the big
problem area which needs a lot more thought than these starting comments. If
the inside system detects a connection close it reestablishes the TCP
connection. The system outside the NAT could perhaps ignore (intercept and
delete) RST and FIN packets while an SA still exists between the peers.
How does one verify and correlate a new NAT mapping with the old mapping
(change in port and/or address)? I'm sure the WG could figure this one out.
Does anyone else feel that the sending of NAT-keepalives is an issue that
deserves further analysis?
-dave
Follow-Ups: