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:

OK.  That's a bogus argument.  NAT's exist all over the place, mostly in
places where RA (and Mobike) will be done.  The attack in question would
be most effective when done near the Head-End.  The Head-End
administrator can't control whether it's peers are behind NAT or not.

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

But if someone is sitting in front of the head-end, then he can muck
with all the packets.  Even worse, let some good ones through, and
switch others that way neither peer will ever detect it (except for
noticing lots of TCP retransmits).

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

If no RR test (with NATD payloads) is done *before* switching, then
consider me opposed to this solution.

In fact, I'm beginning to think that ESP detection might cause more
problems than it solves...

Stephane.

> 
> Thanks
> 
> [email protected]
>