Re: issue 34 proposal

 In your previous mail you wrote:

   But, couldn't an attacker capture an ESP packet, change the src ip /
   port, and force us to start sending/flooding packets to an un-suspecting
   IP addr?
   
=> yes but by definition a NAT is out of control (if you can control it
the first thing you'll do is to remove it :-) so:
 - the implicit update is its own defense, i.e., either it is not supported
   and the attack doesn't work, or it is supported and the first good packet
   from the node behind the NAT will fix the address
 - the pseudo-NAT can simply move the direct (i.e., not reflected) traffic
   to a third party

   At least a RR test would tell us that our 'peer' can indeed recv packets
   on the new IP.

=> not really as:

   Still has MitM issues on the RR, mind you...
   
=> IMHO it is better to rely on ingress filtering:
 - when it is deployed, it catches the same attacks than RR
 - when it is not deployed, the attackers have already too many
   simpler possibilities as the real world can prove everyday...
So I think that most of RR "requirements" are only FUD.

Thanks

[email protected]