RE: issue 34 proposal

 
> 
> Stephane Beaulieu (stephane) writes:
> > Can't both be done?  If I notice that packets are coming in using a 
> > SPI for which the IP/port doesn't match what I expect, can't I just 
> > process them anyway, and update my sadb?  There doesn't appear 
> > anything interoperability wise to stop you from doing this.  If you 
> > update, you recover NOW.  If you wait for DPD/NAT-T, it will take 
> > longer, but still eventually update.
> 
> 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.

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

> 
> > It means more code to write (since we have to be able to handle 2 
> > different ways of changing NAT mappings), but it does satisfy both 
> > camps.
> 
> Why would you want to write more code just to cover very corner case?

Job security :)

Nah, seriously though, I prefer the automatic updates because of the
speed of recovery.  Though you claim that NAT mapping drops are rare, my
experience is different.  Yes, they might be rare enough, but every time
it happens, I have to spend 1 hour looking through customer's syslogs to
figure out why things stopped working.  I hate doing that ! :)

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.

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.

> 
> We do not expect the NATs be rebooted or loosing mappings 
> regularly, it might happen to some people every few months or 
> so, and some people will probably never see that.
> --
> [email protected]
>