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.

OK.  So you're assuming that when we dectect a port change at the ESP
layer, then we'll send probes to all possible paths.  I was not making
this assumption.

> 
> 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. 

This is a good point.  An attacker could fool us into changing our
database just by modifying our outer headers.  I hadn't thought of this.
I think what you're saying is that the only way to prevent this, is to
do a probe to 'confirm' the peer's new address, but that doing so might
cause you to choose a bad path.

Could you not do a probe (or some other exchange) JUST to the new
address to verify that the peer is indeed reacheable on this new
IP/port?.  Of course you'd have to rate-limit this to avoid someone
forcing you to build/send endless probes.

> 
> > I have however seen NAT mappings get lost many, many times.
> 
> Was the problem there NAT rebootting, or too long keepalives 
> or something else? 

I've seen it all :)  

> 
> > 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.

Who are you going to call though?  The guy who sold you a $10,000 box
with a support contract, or some 1-800- support number which is now
disconnected. ;)

> 
> > 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.

It would be ideal, but I would also like to be able to recover from
badly-behaving NAT boxes, if we can with a relatively low cost.

> --
> [email protected]
>