RE: issue 34 proposal

Stephane Beaulieu (stephane) writes:
> > For ESP packets you could do that, but for IKE packets you 
> > need separate path test exchange if you do that, as then you 
> > cannot probe if the path is working with IKE packet, as the 
> > probe can break the link (it would cause traffic to move to 
> > that address pair and if that address pair was unidirectional 
> > the connection would be lost because of that). 
> 
> Not sure I follow your second point.
> 
> You're saying that the original NAT mapping was bi-directional, but
> after the reboot, a new NAT mapping was given but this one is
> uniderctional?  I admit my experience with NAT is limited, but I have
> never seen this happen.
> 

When the NAT mapping is lost most commonly it can only be recreated
from the behind of NAT. This will create bi-directional mapping.

The problem with the automatic updating of the address pair when
receiving valid packet from the remote end is that if you have working
address pair A1, B1 (with NAT), and you are using it. You also have
another address pair A2, B1 (with or without NAT) and you do not know
if it works yet. So now if you send IKEv2 probe packet with A2, B1 to
the remote host, the remote host will notice that this is valid packet
for the IKEv2 SA, thus it will move the traffic immediately to that
A2, B1 pair when receiving that packet.

Now if that A2, B1 path happened to be uni-directional for some
reason, so the reply packets B1, A2 will not get through then we
managed to cause connection problem while we still had completely
valid and working address pair A1, B1. Even when we later retransmit
that packet to A1, B1 address pair, the other peer now notices as this
retransmission, and replays its old answer back. It might not update
the mapping at that point (it is not clear from the ikev2 draft
wheather replays should be consider "valid authenticated packet").

If we disable the IKEv2 automatic updating of the remote peers
address, then we can send that probe packet, and it will not cause any
connection problems. After a while when we notice that we are not
getting reply back, we retransmit that using other addresses, i.e. A1,
B1, and other end would then reply to us to B1, A1 address and the
exchange is finished.

I would actually say that replay is not "valid authenticated packet"
as it would be too easy for the attacker to grab one "valid
authenticated packet" from the link, modify the IP headers and the
replay that every second, to make sure the traffic is all the time
redirected to the host he wants to attack. 

> I have however seen NAT mappings get lost many, many times.

Was the problem there NAT rebootting, or too long keepalives or
something else? 

> BTW, have you seen the number of home/SOHO router/NAT boxes you can buy
> today for about $5.  Reliability is not the first word that comes to
> mind.

True, but in that case I would assume they know who to blame... :-)
Still most of those small NAT boxes have enough memory and so small
amount of traffic that they do not have really reason to remove NAT
mappings very fast. And I do not think they crash that often. Again if
they crash that will cause long delay anyways.

> I'm willing to implement it both ways because the cost/complexity is
> fairly low, and I can see how doing it via ESP detection only might be
> more difficult for some vendors.

So perhaps we should say you MUST NOT do automatic update with IKEv2
packets (breaks the probing), but you MAY do it for ESP packets? It
will add the another module causing address updates, and you need to
make sure the policy for the MOBIKE and that automatic update module
are same.

I really like the explicit address update because it will put the all
policy decision about address changes in exactly one place, i.e in the
MOBIKE module. 
-- 
[email protected]