[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.
You don't necessarily need to use the src port as part
of the lookup. Just use the cookies.
> 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.
Just use the cookies for the lookup.
> 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.
TCP NAT mappings don't require a keepalive. They're generally
based upon the state of the connection (which can also create
problems) and not a flat timeout as is used for UDP. I'm not
saying that I know what the solution is, I'm just saying that we
need to take a serious look at possible alternatives. Do not
send the TCP message in the clear (use the cookies for lookup -
and yes there are problems here in determining message boundaries).
> 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.
I was under the impression that the N minutes linger was
so that the clients don't need to keep track of active
connections. I'm also concerned with keepalives for
long periods even when there are idle active connections.
A change in NAT mappings doesn't necessarily mean the
invalidation of the IKE SA.
-dave
Follow-Ups: