[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt
I don't think the below analysis is quite correct. In my opinion, the
UDP NAT mapping is a property of the SA. The outside peer needs to
demultiplex the SA based on the floated source port, i.e. this is part
of the SA state lookup (peer ip, local ip, cookies, src port, (dst port
always == 500). This is the way he uniquely picks out the inside peer.
So, if we let the NAT mapping expire, then basically we've let the MM
SAs expire too.
Say we didn't expire the MM SAs on the NAT mapping change. Now, we want
to send some notify either in IKE or via the extra TCP channel to the
peer to tell him about the new mappings for the old SA. If we send it
as an IKE message, then the message will arrive with a new floated
source port, and we'll need to cook up some funky mechanism to read the
original port out of the notify before validating the authenticity of
the notify, and then do our lookup of the original SA, and then validate
that the notify is ok. When you add into the mix all the state needed
to make transport mode work and modifying all that state on each of
these NAT mapping changes, the complexity of this approach is
overwhelming.
A TCP channel seems even more complicated. For TCP to work, we'd need
to have and IKE channel and an IPSec SA both up. But in the case where
the NAT mappings have changed, it is impossible to keep both of them up
for the reasons above, so I don't see how we could get a TCP message to
the peer, either. Or were you advocating TCP in the clear? In that
case, there is no way to keep the channel up from active attack.
If we are mainly concerned with VPN, then our VPN clients can be made
smarter to also solve the keepalive "problem". The VPN could detect
what connections are active, and if no connections are alive, stop
sending the keepalives and just renegotiate the MM if new traffic starts
up again. Or this could work as an optimization in the ipsec layer to
stop the keepalives when no upper layer connections exists. However,
this will increase the load on the VPN gateways because many more MMs
will need to be negotiated since the change in NAT mapping invalidates
the MM.
bs
-----Original Message-----
From: Mason, David [mailto:David_Mason@NAI.com]
Sent: Thursday, July 12, 2001 8:33 AM
To: Mason, David; Brian Swander; 'ipsec@lists.tislabs.com'
Subject: 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