Re: bidding down attach on NAT-T

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

 In your previous mail you wrote:

     Well, they do not need to be in the reverse path.
     It enough to be in the forward path.  (client->gateway)
   
=> IMHO this is only true for the bidding down attack itself
because for the transient pseudo-NAT attack the initiator/client
won't receive the reply so will retransmit the request.

     The replay protection means that it isn't enough to replay the packet,
   unless one can do it faster than the original packet. So, I agree that the
   attacker pretty much has to be inline. 
   
=> agreed

     I'm wasn't explicit in saying that these aren't unique attacks to NAT-T.
   
=> in fact the only useful thing in favor of my bidding down argument
is that NAT-T is less secure.

     The thing that we could do, is require some kind of three way handshake to
   change the UDP port #/IP address. That could be a rekey.
   
=> it won't be enough: you just increase the number of messages the
pseudo-NAT attacker has to patch.

     This assures that the flow doesn't get aimed at some innocent bystandard
   until the real client speaks again. 
   
     The sequence would go something like this:
   
         gateway receives new UDP port #/IP
   #1    sends notify to old UDP port #/IP,
   	    indicating that it thinks it should change
   #2    sends notify to new UDP port #/IP,
   	    indicating that it thinks it is time to rekey
   
     A client receiving #1 can reply, saying "no thank you" if it doesn't
   want to rekey yet.
     A client receiving #2 can reply with a rekey.
     A client receiving both could cancel the rekey with some token from
   #1. 
    
     This might all fit into Dead Peer Detection.
   
     Note that an observer can easily figure out which is IKE traffic and
   which is ESP traffic. The truly paranoid may want to have the gateway send
   the IKE traffic inside the ESP tunnel. This seems very fragile to me.
   
=> we (me and Tero) already discussed about this kind of three way
handshakes... in fact they are more useful for mobility/multihoming
(they provide more than the trust in the other peer to own its address).
 About NAT-T, it seems the best defense is to support an implicit
address change, i.e., the peer address is updated in all SAs as soon as
a packet (ESP or IKE) is received from a new address. The transient
pseudo-NAT attack still works but its effect is transient, i.e., the
first unmodified packet from the peer will put again the right address.
And this is more efficient for the NAT-T itself.

Thanks

Francis.Dupont@enst-bretagne.fr