Re: bidding down attach on NAT-T

[Francis Dupont <Francis.Dupont@enst-bretagne.fr>]

 In your previous mail you wrote:

   -----BEGIN PGP SIGNED MESSAGE-----
   
   
   >>>>> "Francis" == Francis Dupont <Francis.Dupont@enst-bretagne.fr> writes:
       Francis> => the IKEv2 mechanism has to be revised because it is subject
       Francis> to a bidding down attack. Can we open a thread about this?
   
     As I understood things, this issue is not that a third party can 
   force UDP encapsulation of the ESP packets by playing with the UDP
   headers of the IKE exchange.
   
=> there are two things, the bidding down attack and the attack using
the NAT traversal. Your text is about the second: it is useful but
it is not the bidding down attack, i.e., it is just an explaination
of the "bidding down".

     The issue is that said attacker can force all transmissions from the
   gateway to the client to go via itself.

=> not itself but someone.

   It does this by pretending to
   be a NAT, and futzing with the source IP/port#. The gateway will use that
   address for the packets it sends. 
     We can not, in general have the gateway refuse to change its notion of
   where to send things because: 
          1) the attacker could have started futzing at the beginning of the
   	  exchange anyway.
          2) a NAT may legitimately assign new port numbers/IP addresses to
   	  the flow.
   
     So, what in the end is the effect of having the IKE/ESP flow sent via
   some malicious third party? Assuming that the third party does not drop
   any packets in the flow, we have:
        a) additional latency. 
        b) traffic analysis.
        
     I assume that the crypto is good. If it isn't, and the attacker can break
   the crypto, all bets are off anyway.
   
     The most serious thing that the third party can do is to hijack the flow
   with the intent to disrupt the flow. This is a denial of service attack.
   
     I have a notion on how to deal with this, but before I get into it,
   I'd like be sure that we are solving the right problem.
   
=> yes, the main issue is the DoS attack. IKE itself is secure but
it can be (ab)used to launch attacks.

     The problem is: is there a way for the client/gateway to agree that they
   have a functional UDP pipe between each other before committing to a change.
   
=> there is none.

It seems we agree that the NAT traversal feature is less secure so:
 - it should be disabled when one knows there cannot be a NAT on the path.
 - the NAT detection should be safe, i.e., it should not give false
   positive. This is my "bidding down" argument against the current
   mechanism (which has many other problems but one is enough).

Thanks

Francis.Dupont@enst-bretagne.fr

PS: the bidding down attack itself is obvious: the attacker has only to
change a NAT-DETECTION-*-IP in the IKE_SA_INIT reply.
PPS: the reference about attacks using IKE (not against IKE) is
draft-dupont-transient-pseudonat-01.txt